A New Methodology to Manage FPGA Distributed Memory Content via Bitstream for Xilinx ZYNQ Devices

Round 1

Reviewer 1 Report

The article shows two methodologies for accessing data and managing design allocation through bitstream configuration. The article is easy to follow, well structured and well written. However, there are some issues and detail that, in my opinion, could improve the quality of the paper.

1. The title could be improved to describe, in a better way, which the article proposes.

2. In the introduction I believe that some minor aspects should be improved:
    2.1. line 25-26 "reprogrammable logic" is "programmable logic".
    2.2. line 39 "the price to pay" change for other expression.
    2.3. line 43 "is by using" improve this.
    2.4. line 51 Suggestion to change "This work addesses" to "The main contribuion of this work".
3. In the "existing approaches" section.
    3.1. Only a comparison is made with AMD-Xilinx devices, is there any existing references that do something similar with other devices such as Intel-Altera devices?
    3.2. In this section I think it would be interesting to include a comparative table with previous works and to allow comparison of the proposal made in this article with previous works.
    3.3. line 102: Define ICAP.
    3.4. line 126: "like 7 series" + "from Xilinx".

4. About section "3. Description of the Proposed Approach".
    4.1. I consider that it should be included in some part of the proposal that these implementations are particularized for the Xilinx 7 series. Is the Zynq UltraScale+ series also included?
    4.2. From line 178 it is said that the Zynq PS is used, so what is the point of modifying the bitstream data when it is just as easy or easier to do it directly from the PS using the AXI bus? I may have misunderstood some of the process, but it seems very crafty for the end result.
    4.3. line 188: Define PCAP.
    4.4. Figure 3 is very small compared to the rest of the document and figures.
    4.5. From line 247 to 260 describes the process that has been carried out to determine the blocked content. I consider that this process should be better described and the tests that have been carried out should be developed. At this point I do not know if a "Partial Reconfiguration Bitstream Monitor IP" could be used to verify some part of the process.
    4.6. line 276: Change "has to be download".
    4.7. line 280: The word goes out of the document margins.
    4.8. In point 3.2 the second approach is presented, however, I consider that these two approaches are different or have different objectives. I think this should be made clear somewhere in the document.

5. About section "4. Experimental Setup and Physical Validation".
    5.1. line 373: "Vivado Design Suite (18.2)", I guess the version of Vivado is indicated by the year, 2018.2. Check if it is 2018.2.
    5.2. It is indicated that there is an overhead in the bitstream size when you have protected regions, but this is something obvious, since to protect a region of the bitstream some kind of encryption is used, which causes information to be added to the target file. I would like to know what these results are intended to suggest.
    
6. About section "5. Conclusions and future work" and "References".
    6.1. line 504: "Ultrascale" -> "UltraScale".
    6.2. Regarding references, I think they should be increased (if possible) with related works.
    
7. As a curiosity, I would like to get an answer to the following question: what is the difference between your proposal and the PL reconfiguration done using Pynq?

Author Response

We would like to thank the reviewer for the comments on our manuscript. We believe that the new version of our paper deals carefully with such comments, which are individually addressed in the line bellow. As a result the paper has been extensively improved.

1.We have changed the title to “Novel design flows to manage FPGA distributed memory content via bitstream for Xilinx ZYNQ devices”, which we believe, describes the work more precisely.

2. In the introduction I believe that some minor aspects should be improved:
    2.1. We have carried out the suggested change.
    2.2. We have carried out the suggested change by writing “drawback” instead of “price to pay”.
    2.3. We have carried out the suggested change by rewriting the sentence.
    2.4. We have carried out the suggested change.
3. In the "existing approaches" section.
    3.1. The comparison has been focus on Xlilinx devices because the presented approach is based on manipulating the bitstream of this vendor’s FPGAs. The structure of the bitstream is tighly related with the each vendor’s technology, and for this reason we have considered that solutions for other vendor’s devices are out of the scope of this work. Nevertheless, following the idea suggested by the reviewer we have searched in the literature for similar approaches on Intel-Altera devices, but we haven´t been able to find any.
    3.2. Following the suggestion made by the reviewer we have added a table summarizing the presented existing alternatives.
    3.3. We have carried out the suggested change by defining the ICAP interface.
    3.4. We have carried out the suggested change.

4. About section "3. Description of the Proposed Approach".
    4.1. We have carried out the suggested change by rewriting the introduction paragraph of the mentioned section. Regarding the question about UltraScale devices, despite the approach has been focus on ZYNQ devices it is suppose to be valid for UltraScale devices (likely requiring some adaptations) because they share the main features of the bitstream structure. Nevertheless, as it has been mentioned in the “Conclusions and Future Work” section this is something that would be addressed in future works.
    4.2. Although the approach proposed by the reviewer is an interesting alternative, in some cases the use of the bitstream provides certain specific benefits that, depending on the application case, could be more interesting. In addition  the use of the the PS of the ZYNQ enables to read, edit and write the bitstream in an autonomous way and it permits to access and control both logic resources and the used primitives (STARTUPEE2 and CAPTUREE2 primitives) through the EMIO interface. We have extended the final part of the introduction section presenting some examples of the potential benefits offered by the proposed methodology.
    4.3. We have carried out the suggested change by defining acronym of PCAP.
    4.4. We have carried out the suggested change by increasing the size of the figures.
    4.5. In order to improve the manuscript we have modified and extended the mentioned paragraph by adding new explanations and changing the way of explaining the process utilized to reach the results. Regarding the “Partial Reconfiguration Bitstream Monitor IP” (which it seems that it has been discontinued and substituted by the “Partial Reconfiguration Bitstream Monitor IP”), as far as we have investigate, it does not provide the functionality that we have described. However, we consider that this proposed IP could be interesting tool to expand the approach’s functionality at higher level applications for future works.

    4.6. We have carried out the suggested change by writing “has to be loaded”
    4.7. We have carried out the suggested change by breaking the mentioned word.
    4.8. In order to improve the manuscript following the suggestion provided by the reviewer we have added an extra explanation describing both proposed approaches at the end of the introduction section.

5. About section "4. Experimental Setup and Physical Validation".
    5.1. We have carried out the suggested change by writing “2018.2” instead of “18.2”.
    5.2. In order to clarify the implications of increasing the size of the bitstream we have added the following text to the manuscript: “Although this size increase of the bitstream usually does not suppose a remarkable drawback, in some cases this is an aspect that could be relevant due to the effect of the size of the bitstream in the storage requirements and in the time necessary to program the device.”
    
6. About section "5. Conclusions and future work" and "References".
    6.1. We have carried out the suggested change.
    6.2. Following the suggestion made by the reviewer we have upgraded the manuscript by adding five extra references.
    
7. We would like to thank the reviewer for this interesting question. In this sense, we would say that the main difference is that our approach has been developed by using Xilinx functions (based on C language) to read, process and write the bitstream. We are not sure if a Python based PYNQ alternative could improve the bitstream manipulation time demand (one of the most critical aspects of the approach). However, probably a PYNQ based alternative could be very interesting to extend the functionality of the approach. Hence, it is an interesting alternative that we should study for the future work.

Reviewer 2 Report

After review this work:

There is no novel contribution to the FPGA state of the art. Moreover, there is no complex electronic implementation just configuration without significant modifications of Xilinx files.

I can not recommend this work for publication

Author Response

We are sorry for not fulfilling the expectations of the reviewer. We hope that our future works will be of greater interest to the reviewer.

Reviewer 3 Report

In the paper "Managing FPGA distributed memory content via bitstream" the authors propose a relatively new method (essentially inspired by more or less identical implementations - specific to other FPGA versions) well grounded and experimentally validated. The work is well written, the only negative aspect is the graphic nature. I recommend enlarging the figures (1, 4, 5) or reconfiguring them vertically (3). For figure 2 and 9, I recommend a background of another color or a border. 

Author Response

We would like to thank the reviewer for the provided comments because thanks to them we have improved the manuscript by increasing the sizes of the figures and by adding borders to the suggested figures.

Round 2

Reviewer 2 Report

With respect, the work is not suitable for publication.

Author Response

We would like to thank reviewers work and to mention that we sincerely respect its assessment.

Nevertheless, we would like to comment that our approach addresses the user data management through the bitstream in a new manner. Compared with the BITMAN approach (which is the only identified remarkable existing alternative standalone solution available for 7 series devices), our approach offers a solution that requires less resources and time. This is  because while BITMAM tool is Linux OS based high level approach that requieres a more complex processing and time (in the order of seconds), our solution is a low level methodology based on Xilinx functions that requires less memory, processing and time (milliseconds).

This proposed methodology has been detailed, discussed and validated in order to provide an alternative tool for designers.

Thanks to the reviewer's report  we have modified the conclusions section pointing out the mentioned benefits of our approach.

Round 3

Reviewer 2 Report

No substantial modifications were made by the authors.

In my opinion, there is no novel contribution.

I do not recommend publishing this work.