The Firmware Design and Implementation Scheme for C Form-Factor Pluggable Optical Transceiver ^†

Round 1

Reviewer 1 Report

The authors present a methodology in firmware implementation for optical communication devices in particular for future transceiver and 5G .

At line 50 the authors state:" Therefore, manufacturers must invest money
 and development time to design firmware when developing optical transceivers. "

I think the authors under estimate greatly the amount of money poured in this kind of development. The fact that companies do not speak about it does not mean that they are not doing it.

I would suggest to remove this statement or at least give solid proof of it.

In general the work presented by the authors is sound but as always with papers on firmware or software, it is difficult to judge without seeing the code or at least have a demo. I would encourage the authors to publish their work on github for example if they don't have IP issues.

Is the link between the FPGA and MCU based on SPI communications?

In table 3 state the parts for ease of the reader used since they can be seen on the picture of the board.

Is there any reason why the author used an 8051 architecture instead of a RISC or ARM?

The proposed framework is shown to provide some important advantage in terms of performance but there is no mention on safety.

In particular, no encryptation of other signing techniques are mentioaned to safeguard the firmware.

The authors acknowledge in their conclusion that they did not consider remote update of the firmware which in many applications is a key part.

Is there a way to daisy chain their board in order to expand it beyond the proposed channel counts?

Author Response

We apologize for the delay in taking additional experiments and editing the document.

Please note that the pictures in the paper have been added and grouped.

Please see the attachment.

Thank you.

Author Response File: Author Response.docx

Reviewer 2 Report

This manuscript is regarding a firmware design for C Form-Factor Pluggable Optical Transceiver; the authors try to propose general design rules for this particular task, this idea is great and interesting.  However, the authors fail to present their ideas clearly in this manuscript and make this paper read as a  manual.  Strongly suggest the authors should provide clear descriptions of the improvements to highlight the value of this study. In addition, there are some concerns the authors need to improve;

1. Some abbreviations and terminologies are used without giving full names or definitions.
2. Line 210-216; Where does the LUT storage and when the DDM value will be corrected by LUT?  Would the properties of the optical component be changed because of aging and how to detect the change if the DDM calibration outcome is always corrected by data from LUT?
3. Regarding the firmware-hardware reliably evaluation, the test is based on any available standard or a method proposed by the authors?
4. As the authors mentioned that the properties of the optical component (fiber) are temperature dependent, whether there is any function of the testbed setup that can reflect the needs?
5. More details should be given for the testbed shown in Figure 10.
6. Figure 15 shows the data for 48 sec which cannot support that the reliability test results for 72 hours concluded in this paper.
7. Line 284-287; part of the discussions cannot be understood from Figure 16! For example, it is impossible to know the accuracy of channel 4 is 93.4%; the accuracy is highest when the power of -9 dBm is also ambiguous.
8. The authors summarize the advantages of the proposed firmware design method in Table 4; unfortunately, there is no corresponding data or discussion which can support the authors' claims.
9. Expecting to have more discussions regarding the Rx power DDM Accuracy comparison; for example, the main differences for the proposed method and existing CFP 1 and 2, why the proposed method and existing CFP 1 possess higher accuracies in channel 4 but existing CFP 2, and others.  
10. As the authors mentioned the firmware design is 100Gbps CFP, and then declare that the proposed techniques can be applied to the development of 200/400 Gbps in the future without addressing the possible technical barriers. 

Author Response

We apologize for the delay in taking additional experiments and editing the document.

Please note that the pictures in the paper have been added and grouped.

Please see the attachment.

Thank you.

Author Response File: Author Response.docx

Reviewer 3 Report

Your paper entitled “The Firmware Design and Implementation Scheme for C Form-Factor Pluggable Optical Transceiver,” is very interesting.  The telecommunication industry can benefit from a 100 Gbps C form-factor pluggable (CFP) optical transceiver with enhanced quality and reduced cost.   Your novel approach of employing a C form-factor pluggable (CFP) firmware design, based on the multi-source agreement (MSA) standard (an industry standard), represents a design method for the entire operation of the optical transceiver.   

My comments/recommendations are provided below.

• In your introduction, you mentioned that the firmware designed by existing CFP transceiver manufacturers is based on industry standards, but manufacturers do not disclose their design techniques.  Recommend that you discuss how this problem is solved using your design approach.
• In your conclusion, you mentioned that a comparison of the performance of your proposed firmware was made with that of the CFP transceiver of an existing product.  Recommend that the difference shown in Figure 17 be mentioned in the conclusion.
• Recommend that the word “The” be changed to “the” in line 4 (page 1).
• Recommend that the period following Figure (e.g., Figure.1) be removed (e.g., Figure 1) in lines (67, 84, 105, 116, 142, 172, 185, 231, 247, 250, 263, 267 twice, 271, 275,283, and 288).

Author Response

We apologize for the delay in taking additional experiments and editing the document.

Please note that the pictures in the paper have been added and grouped.

Please see the attachment.

Thank you.

Author Response File: Author Response.docx

Round 2

Reviewer 1 Report

The authors answered all my questions. Concerning the numbering the parts I was referring to the chips your are using specifically and their alphanumerical code. On the picture, it is possible to read it by zooming. So I guess it is not an issue to actually mention those part numbers in the text in clear.

Author Response

Dear reviewer.

Thank you for your careful review and kind response.

Reviewer 2 Report

The authors properly reply to the concerns and change the article accordingly. In this version, no additional technical issue has revealed.    

Author Response

Thank you for your review and kind reply.