In-Pipeline Processor Protection against Soft Errors

Round 1

Reviewer 1 Report

Comments for author File: Comments.pdf

Author Response

Thank you very much for your feedback and valuable comments. We did our best to address all your points to improve the paper accordingly. The paper has undergone extensive grammar and syntax editing besides the technical points.

Answers to the questions and related improvements:

1. In line 296, the conditional statement of the phrase seems to be self-contradicted. The periodically reading out of individual records could avoid fault accumulation. Is that the case? - Yes, you are right. This is why we implemented the Automatic Correction Mechanism (ACM) into the pipeline - to ensure that each record in the register file is periodically checked, which prevents the accumulation of faults. Chapter 3.3 has been reworked to reflect the implementation status better.
2. In line 440, you do not clarify the reason you utilize two comparators for the register outputs. Please elaborate. Also, what is the reasoning behind the connection of d0 to t0 and t2, and the connection of d1 to t1? - Regarding the comparators: we need to ensure that if the comparator fails due to SET, the instruction will be restarted. So we need at least two comparators to detect a fault. We made a simplification - the registers at the output of the OP-stage have tenths of bits. One comparator compares all the bits of the first replica of OPEX registers with all bits from the second replica. Regarding the connection between the dX and tX pipelines: such an interconnect is necessary to connect two replicas of the pipeline to three replicas. Besides interconnection, such an approach allows protection with two replicas of ALU instead of three. We have significantly improved Chapter 4.2. so it should be more clear now.
3. In line 467, why the predictor gets the current fetching address from pipeline d0 and not from pipeline d1? Is there a particular explanation for this? Please clarify. The same for RAS. – Since having only a single predictor/RAS in our protection scheme is sufficient, providing the addresses from both pipelines is unnecessary. Both pipelines should have the same address in a faultless operation. Otherwise, the instruction will be restarted, and the prediction discarded. Chapter 4.2 and the prediction subsection have been reworked to reflect the implementation better.
4. In section 4.4, have you predicted that multiple-bit upsets might occur in a memory word resulting in the checksum not being trustworthy? What will happen if this is the case? Could you elaborate? – Yes, such a situation could happen. For this reason, some scrubbing mechanisms, similar to ACM, should be implemented outside the core to prevent such a situation. We have included Chapter 4.4 to provide the broader picture, but the exact implementation of memory protection is outside the scope of this paper.
5. How did you compare the area and power between dual and triple-lockstep schemes with your approach and found it similar? Have you utilized any specific bibliography? Please clarify. We realized that we needed to provide a deeper comparison with other protection approaches regarding power, performance, and area. In the updated version of the paper, we included such a comparison to the new Chapter 6.3., with appropriate references. Chapter 2.2. has also been improved and contains a description of additional protection approaches.

Reviewer 2 Report

The manuscript addresses a relevant topic “In-Pipeline Processor Protection against Soft Errors” that is inside the scope of the journal, however, the following comments should be solved:

1)      The abstract should contain important results of the study

2)      Improve the figure quality.

3)      Add some comparison results and discussion.

4)      Give a comparison from previous work.

5)      Check for grammar and spellings.

6)      Literature review part is required to be improved.

7)      Result and discussion part is required to be improved.

8)      Equation Part is required to be improved.

9)      State the novelty of your work.

10)   Author should citied the figure and table in your paper content.

11)   Author research should follow the recent year and also compare your results with recent articles.

12)   Conclusion should be improved. I recommend to focus on the prominent points.

13)   More Number of References Should be added in your article.

The English language of the paper must be refined, I recommend to review by native person.               

Author Response

Thank you very much for your feedback and valuable comments. We did our best to address all your points to improve the paper accordingly. The paper has undergone extensive grammar and syntax editing besides the technical points.

Answers to the comments and related improvements:

1. The abstract has been improved; now, it focuses more on main contributions and novelty.
2. Figures 2, 3, and 5 have been slightly changed.
3. Chapter 2.2 now contains a description of additional protection approaches. The updated version of the article includes in Chapter 6.3 a comparison of existing protection approaches (also from recent years) to our protection scheme in terms of power consumption, area, and performance.
4. The discussion chapter better describes the novelty and improvements compared to other approaches.
5. All chapters have undergone revisions to describe the implementation better.

Round 2

Reviewer 2 Report

I checked the revised paper, I confirm that the authors addressed all major changes, I accept to publish the paper in present form.

Minor editing of English language required