The main advantage of auto-restarting HLS designs is that they run semi-autonomously operating as data-driven without the need for frequent interaction with the software application or for software control. But auto-restarting kernels also offer semi-synchronization through a feature known as the mailbox, which provides the ability to exchange data with the software application in an asynchronous, non-blocking, and safe way.
Once started by the software application the HLS design is automatically restarted until explicitly stopped. The software application can also query the status of the design to determine when it actually has finished executing after being instructed to do so. The application and auto-restarting design use the following communications protocol:
- For passing argument values from the software application to
the design, the mailbox implements a set of double-buffered
s_axilitemapped registers to ensure non-blocking communication and consistent passing of inputs by the software application and passing of outputs by the design.
- Whenever the software application writes to an input argument,
it changes the software-side copy. The HLS design running in hardware does not
see that change. After the software application requests a mailbox write, the
next time the design automatically restarts the copy of the registers that are
seen by the design is updated with the latest inputs. Hence the software
application can write any number of arguments in any order, and the HLS design
does not see these updates until the software application requests a mailbox
write, and the design restarts. Tip: If some arguments are arrays mapped to
s_axiliteregister files, then the entire array must be written between successive mailbox writes because it is implemented as a ping-pong buffer.
- The same process occurs on the output side when the HLS design
writes to the design-side register and requests a mailbox read. The next time
the design is done, the values of the
s_axilitemapped output arguments are updated, and the software application can read them as needed.
Hence the software application has the following criteria:
- Not in charge of providing input data at every execution of the HLS design and collecting output data at its finish, as it would be in the case of control-driven designs.
- Involved in occasionally setting and updating some design input parameters (for example, routing tables, etc.) and checking the status of the design execution. This semi-synchronization operation is typically done without a fixed communication rate between the software application and the HLS design.
- When the software application has a new set of parameters to send to the HLS design, it does so without caring where the design is in its execution. When the software application needs to check the status of the HLS design, it does so without caring where design is in its execution. It is satisfied only that the parameter update and status check is performed consistently for the hardware.