0
1
00:00:01,590 --> 00:00:08,280
What is the role of functions in describing logic circuits in HLS? This lecture explains the basic rules 
1

2
00:00:08,400 --> 00:00:11,460
for using C/C++ functions in Vivado-HLS.
2

3
00:00:13,870 --> 00:00:18,260
Hardware designs in HLS are described by a set of C/C++ functions.
3

4
00:00:18,670 --> 00:00:24,340
Therefore, the structure of each function and its relation with others have a significant impact on 
4

5
00:00:24,340 --> 00:00:26,200
the final synthesised hardware.
5

6
00:00:27,540 --> 00:00:33,240
The new advanced HLS tools can synthesise a wide range of functions into their equivalent RTL hardware. 
6

7
00:00:33,540 --> 00:00:38,970
However, they sometimes should spend a long time to examine all the possible cases to find a near-optimal 
7

8
00:00:38,970 --> 00:00:39,960
solution.
8

9
00:00:40,200 --> 00:00:46,020
Following a specific coding style can help the synthesis process to find the optimum points quickly. 
9

10
00:00:48,090 --> 00:00:51,430
The C functions must contain the entire functionality of the design.
10

11
00:00:51,480 --> 00:00:56,580
They can be organised into libraries, but system calls to the operating system are not allowed.
11

12
00:00:57,710 --> 00:01:03,590
In general, calls to the system cannot be synthesised and should be removed from the function before
12

13
00:01:03,590 --> 00:01:04,220
synthesis. 
13

14
00:01:05,260 --> 00:01:12,340
Some examples of such calls are getc(), time(), sleep(), all of which make calls to the operating system.
14

15
00:01:13,150 --> 00:01:18,830
Notice that, these functions can be used in a testbench function but not inside a design function.
15

16
00:01:19,210 --> 00:01:22,960
The testbench concepts and approaches are explained in the next section.
16

17
00:01:24,850 --> 00:01:31,150
Vivado® HLS ignores commonly-used system calls that display only data and that have no impact on 
17

18
00:01:31,150 --> 00:01:36,130
the execution of the algorithm, such as cout, and printf(). In the next section,
18

19
00:01:36,280 --> 00:01:40,330
I will explain how we can use this feature during design C-simulation. 
19

20
00:01:43,240 --> 00:01:48,910
The top-level function in a design description has an important role and becomes the top-level module 
20

21
00:01:49,060 --> 00:01:55,520
of the RTL design after synthesis. 
Sub-functions are synthesised into blocks in the RTL design.
21

22
00:01:56,260 --> 00:02:01,930
There is a relation between the function call graph in HLS and the module hierarchy of the corresponding
22

23
00:02:01,930 --> 00:02:03,370
hardware after synthesis.
23

24
00:02:03,850 --> 00:02:06,940
Notice that the top-level function cannot be a static function.
24

25
00:02:10,250 --> 00:02:16,100
When the top-level function is synthesised, the arguments (or parameters) to the function are synthesised
25

26
00:02:16,100 --> 00:02:20,270
into RTL ports. This process is called interface synthesis.
26

27
00:02:20,690 --> 00:02:24,010
Arguments in the top-level function require interfaces. 
27

28
00:02:24,380 --> 00:02:28,370
If you don’t define them, the HLS considers default interface for them.
28

29
00:02:30,500 --> 00:02:36,440
Sub-functions can optionally be inlined to merge their logic with the logic of the surrounding function. 
29

30
00:02:36,650 --> 00:02:41,930
While inlining functions can result in better optimisations, it can also increase runtime. 
30

31
00:02:42,200 --> 00:02:46,580
More logic and more possibilities must be kept in memory and analysed.
31

32
00:02:47,980 --> 00:02:53,770
For example, if we consider that functions in the last level of this functional call graph are inlined, 
32

33
00:02:53,950 --> 00:02:58,570
then they would be merged with their calling function in the resulted hardware module.
33

34
00:03:01,670 --> 00:03:07,310
Vivado-HLS may perform automatic inlining of small functions. To disable automatic inlining 
34

35
00:03:07,310 --> 00:03:11,810
of a small function, set the inline directive to off for that function.
35

36
00:03:13,850 --> 00:03:19,580
As an example, consider these two simple functions and a top function that calls them. Don’t forget 
36

37
00:03:19,580 --> 00:03:22,070
to add interfaces for the top-function arguments.
37

38
00:03:23,140 --> 00:03:27,490
If we synthesise this code, then all subfunctions are merged into the top function.
38

39
00:03:27,910 --> 00:03:31,480
However, we can prevent this process by adding these pragmas. 
39

40
00:03:32,440 --> 00:03:34,380
Let’s see the function inilining in action. 
40

41
00:03:36,900 --> 00:03:42,240
For this purpose, create a Vivado-HLS project and enter the functions in the previous slide
41

42
00:03:42,240 --> 00:03:49,440
as a design. And then synthesise the design. The Vivado-HLS merges the small functions into the top-function 
42

43
00:03:49,440 --> 00:03:52,650
and creates only one RTL module. 
43

44
00:03:55,330 --> 00:04:00,910
If you go to the console view, you can see the compiler message regarding to the function 
44

45
00:04:00,910 --> 00:04:01,410
automatic-inlining. 
45

46
00:04:05,580 --> 00:04:11,280
In the synthesis report, we can see that the design propagation delay is 0.978
46

47
00:04:11,280 --> 00:04:12,090
nanosecond.
47

48
00:04:12,630 --> 00:04:16,470
Also, there are no instances of function in the Instance part.
48

49
00:04:17,040 --> 00:04:23,850
In addition, there is only one report file corresponding to the top RTL module in the report folder under 
49

50
00:04:23,850 --> 00:04:24,870
the "syn" directory.
50

51
00:04:27,830 --> 00:04:33,320
Now let’s turn off the automatic inlining feature for the two sub-functions; for this purpose,  you
51

52
00:04:33,320 --> 00:04:35,390
should add two pragmas to the functions.
52

53
00:04:45,970 --> 00:04:52,360
Now if we synthesise the code, there should be three RTL modules in the hardware design after synthesis,
53

54
00:04:52,720 --> 00:04:58,960
including the top module.  If we check the instance section, we can see the two RTL module instances 
54

55
00:04:59,110 --> 00:05:00,860
corresponding the two subfunctions. 
55

56
00:05:01,150 --> 00:05:04,180
Notice that the top module won’t list in this part.
56

57
00:05:04,840 --> 00:05:10,960
Also, if we check the synthesis report folder, we can see three report files corresponding to the
57

58
00:05:10,960 --> 00:05:12,340
three RTL modules. 
58

59
00:05:14,640 --> 00:05:20,100
Now that we have introduced to the HLS functions. The question is How can we model the structure 
59

60
00:05:20,100 --> 00:05:25,400
of a combinational code inside a function to better understand the synthesis process behaviour?
60

61
00:05:25,950 --> 00:05:28,050
The next lecture will address this question.
61

62
00:05:31,380 --> 00:05:36,750
These are our takeaway messages: The C functions must contain the entire functionality of the design.
62

63
00:05:37,230 --> 00:05:37,710
System
63

64
00:05:37,710 --> 00:05:40,200
calls to the operating system are not allowed.
64

65
00:05:40,500 --> 00:05:43,920
Arguments in the top-level function require interfaces
65

66
00:05:44,130 --> 00:05:50,400
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

67
00:05:50,400 --> 00:05:51,030
functions.
67

68
00:05:53,020 --> 00:05:58,410
Now the quiz question. How can we stop the Vivado-HLS synthesis process from merging the 
68

69
00:05:58,420 --> 00:06:00,910
sub-function with the top-function in this code?