What is the role of functions in describing logic circuits in HLS? This lecture explains the basic rules 1
for using C/C++ functions in Vivado-HLS. 2
Hardware designs in HLS are described by a set of C/C++ functions. 3
Therefore, the structure of each function and its relation with others have a significant impact on 4
the final synthesised hardware. 5
The new advanced HLS tools can synthesise a wide range of functions into their equivalent RTL hardware. 6
However, they sometimes should spend a long time to examine all the possible cases to find a near-optimal 7
solution. 8
Following a specific coding style can help the synthesis process to find the optimum points quickly. 9
The C functions must contain the entire functionality of the design. 10
They can be organised into libraries, but system calls to the operating system are not allowed. 11
In general, calls to the system cannot be synthesised and should be removed from the function before 12
synthesis. 13
Some examples of such calls are getc(), time(), sleep(), all of which make calls to the operating system. 14
Notice that, these functions can be used in a testbench function but not inside a design function. 15
The testbench concepts and approaches are explained in the next section. 16
Vivado® HLS ignores commonly-used system calls that display only data and that have no impact on 17
the execution of the algorithm, such as cout, and printf(). In the next section, 18
I will explain how we can use this feature during design C-simulation. 19
The top-level function in a design description has an important role and becomes the top-level module 20
of the RTL design after synthesis. Sub-functions are synthesised into blocks in the RTL design. 21
There is a relation between the function call graph in HLS and the module hierarchy of the corresponding 22
hardware after synthesis. 23
Notice that the top-level function cannot be a static function. 24
When the top-level function is synthesised, the arguments (or parameters) to the function are synthesised 25
into RTL ports. This process is called interface synthesis. 26
Arguments in the top-level function require interfaces. 27
If you don’t define them, the HLS considers default interface for them. 28
Sub-functions can optionally be inlined to merge their logic with the logic of the surrounding function. 29
While inlining functions can result in better optimisations, it can also increase runtime. 30
More logic and more possibilities must be kept in memory and analysed. 31
For example, if we consider that functions in the last level of this functional call graph are inlined, 32
then they would be merged with their calling function in the resulted hardware module. 33
Vivado-HLS may perform automatic inlining of small functions. To disable automatic inlining 34
of a small function, set the inline directive to off for that function. 35
As an example, consider these two simple functions and a top function that calls them. Don’t forget 36
to add interfaces for the top-function arguments. 37
If we synthesise this code, then all subfunctions are merged into the top function. 38
However, we can prevent this process by adding these pragmas. 39
Let’s see the function inilining in action. 40
For this purpose, create a Vivado-HLS project and enter the functions in the previous slide 41
as a design. And then synthesise the design. The Vivado-HLS merges the small functions into the top-function 42
and creates only one RTL module. 43
If you go to the console view, you can see the compiler message regarding to the function 44
automatic-inlining. 45
In the synthesis report, we can see that the design propagation delay is 0.978 46
nanosecond. 47
Also, there are no instances of function in the Instance part. 48
In addition, there is only one report file corresponding to the top RTL module in the report folder under 49
the "syn" directory. 50
Now let’s turn off the automatic inlining feature for the two sub-functions; for this purpose, you 51
should add two pragmas to the functions. 52
Now if we synthesise the code, there should be three RTL modules in the hardware design after synthesis, 53
including the top module. If we check the instance section, we can see the two RTL module instances 54
corresponding the two subfunctions. 55
Notice that the top module won’t list in this part. 56
Also, if we check the synthesis report folder, we can see three report files corresponding to the 57
three RTL modules. 58
Now that we have introduced to the HLS functions. The question is How can we model the structure 59
of a combinational code inside a function to better understand the synthesis process behaviour? 60
The next lecture will address this question. 61
These are our takeaway messages: The C functions must contain the entire functionality of the design. 62
System 63
calls to the operating system are not allowed. 64
Arguments in the top-level function require interfaces 65
Sub-functions can optionally be inlined to merge their logic with the logic of the surrounding function. Vivado-HLS may perform automatic inlining of small 66
functions. 67
Now the quiz question. How can we stop the Vivado-HLS synthesis process from merging the 68
sub-function with the top-function in this code?