Review of Guideline #32

Review of Guideline #32

Formatting

Item	Outcome
Guideline complies with the Guideline-Template	No, but I updated it!, so... Yes!
Name of guideline responsible with affiliation is clearly stated	Yes

Is the audience of the guideline correctly specified?

The current specified audience is System architect.

Even though this is dealing with hardware (i.e. VHDL) and software, I would still recommend to target Application developers as this inlining choice is what they will face when implementing the application on the Tulipp hardware instance (a.k.a the Tulipp hardware platform).

I would also add Toolchain designers as they have to understand what they can do to optimize the code without breaking performance.

So, I would say the following:

Item	Value
Guideline Audience (Category)	Toolchain designers, Application developers

Is the expertise required to write the guideline correctly specified?

The required expertise is currently not specified. I realize that we miss two categories of experts:

• the hardware developers: the one that can develop VHDL code and know how to deal with synthesis, mapping, routing and timing issues. These people are now the one that have evolved to understand how to write "C" code optimized for hardware, in order to use High-Level-Synthesis tools (HLS).
• the software developers: Here I mean "embedded" software developers. The one that can develop code that runs just fine on low-sized-memory system and that knows about scratch pad memories, interrupts, real-time, assembly code and how to optimize the source code to do the same thing ten times faster.

We are not going to re-define the categories. According to the definitions of our expertise categories, I would recommend Application developers.

So, I would say the following:

Item	Value
Guideline Expertise (Category)	Application developers

Are the keywords well selected?

YES. This guideline is about how to optimize the source code on a Zynq in order to execute better without breaking the pipeline.

Item	Value
Guideline Keywords (Category)	Code Optimization

Are parts of the guideline too generic or too specific?

Note: If too specific, also check and add advices : how the guideline could be extended? Note: If too generic, then it is meaningless. Give hints : how to improve the impact?

The guideline is specific because it deals with HSL on Xilinx targets. But it is generic enough because the explanation is true for any Xilinx target on which we use HSL.

Does the guideline explicitly refer to the handbook? To which part of the deliverable is it relevant (e.g., chapter of D1.2/D1.3)?

If no, what parts of D1.2/D1.3 should it refer to. You must evaluate and give a clear answer to help the guideline author to create a link with the handbook.

The guideline does not refer to the handbook.

There should at least be a reference of this guideline in chapter 5 while it deals several time with HLS programming. If D1.3 include a section about code optimization, it would also be a right place to refer the handbook; optimization is, however, currently also covered by chapter 5.

Other comments

1. Guideline advice: Is short, so it is good, but I would state that it deals with FPGA, may be even Xilinx FPGA.

   When I first read the guideline, I only understood we speak about FPGA when I came to read the Recommended implementation method. We might also state that in the title, replacing "Ensure Dataflow by using Inline Subfunctions" by "Ensure Dataflow in FPGA by using HLS Inline Subfunctions"

2. Insights that led to the guideline: The insights section is good. I would keep it the way it is, but I would also add some information to explain how one can come to the idea that the cause of the problem is a broken dataflow pipeline.

   It is not clear if there is a message during synthesis or any step to produce the bitstream or if it is only at execution time that we see the problem. Is it possible to see the problem through any report, or during simulation?

3. Recommended implementation method of the guideline along with a solid motivation for the recommendation: The current text explains what to do to inline a subfunction and what might be the drawbacks.

   The reference given in this part should be moved to the Reference section of the guideline. I could also be good to explain how to see that the pipeline is broken and how we can know that the guideline will be useful.

4. Instantiation of the recommended implementation method in the reference platform: The current text does not explain what we have done concretely in the project to make use of the guideline. It guides the reader again to the Xilinx example, but here, it should be explained what has been done "in the reference platform".

   As I understand the guideline, since it deals with how to implement the application, there is no actual implementation in the reference platform.

   However, is there something done in the toolchain? It is taken into account in the toolchain?

   • If yes: Then we must tell how.
   • If no: Then we must tell why and if it will be implemented one day or taken into account.

5. Evaluation of the guideline in reference applications: This guideline is actually used in a use case: A GOOD POINT!

   It could be good to explain the gain we have had using the recommendation of this guideline: processing time or what ever the KPI is should be given before and after using the guideline on the concrete example of one of the use case (the UAV use case here).

6. References: The Xilinx document should be referenced here.

Track changes:

1. 23/07/2018: guideline reviewed. Format updated according to template.