Review of Guideline #47

Formatting

Item	Outcome
Guideline complies with the Guideline-Template	Yes
Name of guideline responsible with affiliation is clearly stated	Yes

Is the audience of the guideline correctly specified?

Yes. The guideline deals with partial reconfiguration of FPGAs which is dedicated to both HW designers and application programmers.

Is the expertise required to write the guideline correctly specified?

Yes. It is required to have HW design knowledge and expertise. The guideline assumes that the operating system already manages partial reconfiguration in FPGA. Therefore OS designer expertise is not required.

Are the keywords well selected?

Yes.

Are parts of the guideline too generic or too specific?

The guideline has both a generic part and a Xilinx specific part.

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)?

No. There should be a pointer to the interfaces between the operating system and the hardware. In chapter 6 with HW platform interfaces and OS interfaces (6.2). The D1.3 does not tell how to deal with partial reconfiguration and the development process shall be adapted to take it into account. As D1.3 refers to SDSoC for HW implementation, this guideline should also explain if it is possible to address SDSoC with partial reconfiguration or not. And if yes, how.

Does the guideline specify the work done in the project that can benefit from the guideline?

The guideline says a proof of concept has been done implementing partial reconfiguration with both Hipperos and FreeRTOS, but does not explain the benefits of this implementation compared to other choices. It might be interesting to know the difficulties faces by the developers while they were implementing partial reconfiguration with these two OS. And how they overcame the difficulties.

Other comments

1. Guideline advice:
   A sentence to introduce the guideline would be appreciated.

2. Insights that led to the guideline:
   The insight is clear. And explains why you need to have a development process.

3. Recommended implementation method of the guideline along with a solid motivation for the recommendation:
   There is a method described. It might be good to have a few more explanation of each step. If there are some loops, then make them clear, like:

For each IP to introduce in the reconfigurable area, Do:

While the static HW design does not work, Do:

Develop the IP RTL code
Test the static HW design

Done While-loop

Done For-loop

4. Instantiation of the recommended implementation method in the reference platform:
   The guideline says it has been tested with two operating systems but does not explain how it is implemented with the reference platform. i.e. how it is implemented with Hipperos. Is it taken into account by the operating system, and how.

5. Evaluation of the guideline in reference applications:
   It would be interesting to describe more how the evaluation was done. How are we sure the method described has worked as expected. We assume development risks were avoided using the method. How many bugs did you find using the static design and how many did you find while in partial reconfiguration? Were there only SW bugs remaining?

6. References:
   Very good set of reference + link to another guideline.

Track changes:

1. 19/10/2018: Guideline uploaded.
2. 17/01/2019: Guideline reviewed.
3. 18/01/2019: g´Guideline updated.