Enhancing Radiation Resilience and Throughput in Spaceborne RS(255,223) Encoder via Interleaved Pipelined Architecture

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

In this paper, a finely subdivided (36-stage) pipeline is proposed for increasing the throughput of a Reed-Solomon (RS) encoder. The data dependency between the operations for an input data stream generates bubbles in the pipeline; the bubbles are replaced with valid data sets which come from other streams. That is, the inter-stream parallelism in the algorithm is exploited to maintain the utilization efficiency of the pipeline. The proposed pipeline itself seems to be sound; however, it is difficult for the reviewer to understand the effectiveness the authors claimed because of the unclear explanations.

1) Radiation tolerance enhancement
In the reviewer's understanding, the radiation tolerance depends on the error correction capability, and the error correction capability is determined by the algorithm called RS(255,223). There is no explicit explanation on how the proposed pipeline (or interleaving) increases the error correction capability of RS(255,223).

2) Superiority in throughput
Table 1 shows the comparison on throughput. The competitors' circuits are also clock-synchronous, and their throughput depends on the frequency. In the reviewer's understanding, the actual frequency depends on the device or process rule used. For example, a (relatively new) FPGA device with 10nm process rule enables us to achieve higher frequency and throughput than (relatively old) one with 65m process rule. There seems to be no explanation on the conditions affecting the effective throughput, and thus the comparison seems to be unfair.

In addition, as the authors mentioned, the replication of an encoder can increase the effective throughput. In other words, we can achieve higher effective throughput by investing more circuit resources. From this viewpoint, the circuit size should also be taken account of in the evaluation of throughput.

3) Other unclear points
The authors explained that the number of clock cycles required to complete the encoding of one data group (4*223) is 1055. In the reviewer's understanding, the one-cycle reset imposes one more clock cycle; accordingly, the maximum throughput of the proposed pipeline should be approximately 3.040Gbps. Some clarification should be added.

The explanation on "a[i]" and "mem[i][j]" is insufficient.

The explanation on the value "982" on page 8 is missing.

Comments on the Quality of English Language

Overall, the English seems to be fine, but there are grammatical mistakes (e.g. "This issues are").

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

I agree with the authors' contribution and the benefits of their proposed architecture of a 36-stage pipelined RS(255,223) interleaved encoder. In point two Relate Work, there are no citations, and it is difficult to understand whether the proposed algorithms are the author's or the existing concepts. In the author's opinion, this can be emphasized. On page 11 in point 4.1, experiments were made to correct errors in the data, but these results are not described in detail or visualized in the article. And it would be good to show them in some way, since they are used for experimental proof. Table 1 gives the results of the experiments of the author's module and other similar encoders, but it is not clear to me why these encoders were chosen for comparison and in what system the author's encoder was included during the experiment.

Comments for author File: Comments.pdf

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

The article proposes an innovative interleaved pipelined architecture to enhance both radiation resilience and throughput in RS(255,223) encoders, making it highly relevant for next-generation spaceborne solid-state recorders (O-SSRs). The work is technically sound, well-structured, and supported with implementation results on an FPGA platform. The integration of interleaving within the pipeline, rather than as a post-processing step, is a meaningful contribution. I have the following comments for the authors to consider.

 

Review Comments

1. Architecture Diagram (Figure 2): The authors should do clearer labeling of the pipeline stages and signals such as the 2-bit counter, valid signal, and interleaving control in the architectural diagram. Currently, it may be challenging for readers unfamiliar with FPGA design to follow. Also, include annotations or a legend for each key signal/control flow in the figure.
2. Table 1: Please ensure that all acronyms (e.g., SBU, MBU) used in the table are explained in the caption or as a footnote for completeness.
3. Performance evaluation: While performance is tested on a single FPGA chip the authors could address the system-level integration and scalability (e.g., in multi-core encoder systems or under high traffic) also. Please include a brief discussion of potential scalability issues and how the architecture could be adapted for multi-encoder setups.
4. Radiation Testing Limitations: The authors have validated the radiation resilience via error injection, but this is only an indirect method. Acknowledging the absence of real-space or radiation chamber testing and suggesting it as future work would improve the credibility of the validation.
5. Terminology: The authors need to clearly define acronyms like QTBU and DBU when first used in the abstract or introduction.
6. Reference Formatting: Some references (e.g., [18], [19]) are from theses or internal publications. Please consider adding more peer-reviewed references where possible.

Comments on the Quality of English Language

Language and Grammar: The authors should consider proofreading the manuscript for grammatical improvements, particularly in the introduction and conclusion sections. The manuscript has occasional grammatical inconsistencies (e.g., singular/plural mismatches, awkward phrasing).

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

The reviewer still has a question on "Radiation tolerance enhancement." The authors added the explanation and figure that illustrate consecutive symbols are dispersed into four codewords. It is understandable that up to 64 consecutive symbol errors become correctable by using the proposed pipeline. However, in the reviewer's understanding, the interleaving may also gather originally dispersed symbols containing one or more error bits into one codeword and make them uncorrectable. It is unclear whether such a risk exists or not. If it exists, the error correction capability should be properly evaluated; otherwise, the claim on the radiation tolerance enhancement should be eased or retracted.

FYI:
{(892 x 8 bits) / 1055 cycles x 450 MHz} should be nearly equal to 3,043 or 3,044 Gbps. Note that the number of cycles remains 1055.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

The authors have done a good job at revising the paper. However, I still have the following suggestions to consider.

1. Introduction: Please include a short summary comparing RS(256,252) and RS(255,223) earlier in the introduction rather than only in the middle of the section. Also, please avoid overusing phrases like “recent advancements show clear asymmetry” and be more specific.
2. Related work: Please add a comparative table summarizing existing approaches, even briefly, to enhance accessibility for readers unfamiliar with the domain.
3. Reed-Solomon Algorithm: Well explained, but some equations (e.g., Equation 6) could be more clearly formatted and explained with an example to aid understanding. Also, please highlight differences in encoder complexity when switching from RS(256,252) to RS(255,223).
4. Widely Adopted Hardware Architecture: Please add a small illustrative example of encoding a short symbol sequence through the architecture for better clarity.
5. Interleaved Pipelined Architecture: Figures 2 and 3 are critical but are only described, not shown. Please ensure diagrams are clearly visible and labeled in the final submission. Also, explain more explicitly how interleaving addresses the timing dependency bottlenecks. Currently, the explanation is scattered across multiple paragraphs. 
6. Validation and Analysis: While fault injection is a common method, it should be explicitly acknowledged as a limitation more strongly. Also, please include a short discussion on the potential overhead or latency tradeoffs due to interleaving.
7. English and grammar: Please avoid redundancy. Phrases like “performance is significantly improved” are repeated. There are minor grammar issues such as articles and tense mismatches. A careful proofread is recommended. Also, please ensure that all cited works are peer-reviewed and relevant; a few master's theses are cited, which may be less rigorous.

Author Response

Dear Reviewer,

Thank you very much for your continued feedback and insightful suggestions. We truly appreciate your thoughtful review, which helps enhance the clarity and accessibility of our work. Please find our responses to your suggestions below:

1. Introduction – Early comparison of RS(256,252) and RS(255,223):
Thank you for the suggestion. We agree that introducing a brief comparison earlier in the introduction can help establish a clearer context for the choice of RS(255,223). We will carefully consider restructuring this section accordingly.

2. Clarifying vague expressions:
We appreciate your comment regarding expressions such as “recent advancements show clear asymmetry.” Greater specificity is indeed valuable for readers, and we will take this into account to improve clarity in future revisions.

3. Related Work – Comparative table:
Including a summary table of existing approaches is an excellent idea for improving accessibility. We recognize the benefit this would bring to readers unfamiliar with the topic and will consider integrating such a table to complement the discussion.

4. Reed-Solomon Algorithm – Equation formatting and encoder complexity:
We acknowledge the importance of clear equation formatting and illustrative examples. Your suggestion to include a simple example to support Equation (6), as well as highlighting encoder complexity differences, is well taken and will be carefully considered in future refinement.

5. Widely Adopted Hardware Architecture – Encoding example:
Thank you for the recommendation. A small illustrative example can indeed make the process more intuitive, and we appreciate your suggestion to improve clarity in this section.

6. Interleaved Pipelined Architecture – Figures and explanation clarity:
We appreciate your observation. Ensuring figures are clearly presented and explicitly referenced is critical for reader comprehension. Likewise, your advice on providing a more consolidated explanation of how interleaving mitigates timing dependencies is very helpful.

7. Validation and Analysis – Limitations and tradeoffs:
We agree that it is important to explicitly acknowledge the limitations of fault injection methods and to discuss potential latency or resource overheads. These are valuable considerations for readers and practitioners alike.

8. Language and References:
We thank you for your attention to language and reference quality. Avoiding redundancy and ensuring consistent grammar, as well as using peer-reviewed sources wherever possible, are important aspects of a polished manuscript. Your points are well noted.

Once again, thank you for your constructive feedback and valuable suggestions. We are grateful for your efforts in reviewing our manuscript.

Round 3

Reviewer 1 Report

Comments and Suggestions for Authors

All the reviewer's questions have been answered and addressed.