Let’s talk a little bit about the C/C++ based design flow in Vivado-HLS. 1
This helps us to have a big picture of the HLS flow process so we can use that along the course. 2
The Xilinx Vivado-HLS design flow starts with coding the hardware functionality in C/C++. This coding process 3
should follow a specific style in which using some functions or concepts are not allowed, such as dynamic 4
memory allocations or recursive functions. Although we should utilise all the available techniques 5
in C/C++ language, 6
this step is the first step that it is better to have the hardware design concepts in our mind. 7
For example, one of the underlying decision during code development is choosing a suitable data types that 8
have a sensible hardware counterpart. 9
After coding the given hardware, we can perform C-simulation to check the functionality. 10
The C- simulator considers the C main function as the test bench through which the design code is invoked. 11
In the case of any error, the source code can be modified. Although this step is optional, 12
it is highly recommended reducing the total development time. 13
The Xilinx Vivado-HLS utilises several dedicated libraries and techniques to provide simulation results 14
close to that of the final hardware. 15
Therefore, understanding these libraries and underlying technologies can help us to develop an optimum 16
hardware design in the early stages of code development. 17
I will clarify these libraries and coding styles along this course. The next step is adding hardware-specific 18
optimisation and design techniques to the C/C++ code. As the current C/C++ language cannot 19
support some of these concepts, 20
the Xilinx Vivado-HLS provides new hardware-oriented compiler settings through pragmas (or compiler configurations). 21
As they are compiler directives, they are statically processed by the HLS synthesis tool, 22
so some constraints on timing, hardware utilisation or code optimisation will be considered during 23
final hardware design. 24
Designers with fundamental hardware knowledge can efficiently add the proper pragmas to the code. 25
. Therefore a basic understanding of hardware is essential. 26
Along with this course, I will explain these hardware concepts and their corresponding HLS code. As the 27
HLS synthesiser makes some default hardware related assumptions along the synthesis process, 28
adding pragmas is optional. However, adding proper pragmas are essential to get appropriate 29
hardware behaviour, and the default assumptions do not always give the desired functionality. 30
After adding hardware related pragmas, the code is ready for high-level synthesis. 31
In the case of successful synthesis, the output of this synthesis process is a reusable HDL IP described 32
in VHDL or Verilog. 33
In this course, we treat this IP as a black box and use that during the logic synthesis without any knowledge 34
about its internal coding structure. 35
The synthesis process generates a couple of reports; including step-by-step synthesis messages and 36
the timing and resource utilisation diagram and reports. 37
If there is any error message, then the original C/C++ source code or the added pragmas should be modified. 38
Also, the reports can be inspected to make sure that all performance targets are met. 39
In the case of any issue or performance degradations, the source code or the compiler pragmas should 40
be modified. 41
After synthesis, the co-simulation will be enabled and can be run by designers. 42
This step uses the corresponding generated HDL code along with the C test-bench and performs 43
a hardware-software co-simulation. 44
The simulation is cycle-accurate, and the behaviour is very close to that of the final hardware on the 45
board. 46
In the case of any failures in functionality or performance, the source code or compiler directives should 47
be modified. 48
This step can also detect deadlocks in the design. 49
This step is optional and a time-consuming process. 50
However, it is useful to perform a debug process close to hardware behaviour and find any performance 51
bottlenecks. 52
The last step is IP generation which packages our design into an IP that can be used in the logic 53
synthesis step as a black box. 54
In the next step, I will explain how to use a C/C++ function code to describe a given hardware design. 55
I will talk about the analogy between different components in a software function and a hardware module. 56
The takeaway message from this video is that the C/C++ design flow using Xilinx Vivado-HLS has three 57
main steps. 58
The first step is describing the hardware considering a proper C/C++ coding style. The second step 59
would be adding hardware design&optimisation pragmas into the code and finally performing the 60
HLS synthesis to generate the corresponding HDL based IP. 61
Now the quiz question. What is the difference between C-Simulation and RTL-Co-Simulation?