-
Notifications
You must be signed in to change notification settings - Fork 0
Review of Guideline #21
| Item | Outcome |
|---|---|
| Guideline complies with the Guideline-Template | Yes |
| Name of guideline responsible with affiliation is clearly stated | Yes |
The audience is HLS developers, which refers to Application developers category. I would remove System architects as this is more about code development and optimization than system architecture.
There is no expertise specified. The expertise is HLS development, so again Application developers category.
I would only keep the following:
| Item | Value |
|---|---|
| Guideline Keywords (Category) | code optimization, FPGA |
The guideline is a good example of an HLS problem that one can find while coding an application. This explains how to implement conditions in hardware. If you would have to implement it in VHDL, you would write it naturally like in the solution because you always compute everything in parallel and you only select the result you want with a MUX at the end. But HLS is often written by software engineers that will implement it like a software processor, saving CPU time. The level of genericity is right while it can be used anywhere.
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)?
There are no section in the book about HLS implementation. This guideline deals with optimization of the application through HLS and the problems one can encounter while implementing a branch. Since it is about implementation and performance, it could be referenced in chapter 5 about performance analysis.
The chosen example is about how to mix two pictures in the display, taking the half top of the first picture and the half bottom of the second picture. While it is unlikely that one will have to do it in a real application, the problem still remains when you have to compute two different things in two different branches of your application. The benefit should be better explained, not only around the chosen example, but also as a general way to write this kind of function. The benefit is actually to avoid a bug, difficult to figure out.
-
Guideline advice: Very clear
-
Insights that led to the guideline: Also clear, I like the fact it is linked with a real case and not an abstracted view of a potential case.
-
Recommended implementation method of the guideline along with a solid motivation for the recommendation: Very clear and detailed.
-
Instantiation of the recommended implementation method in the reference platform: Not clear enough. We must not explain "how it is implemented in the application" but "how it is implemented in the reference platform". Is there something the toolchain could detect here? If we have some generated code; where there is a branch, it should implement this method.
-
Evaluation of the guideline in reference applications: As I understand, the current evaluation is done in a use case. It was then evaluated that it solves the problem. This should at least be written here. If there is a link with the reference platform (see point 4 above), it should be made clear how it was used from the reference platform to the given application. Doing it manually might not be enough.
-
References: I am pretty sure there are Xilinx reference to explain this problem; it might be good to refer to them. Guideline #8 could be linked with guideline #21 as they both refer to HLS implementation tricks.
- 30/07/2018: Made some formatting changes in the guidelines to cope with template.
- 30/07/2018: guideline reviewed.
TULIPP Guideline Wiki