Ethernet Packet to USB Data Transfer Bridge ASIC with Modbus Transmission Control Protocol Based on FPGA Development Kit
Round 1
Reviewer 1 Report
What are the additional ways in which the paper could be improved: Some comments are given in the following. 1.1.In the abstract, some disadvantages are given (The first sentence). In this manuscript, proposed architecture are introduced. Do the disadvantages belong existing method? If possible, some detailed explanations are suggested. Furthermore, some existing works or experiments are required to support these points.2.ack of literature review , author did not well analyzed the existing work limitations.
3.figure 7 steps detail unclear. Figure 6 need more detail explanation.
4.simulation parameters did not well discuss need detail explanation.
5.figure 9 the circled steps should be given without the step number, which may cause confusion.
Author Response
Please see the attachment.
Author Response File: 
Author Response.pdf
Reviewer 2 Report
The paper presents a solution intended to translate the Ethernet Modbus TCP packets into the data transmitted via USB.
After reading the paper, it seems that the general idea was to provide an energy-efficient device that receives the Modbus TCP packet and sends it as a USB packet (probably as a Modbus RTU message, but it is not clearly stated in the paper). Similarly, it should receive the USB packet (again, a Modbus RTU message?) and transmit it as a Modbus TCP Ethernet packet.
The title of the paper is, however, unclear - "Ethernet Packet to USB Data Transfer Bridge ASIC with Modbus Transmission Control Protocol for FPGA-Based Hardware Implementation". If the paper describes the ASIC, why does it say it is dedicated to an FPGA-based implementation?
The authors use the CYUSB3014 chip ( https://www.infineon.com/dgdl/Infineon-CYUSB301X_CYUSB201X_EZ-USB_FX3_SUPERSPEED_USB_CONTROLLER-DataSheet-v01_00-EN.pdf ). They do not describe the software running on CYUSB3014, so probably the FIFO mode is used.
That statement may be supported by the description in lines 136-146, and by comparison of Figure 4 in the reviewed paper with Figure 2 in https://www.infineon.com/dgdl/Infineon-AN65974_Designing_with_the_EZ-USB_FX3_Slave_FIFO_Interface-ApplicationNotes-v17_00-EN.pdf .
I'd suggest that the authors should clearly describe in which mode the CYUSB3014 is used and reference the appropriate documentation.
The authors describe how the processing of the Ethernet packets is performed in the FPGA or ASIC. They describe handling the ARP requests and replies and handling the TCP packets with data.
However, there is a very serious problem with that implementation. The TCP protocol with confirming packets and retransmission of non-confirmed packets is not implemented. If the ASIC/FPGA really works as described, the computer won't receive confirmation of the transmitted packet and will keep retransmitting it until the transmission error is detected.
The presented implementation may work with Modbus UDP but not with Modbus TCP. That clearly contradicts what the authors claim in Table 2.
The paper also contains a few less important inaccuracies.
In Figure 1, the PC in the top-right corner is connected via an Ethernet/USB3.0 bridge. Isn't it equipped with a standard Ethernet network adapter?
The statement in line 82: "Two SRAMs are used to improve the frequency incompatibility between Ethernet and USB." - what is the "frequency incompatibility"?
In lines 110-112: "The GMII module is responsible for transforming the Ethernet packet into the GMII interface standard format and transmitting the packet to the GMII interface with the Ethernet PHY chip" - there is no "GMII interface standard format". That module simply transmits the Ethernet packet via the Ethernet PHY chip using the GMII interface.
The authors use the name "photoelectric converter" for Ethernet Fiber Media Converter. The "photoelectric converter" is a detector converting the light into an electric signal.
Figure 15 does not show how exactly the components of the verification setup are connected. I think that this figure should be accompanied by a connection diagram similar to Figure 1.
The paper requires a major revision to remove the listed essential inaccuracies.
In particular, the authors should either add support for TCP protocol, or clearly state that the solution supports only Modbus UDP.
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Reviewer 3 Report
This paper presents an Ethernet packet transformation and transmission architecture between Modbus transmission control protocol (Modbus TCP) and universal serial bus (USB) 3.0 developed with a field-programmable gate array (FPGA) development board. The paper is well written and the analyses along with the results are well expressed. These are some of the comments that need to be addressed.
1. The presentation contains several grammar errors; English must be improved too.
2. Abstract: should highlight the main idea of the method; specifically, what is novel.
3. Introduction: needs a stronger motivation.
4. Related work: missing, focus on recent works.
5. Quality of figures and tables are rather poor; some drawings are stretched; some are too small (Fig. 7 , Fig. 10 for example).
6. Experimental results: How it is superior to reported in [10] - [14]. [12] and [13] haven’t implemented on Hardware.
7. What is the reason to prefer TSMC 0.18-μm CMOS process?
8. Citation is missed for Table 1.
9. Experimental results: Why both FPGA and CMOS required?
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Round 2
Reviewer 1 Report
All comments are well addresses.
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Reviewer 2 Report
The authors have considered most suggestions. However, there is one point where they refuse to accept them. This is a question whether the proposed solution implements Modbus UDP or Modbus TCP.
The essential difference between the UDP and TCP protocols is that while UDP offers only the best-effort unreliable transport of UDP datagrams, the TCP provides reliable data transfer. The reliability is ensured by mechanisms based on acknowledgment/retransmission. Generally, each transmitted package must be confirmed by the recipient. If it is not confirmed, it must be transmitted again. That is described even in the basic definition of TCP protocol:https://www.rfc-editor.org/rfc/rfc793 , sec. 2.6 (later, much more sophisticated algorithms have been proposed, e.g., https://www.rfc-editor.org/rfc/rfc2018 ).
Another level of complexity is introduced by the fact that TCP is a stateful, connection-based protocol. The authors do not describe at all how their FPGA firmware handles the TCP connection.
Generally, the implementation of TCP in FPGA is not a trivial task. Certain attempts to implement a subset of TCP sufficient to establish a connection with PC and transmit data are described in doi:10.1088/1742-6596/513/1/012042 .
The simplifications were quite serious (see Figure 2 in doi:10.1088/1742-6596/513/1/012042). However, the basic functionalities, like: reliable and in-order transmission, flow control, and congestion control, were implemented.
The description given by the authors does not show how FPGA retransmits the packets that were lost (due to possible transmission error in Ethernet).
Neither it explains how the packets transmitted from PC to FPGA are confirmed. Without such confirmation, the PC would continue retransmitting the packet, and finally, the communication will be broken.
Output from Wireshark presented by the authors does not prove the correct and full implementation of the TCP protocol. Below I show an example of TCP packets related to the mentioned acknowledgments:
In fact, the picture provided by the authors in their response raises further doubts:
If this is a packet captured during the normal operation of their system, why is this a "FIN" packet? Such packets are transmitted to finish the TCP connection. Here again, we return to the question, how does the authors' firmware handle the TCP connections?
Modbus over TCP/IP requires a connection-based reliable connection. In https://modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf we find:
In point 4.2.1.1:
"A MODBUS communication requires the establishment of a TCP connection between a Client and a Server."
In section 4.3, there is a clear statement:
"For more information, the advice is to read the RFC 1122 that provides guidance for vendors and designers of Internet communication software. It enumerates standard protocols that a host connected to the Internet must use as well as an explicit set of requirements and options."
In the referenced https://www.rfc-editor.org/rfc/rfc1122 , section 4.2 describes the required functionalities. Without them, the claim that the presented solution implements Modbus TCP is unjustified.
Maybe the authors have found a way to use the TCP/IP protocol in a simplified way (similarly to what the authors of doi:10.1088/1742-6596/513/1/012042 have done). If that's the case, explaining how it was possible would make the paper even more interesting.
Unless a more detailed description of the TCP/IP stack implementation in the authors' firmware is provided, the paper allows to claim that the solution implements "the connection-less Modbus UDP protocol" but not "Modbus TCP".
Except for this issue, the paper may be considered ready for publication.
However, the above-described correction still requires a major revision.
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Round 3
Reviewer 2 Report
As the authors clearly state in the response to point (1), Modbus TCP is implemented in the Application Layer and requires a fully functional TCP transfer layer.
Acknowledging the received packets is an essential part of the RCP specification.
Figure C in the authors' response shows just the connection's establishment and termination. Anyway, sending the message acknowledgments is an essential part of the communication (denoted by ACK).
Analysis of the packet transmitted from the FPGA to the PC (Figure 19 in the manuscript) shows that, indeed, the packet contains the acknowledgment.
However, in that case, storing the sequence number and using them to generate acknowledgments should be shown in figures 8 and 9.
Why have the authors not described that important detail?
Regarding the retransmission of unacknowledged packets, the authors respond:
"A CRC check code is used to guarantee the correct
transmission. The packet retransmission does not occur because that the transmitted environment is set correctly. If the communication is failed, the following verification will be stopped. This means that the retransmitting phenomena does not happen."
It is difficult to agree with the above statement. Each Ethernet link has a non-zero bit error rate. Its value depends on the kind of link. In 100BASE-T copper link it was ca. 10^(-8), in 1000BASE-X it may be of order 10^(-12). Anyway, it means that the risk of not receiving the correct packet exists.
That's why providing the retransmission of not-acknowledged packets is necessary for granting reliable data transmission, which is the essential part of the TCP specification (see https://www.rfc-editor.org/rfc/rfc793#section-2.6 )
In response to point (4) the authors state: "The motivation of this article is to design and implement a bridge ASIC, which is used to transform and transmit the Modbus TCP packet to USB data, and vice versa. The FPGA board is used to verify the designed functions and the Wireshark software is used to analysis those received packets. In this study, we do not suspect that the received packet is Modbus TCP packet because the protocol is TCP displayed with Wireshark software. Here, we do not pay attention to the transmitted machenism between PC and FPGA board. This article is focused on hardware implementation. The firmware implementation does not fall into our research field. Maybe the future work needs to extend to the firmware implementation."
It is difficult to accept that statement. The ASIC implementation is the hardcoded functionality previously tested in FPGA. Further "extension firmware implementation" will require redesign of the ASIC.
What's important, the necessary retransmission mechanism must be implemented in hardware.
I can see a justification for such non-reliable transport (but can it still be named TCP?). The "Modbus over serial line" specification ( https://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf ) accepts the situations where the frame is not received either by the slave or by the master, and the timeout occurs (see Figures 7 and 8, and Section 2.6 in the referenced specification).
If the authors' solution is just a "Modbus RTU over (limited - due to lack of retransmission) TCP", then indeed, it may work using the timeout-handling and error recovery mechanisms built into the "Modbus over serial line".
However, in that case, it is very important how such packet loss affects the connection's state. Have authors checked what communication delays result from a loss of a packet?
Summary
The authors should clearly state that their solution (either FPGA with firmware, or ASIC) implements the packet acknowledgment, and it should be shown in Figures 8 and 9.
The authors should clearly state that their solution does implement the retransmission of not-acknowledged packets and hence does not ensure reliable transport of messages. They should also explain how the loss of the packet in either direction is handled by Modbus protocol.
The above corrections may be considered a "minor revision".
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
