Next Article in Journal
Two Stage Continuous Gesture Recognition Based on Deep Learning
Previous Article in Journal
Transformer-Based VCO for W-Band Automotive Radar Applications
 
 
Article
Peer-Review Record

A Highly Configurable High-Level Synthesis Functional Pattern Library

Electronics 2021, 10(5), 532; https://doi.org/10.3390/electronics10050532
by Lan Huang 1,2,‡, Teng Gao 1,‡, Dalin Li 1,†, Zihao Wang 1 and Kangping Wang 1,2,*
Reviewer 1: Anonymous
Reviewer 2: Anonymous
Reviewer 3: Anonymous
Electronics 2021, 10(5), 532; https://doi.org/10.3390/electronics10050532
Submission received: 10 January 2021 / Revised: 8 February 2021 / Accepted: 20 February 2021 / Published: 25 February 2021
(This article belongs to the Section Computer Science & Engineering)

Round 1

Reviewer 1 Report

The idea of this research is to provide a library of functional patterns that allow to describe the parallel and pipelined implementation of algorithms at a high level of abstraction. 

The idea is interesting because the functional design abstraction level may ease the designer task and the parametrized, hardware aware,  implementation of such patterns provides a flexible interface to HLS.

The proposed patterns describe concurrent data-flow dependency free operations. In this regards, I think that it is relevant to discuss whether such a set is capable to describe any data-flow or not. In addition, you should discuss how to use such patterns in a HLS context where some part of the circuit must be described using traditional approaches. 

The interaction between the proposed patterns and HLS optimization techniques is also not clear. Consider for instance a case where the algorithm contains common sub-expressions possibly resulting in hardware savings. Suppose that the designer is not aware of this and uses your patterns to specify a coarse grained parallel architecture. Can optimization still take place in this case? 

A formal description of the algorithms used as examples would help the reader. 

The manuscript contains several typos and lower case acronyms with no explanation. 

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

The paper presents a functional pattern library suitable for high level synthesis. The presented functional patterns are novel, they have a great potential to be widely used for HSL, though the content of the paper must be improved. Thus, my recommendation is "Major review".

A few Observation:

  1. The formulation of the ideas should be much more concise. 
  2. There are a few paragraphs that can be removed completely. For example:
    1. in section 2: "Moreover, the HLD tool chains ... developping the code directly." This is true, but out of the point.
    2. in section 2: "The latest generation of xilinx HLS ... hot trend in EDA software." True, but is feels like hidden Xilinx advertisement.
    3. in section 5.1 : "The benefits of function-oriented programming .... returned as a result of other functions". This is true, but un-useful.
  3. The fonts in Figure 3 are too small, it cannot be read.
  4. The most important issue to address in this paper is the comparison. In the paper, a comparison is made between an FPGA implementation based on the proposed HLS method and a computer-based software solution. I think this comparison is inadequate, it is like comparing cats and dogs. A fair comparison would be another FPGA based implementation achieved by another HLS (i.e. Xilinx HLS). 

 

Author Response

Please see the attachment.

 

Author Response File: Author Response.pdf

Reviewer 3 Report

The paper tackles a relevant topic related to high-performance parallel pipelined computing models based on Xilinx FPGA, Vivado HLS and MapReduce. In this context, the authors propose and validate a set of functional patterns library implemented by C++ templates based on the MapReduce model. Based on experiments and tests, the authors can quickly implement high-performance parallel pipelined computing models on FPGA circuits.

Section 1 “Introduction” and 2 “Related Work” are well presented, including aspects regarding the RTL, HSL (Lift, Chisel, Bluespec, SpinalHDL,..), benchmark, and FPGA implementations. The paper is relatively full, however, it needs some improvements:

  • Avoiding acronyms in the abstract is also encouraged.
  • Hardware description language (HDL) must be specified only once (line 27, 105); register transfer level (RTL) – line2 and 105,..
  • The improvements achieved with the presented project should have been more clearly highlighted.
  • Figures 3 and 6 can be presented in more detail;
  • The implemented project is validated on the Xilinx Kintex FPGA circuit. How would this complexity reflect in the simulator? No Pre and Post-Synthesis simulation, report Power, or report Timing Summary was presented.
  • The implemented project uses the Kintex FPGA. How does this compare with other FPGAs (Xilinx Zynq-7000 SoC ZC702)? How would this complexity reflect in the ASIC implementation?

Author Response

Please see the attachment.

 

Author Response File: Author Response.pdf

Round 2

Reviewer 2 Report

The authors partially answered my concerns. Again, I consider unfair the comparison of a hardware and a software solution, no wonder a x100 speedup is achieved and claimed. The authors misunderstood my observation, I did not ask them the reimplement particle swarm optimization (PSO) in Vivado XLS. I was suggesting searching for similar implementations that used any other HLS, not Xilinx HLS necessarily. Moreover, there are two algorithms: (i) Sum of vector distances squared and (ii) PSO. Probably, to implement algorithm (i) in Vivado HSL (or any other HLS) is not a major overhead.

Author Response

We are very sorry that we misinterpreted your point, as you said the comparison between software and hardware solutions is really unfair. We realized that we had to compare ourselves with others at the software level and we found the relevant work of our peers: we have similar function and algorithm designs and compared them on the most important advantage of the library: ease of use, and our work is more complete compared to theirs. (add between 385-395 lines). Besides we use the two algorithms in the text just to demonstrate the advantages of our function library in the data processing mode of large-scale data, for the manual use of HLS to implement these two algorithms need to consider a lot of details (like Treeop such as the division of data), the need to adjust the size of the division only need to change the parameters in the function, it is very convenient to use.

 

Reviewer 3 Report

I think that the paper can be accepted.

Author Response

Thank you very much for your recognition of our work!

 

Round 3

Reviewer 2 Report

Indeed, it is difficult to compare two methodology, but it is not impossible. Just because I’ve seen much worst papers published, my recommendation is "accept after minor revision", but otherwise I would reject it because of the lack of comparison.

Back to TopTop