0
1
00:00:01,060 --> 00:00:06,400
The question motivated this lecture is: What is the simulation flow in Vivado-HLS?
1

2
00:00:08,840 --> 00:00:13,820
The first step in the synthesis of any design in HLS is to validate its C description. 
2

3
00:00:14,600 --> 00:00:21,530
This step is usually performed with the help of a test bench. Writing a good test bench can significantly increase
3

4
00:00:21,530 --> 00:00:22,400
your productivity.
4

5
00:00:23,810 --> 00:00:28,910
Before developing any testbench code for a design, we should know the complete simulation flow in the 
5

6
00:00:29,180 --> 00:00:31,270
HLS and its relation with the design flow.
6

7
00:00:33,200 --> 00:00:39,180
By now, our designs were simple, and I have assumed that the designs are correct without any error or bug. 
7

8
00:00:40,310 --> 00:00:43,530
So, I only followed and explained the design flow.
8

9
00:00:43,880 --> 00:00:48,340
However, it is not true for a real design as they may have errors. 
9

10
00:00:49,190 --> 00:00:53,450
These errors should be found and corrected before the final implementation.
10

11
00:00:54,140 --> 00:00:58,060
For this purpose, the simulation flow should be added to the design flow.
11

12
00:00:59,950 --> 00:01:05,560
Let's have a look at the design flow. A design flow in HLS starts with a C/C++ description of a given 
12

13
00:01:05,560 --> 00:01:12,730
design plus its constraints.  Then the synthesis process converts the input descriptions into the equivalent
13

14
00:01:12,730 --> 00:01:13,690
RTL description.
14

15
00:01:14,500 --> 00:01:19,240
The IP packaging process generates the final, ready-to-use design IP.
15

16
00:01:20,740 --> 00:01:26,410
To start the simulation flow, we need a test bench file. 
Then this test bench and the design C/C++
16

17
00:01:26,440 --> 00:01:32,340
description (without constraints) can be simulated to find any functional error in the code.
17

18
00:01:33,220 --> 00:01:39,490
After correcting all possible errors, the synthesis process can be performed, which generates the corresponding
18

19
00:01:39,490 --> 00:01:43,960
cycle-accurate HDL code. This code can be verified, as well.
19

20
00:01:44,350 --> 00:01:47,680
The process is called C/RTL-cosimulation.
20

21
00:01:49,470 --> 00:01:55,740
In this process, the HLS reuses the C-testbench and apply that to the generated RTL description. In 
21

22
00:01:55,740 --> 00:02:01,190
this step, you can check the timing as well as the functionality in a cycle-accurate debugging environment.
22

23
00:02:01,800 --> 00:02:05,670
After doing this process successfully, the hardware IP can be generated.
23

24
00:02:07,740 --> 00:02:15,600
In summary, a design/simulation flow consists of five steps:
Developing the design and test bench descriptions 
24

25
00:02:15,600 --> 00:02:22,140
in C/C++.  Performing the C simulation to find functional errors.  Performing the HLS synthesis
25

26
00:02:22,140 --> 00:02:27,720
to generate the corresponding RTL description. 
Running the C/RTL Cosimulation to check the 
26

27
00:02:27,720 --> 00:02:33,810
functionality and timing in a cycle-accurate environment.
And generating the IP Package.
27

28
00:02:36,660 --> 00:02:42,000
After getting familiar with the HLS simulation flow integrated into the design flow, now the question
28

29
00:02:42,000 --> 00:02:45,210
is: How can we perform this design/simulation flow in Vivado-HLS?
29

30
00:02:45,210 --> 00:02:49,080
In the next lecture, using a design example, 
30

31
00:02:49,260 --> 00:02:50,520
I will answer this question.
31

32
00:02:53,400 --> 00:02:56,910
These are our takeaway messages: To start the C-simulation flow, 
32

33
00:02:57,060 --> 00:03:02,310
we need a test bench file.  C-simulation checks the design functionality before synthesis.
33

34
00:03:03,400 --> 00:03:06,880
C-simulation is highly recommended before synthesising a design.
34

35
00:03:09,030 --> 00:03:14,860
Now the quiz question. Which sentence is correct
Cycle accurate debugging is possible in C-simulation.
35

36
00:03:14,880 --> 00:03:19,740
Cycle accurate debugging is possible in C/RTL-simulation.