0
1
00:00:00,940 --> 00:00:05,970
Let’s talk a little bit about the C/C++ based design flow in Vivado-HLS. 
1

2
00:00:07,100 --> 00:00:13,450
This helps us to have a big picture of the HLS flow process so we can use that along the course.
2

3
00:00:15,210 --> 00:00:22,440
The Xilinx Vivado-HLS design flow starts with coding the hardware functionality in C/C++. This coding process 
3

4
00:00:22,440 --> 00:00:28,920
should follow a specific style in which using some functions or concepts are not allowed, such as dynamic 
4

5
00:00:28,920 --> 00:00:34,710
memory allocations or recursive functions. Although we should utilise all the available techniques
5

6
00:00:34,710 --> 00:00:36,210
in C/C++ language, 
6

7
00:00:36,420 --> 00:00:41,900
this step is the first step that it is better to have the hardware design concepts in our mind.
7

8
00:00:42,060 --> 00:00:48,270
For example, one of the underlying decision during code development is choosing a suitable data types that 
8

9
00:00:48,270 --> 00:00:50,400
have a sensible hardware counterpart. 
9

10
00:00:50,640 --> 00:00:55,410
After coding the given hardware, we can perform C-simulation to check the functionality. 
10

11
00:00:55,950 --> 00:01:02,430
The C- simulator considers the C main function as the test bench through which the design code is invoked. 
11

12
00:01:03,340 --> 00:01:08,980
In the case of any error, the source code can be modified. Although this step is optional, 
12

13
00:01:09,010 --> 00:01:13,660
it is highly recommended reducing the total development time. 
13

14
00:01:13,660 --> 00:01:19,750
The Xilinx Vivado-HLS utilises several dedicated libraries and techniques to provide simulation results 
14

15
00:01:19,750 --> 00:01:21,860
close to that of the final hardware. 
15

16
00:01:22,450 --> 00:01:29,200
Therefore,  understanding these libraries and underlying technologies can help us to develop an optimum 
16

17
00:01:29,200 --> 00:01:32,710
hardware design in the early stages of code development. 
17

18
00:01:34,030 --> 00:01:40,390
I will clarify these libraries and coding styles along this course. The next step is adding hardware-specific 
18

19
00:01:40,390 --> 00:01:47,830
optimisation and design techniques to the C/C++ code. As the current C/C++ language cannot 
19

20
00:01:47,830 --> 00:01:49,390
support some of these concepts, 
20

21
00:01:49,570 --> 00:01:57,940
the Xilinx Vivado-HLS provides new hardware-oriented compiler settings through pragmas (or compiler configurations).  
21

22
00:01:58,870 --> 00:02:04,330
As they are compiler directives, they are statically processed by the HLS synthesis tool, 
22

23
00:02:04,780 --> 00:02:11,890
so some constraints on timing, hardware utilisation or code optimisation will be considered during 
23

24
00:02:11,890 --> 00:02:13,360
final hardware design. 
24

25
00:02:14,140 --> 00:02:20,290
Designers with fundamental hardware knowledge can efficiently add the proper pragmas to the code.
25

26
00:02:20,900 --> 00:02:24,250
. Therefore a basic understanding of hardware is essential. 
26

27
00:02:24,670 --> 00:02:30,910
Along with this course, I will explain these hardware concepts and their corresponding HLS code. As the 
27

28
00:02:31,240 --> 00:02:36,910
HLS synthesiser makes some default hardware related assumptions along the synthesis process,
28

29
00:02:37,180 --> 00:02:43,780
adding pragmas is optional. However, adding proper pragmas are essential to get appropriate 
29

30
00:02:43,780 --> 00:02:49,840
hardware behaviour, and the default assumptions do not always give the desired functionality. 
30

31
00:02:50,020 --> 00:02:54,610
After adding hardware related pragmas, the code is ready for high-level synthesis. 
31

32
00:02:55,030 --> 00:03:01,900
In the case of successful synthesis, the output of this synthesis process is a reusable HDL IP described 
32

33
00:03:01,900 --> 00:03:03,390
in VHDL or Verilog.
33

34
00:03:04,420 --> 00:03:12,250
In this course, we treat this IP as a black box and use that during the logic synthesis without any knowledge
34

35
00:03:12,400 --> 00:03:14,800
about its internal coding structure. 
35

36
00:03:15,580 --> 00:03:22,840
The synthesis process generates a couple of reports; including step-by-step synthesis messages and 
36

37
00:03:22,840 --> 00:03:26,230
the timing and resource utilisation diagram and reports. 
37

38
00:03:27,150 --> 00:03:33,840
If there is any error message, then the original C/C++ source code or the added pragmas should be modified. 
38

39
00:03:34,410 --> 00:03:40,380
Also, the reports can be inspected to make sure that all performance targets are met.
39

40
00:03:40,890 --> 00:03:46,950
In the case of any issue or performance degradations, the source code or the compiler pragmas should
40

41
00:03:46,950 --> 00:03:47,700
be modified.
41

42
00:03:49,810 --> 00:03:54,560
After synthesis, the co-simulation will be enabled and can be run by designers. 
42

43
00:03:54,850 --> 00:04:00,910
This step uses the corresponding generated HDL code along with the C test-bench and performs
43

44
00:04:00,910 --> 00:04:02,620
a hardware-software co-simulation. 
44

45
00:04:03,160 --> 00:04:08,980
The simulation is cycle-accurate, and the behaviour is very close to that of the final hardware on the
45

46
00:04:08,980 --> 00:04:09,320
board.
46

47
00:04:09,820 --> 00:04:16,300
In the case of any failures in functionality or performance, the source code or compiler directives should 
47

48
00:04:16,300 --> 00:04:16,900
be modified.
48

49
00:04:17,500 --> 00:04:20,900
This step can also detect deadlocks in the design. 
49

50
00:04:21,220 --> 00:04:24,880
This step is optional and a time-consuming process.
50

51
00:04:25,240 --> 00:04:32,380
However, it is useful to perform a debug process close to hardware behaviour and find any performance 
51

52
00:04:32,380 --> 00:04:33,070
bottlenecks.
52

53
00:04:34,840 --> 00:04:41,470
The last step is IP generation which packages our design into an IP that can be used in the logic 
53

54
00:04:41,470 --> 00:04:43,960
synthesis step as a black box.
54

55
00:04:46,000 --> 00:04:51,940
In the next step, I will explain how to use a C/C++ function code to describe a given hardware design. 
55

56
00:04:52,570 --> 00:04:58,060
I will talk about the analogy between different components in a software function and a hardware module.
56

57
00:04:59,950 --> 00:05:06,160
The takeaway message from this video is that the C/C++ design flow using Xilinx Vivado-HLS has three 
57

58
00:05:06,160 --> 00:05:06,850
main steps.
58

59
00:05:08,320 --> 00:05:15,550
The first step is describing the hardware considering a proper C/C++ coding style. The second step
59

60
00:05:15,550 --> 00:05:22,660
would be adding hardware design&optimisation pragmas into the code and finally performing the
60

61
00:05:22,660 --> 00:05:26,800
HLS synthesis to generate the corresponding HDL based IP.
61

62
00:05:28,940 --> 00:05:35,600
Now the quiz question. What is the difference between C-Simulation and RTL-Co-Simulation?