Review Reports

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The paper presents the implementation of a heterogeneous high-speed data exchange system using FPGA platforms. The work presented is of an engineering nature, highly specialised and advanced. The scientific contribution is negligible. The work is a continuation of the authors' previous implementations.

From my experience with FPGA/SoC devices and synthesis and implementation systems (e.g. Vivado/Vitis), it appears that the authors put a lot of effort into getting the hardware up and running. Although vendor tools provide a lot of support, rapid technological development means that they are underdeveloped and things simply do not work right away. Usually, a lot of work has to be put into finding the problem and workarounds. I think this was also the case here, although the authors do not boast about it, and it would be very informative for the community.

I believe that the paper may be very interesting for readers, but it requires additions and extensions. Below, I present these expectations and comments of lesser importance.

Required additions:
1.    An extended discussion (separate chapter) related to problems arising during the implementation of the system with the solutions and workarounds used. This is a very important added value for readers. The description of your implementation alone, without this aspect, is merely a demonstration.
2.    In line 347/348, you write: ‘The line rate was set to 20 Gbps, as the 25 Gbps configuration resulted in insufficient eye opening with the existing physical connections’. Please demonstrate the eye diagrams for these systems. 

Further comments:
1.    Chapter 2 seems to have been written and added to the paper by force. It should be properly developed or its content added to other chapters (e.g. the introduction). 
2.    The captions under the figures containing descriptions are not entirely legible and are not commonly used. It is better to include a detailed description in the text where there is a reference to the figure.
3.    The first figure (Fig. 1) is difficult to read. It would be better to draw it by expanding it vertically (e.g. by moving the VCU and SPARK blocks below the network).
4.    The implementation description refers to signals that are not shown in the diagram (e.g. line 325, where there is a reference to user_clk). This is quite confusing, as the reader expects to find them in the diagrams, as suggested by the highlighting in the text.

 

I think it would be advisable to make your projects publicly available as references (via GITHub).

Author Response

Comment 1: An extended discussion (separate chapter) related to problems arising during the implementation of the system with the solutions and workarounds used. This is a very important added value for readers. The description of your implementation alone, without this aspect, is merely a demonstration.
Response 1: Thank you for highlighting this point. In response, we have added a dedicated section (Section 6), titled “Implementation Challenges and Practical Workarounds”, which discusses the key issues encountered during the implementation of the proposed platform along with the corresponding solutions and workarounds adopted. The changes can be found under Section 6 from line 427-489 (page no.13,14 and 15) under the revised manuscript.

Comment 2: In line 347/348, you write: ‘The line rate was set to 20 Gbps, as the 25 Gbps configuration resulted in insufficient eye opening with the existing physical connections’. Please demonstrate the eye diagrams for these systems.
Response 2: Thank you for your insights. In response, we have added eye-diagram comparisons for different physical interconnects (Bullseye-to-FMC and SFP28) and line rates (20 Gbps and 25 Gbps) in Fig. 4, along with the corresponding detailed description. The changes can be found under Section 5 from line 387-399 (page no.11) with Fig. 4 (page no.12) under the revised manuscript.

Comment 3: Chapter 2 seems to have been written and added to the paper by force. It should be properly developed or its content added to other chapters (e.g. the introduction).
Response 3: We appreciate this suggestion. Accordingly, we have revised and rewritten Section 2 to organize the prior work into clear categories and to more explicitly highlight the relevance and contributions of our work relative to the state of the art. The changes can be found under Section 2 from line 88-145 (page no.3 and 4) under the revised manuscript.

Comment 4: The captions under the figures containing descriptions are not entirely legible and are not commonly used. It is better to include a detailed description in the text where there is a reference to the figure.
Response 4: Agree. In response, we have removed the descriptive captions of Fig.1 and Fig.5 and it is referenced and described under Section 3.1 and Section 5 respectively. The changes in the descriptions can be found under in lines 401-402 (page no.11) under the revised manuscript.

Comment 5: The first figure (Fig. 1) is difficult to read. It would be better to draw it by expanding it vertically (e.g. by moving the VCU and SPARK blocks below the network).
Response 5: Thank you for the comment. Accordingly, we have redrawn the figure (Fig. 1) as suggested.

Comment 6: The implementation description refers to signals that are not shown in the diagram (e.g. line 325, where there is a reference to user_clk). This is quite confusing, as the reader expects to find them in the diagrams, as suggested by the highlighting in the text.
Response 6: Thank you for pointing this out. We have added the user_clk and INIT_clk signals in Figs. 2 and 3. The _tvalid, _tdata, _tlast, and _tkeep signals are not explicitly shown in the diagrams, as they are standard AXI4-Stream protocol signals. Moreover, Figs. 2 and 3 have been updated to include the clock sources.

Comment 7: I think it would be advisable to make your projects publicly available as references (via GITHub).
Response 7: Thank you for your suggestion. However, public release of the project via GitHub is not possible due to intellectual property considerations and export control restrictions.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

This article presents the design of two dataflow architectures of multi-FPGA testbeds employed in DSP+AI Applications. They use full-duplex high-speed SerDes connectivity available on Xilinx/AMD RF-SoC and VCU FPGA systems.

The introduction section briefly presents the motivation for the current study, identifies the need for the proposed solution and outlines the article contributions.

The literature review section is very short (less than a page), but the authors manage to capture some essential achievements. Though, the authors fail to compare the proposed solution to the current state of practice.

The third section describes the proposed testbed architecture. The authors provide a high level view of the framework structure. Subsection 3.2 deserves an extended content, being an original contribution of the authors - even if the MVM module is the subject of an accepted article for another journal. Some paragraphs feel like datasheet data: lines 188 - 197.

The digital design aspects are nicely presented in the fourth section, although the section feels more like an engineering report than a scientific article. Again, the datasheet like content is present on lines: 263 - 266, 270 - 273, and more. The figures 2 and 3 clearly present the system-level dataflow.

The experiment setup and results section is very brief: just three paragraphs and four images. Only two use cases are outlined and no limitations are mentioned. It is not clear how the DGX Spark unit contribute to the experimental setup. 

Overall, the paper is well written and compelling, but it feels more as an engineering report than a scientific article. There are no clear comparisons with other systems and the results are very briefly designed and analyzed.

Author Response

Comment 1: The introduction section briefly presents the motivation for the current study, identifies the need for the proposed solution and outlines the article contributions.
Response 1: Thank you for the positive feedback. No changes were required for this item.

 

Comment 2: The literature review section is very short (less than a page), but the authors manage to capture some essential achievements. Though, the authors fail to compare the proposed solution to the current state of practice.
Response 2: Thank you for this suggestion. Accordingly, we have revised and expanded the literature review section by organizing prior work into clear categories and explicitly comparing the proposed solution with the current state of practice, thereby highlighting the significance of our contribution. The changes can be found under Section 2 from line 88-145 (page no.4) under the revised manuscript.

 

Comment 3: The third section describes the proposed testbed architecture. The authors provide a high level view of the framework structure. Subsection 3.2 deserves an extended content, being an original contribution of the authors - even if the MVM module is the subject of an accepted article for another journal. Some paragraphs feel like datasheet data: lines
188 - 197.
Response 3: We appreciate your insights. Accordingly, we have extended Subsection 3.2 by providing a more detailed explanation of the hardware implementation of the MVM core. For additional implementation specifics, the reader is referred to our prior conference publication. The changes can be found under Subsection 3.2 from line 200-207 and 210-211 (page no.6) under the revised manuscript.
Furthermore, the paragraphs in lines 188–197 of the original submission have been revised to remove datasheet-style descriptions, retaining only the information necessary to support the architectural discussion. The changes can be found under Subsection 3.3 from line 216-224 (page no.6) under the revised manuscript.

 

Comment 4: The digital design aspects are nicely presented in the fourth section, although the section feels more like an engineering report than a scientific article. Again, the datasheet like content is present on lines: 263 - 266, 270 - 273, and more. The figures 2 and 3 clearly present the system-level dataflow.
Response 4: Thank you for pointing this out. The datasheet-style content has been removed, and the relevant paragraphs have been revised to include only the necessary information highlighting the compute resources available on each of the FPGA platforms used. The changes can be found under Subsection 4.3 from line 289-306 (page no.7 and 8) under the
revised manuscript.

 

Comment 5: The experiment setup and results section is very brief: just three paragraphs and four images. Only two use cases are outlined and no limitations are mentioned. It is not clear how the DGX Spark unit contribute to the experimental setup.
Response 5: Thank you for this constructive comment. In response, we have extended the experimental setup and results section by adding IBERT-based eye-diagram measurements comparing different physical interconnects (Bullseye-to-FMC and SFP28) and operating line rates (20 Gbps and 25 Gbps), thereby explicitly highlighting the practical limitations of the
testbed and the impact of physical connectivity on link reliability. The changes can be found under Section 5 from line 387-399 (page no.11) including Fig. 4, under the revised manuscript.
Furthermore, recognizing that this work focuses on highly specialized and advanced engineering design aspects, we have added a dedicated section titled “Implementation Challenges and Practical Workarounds”. This section documents the key challenges encountered during system realization, along with the solutions and workarounds adopted. We believe this
addition provides an added value to readers interested in reproducing or extending similar multi-FPGA, SerDes-based compute platforms. The changes can be found under Section 6 from line 427-489 (page no.13,14 and 15) under the revised manuscript. Finally, We have clarified the contribution of the DGX Spark unit by adding experimental validation of its system-level integration, demonstrating end-to-end RF data transfer from the ZCU111 to the DGX Spark platform via the PYNQ framework. This confirms the feasibility of extending the testbed toward AI-native learning and inference, while comprehensive algorithmic evaluation on DGX Spark is deferred to future work. The changes can be found under Section 5 from line 420-426 (page no.13) under the revised manuscript.

 

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

Thank you for the changes. I accept them.

Reviewer 2 Report

Comments and Suggestions for Authors

The authors fairly responded to the requested comments. 

The literature review section was completed with sufficient relevant information organized in multiple categories.

The authors provided a more detailed explanation of the hardware implementation of the MVM core - one of their previous achievements.

The results section is marginally extended. 

The authors added a sixth section dedicated to implementation challenges and practical workarounds where they describe some common but important problems that may arise in such systems.

In current form, the article was changed by adding significant content which makes the whole work more comprehensive. Still, a little more content should be added to the results section.