vivado hls工作机制、设计流程

CPU、GPU、DSP、FPGA之间的区别：https://blog.csdn.net/Qiuoooooo/article/details/81779583

对于一个软件工程师，应该掌握的程度：

        1. FPGA内部每个单元的功能；

        2. 具体的算法操作和每个单元之间的对应关系；

        3. 算法模型中资源的利用率；

        4. 算法模型的优化方法；

那么怎样能使得我们用C/C++转化成的HDL代码可以高效运行？”

一. Vivado HLS的工作原理

1. History of ESL(Electronic System Level)

 CAD-CAE-EDA
 - Computer Aided Design
 - Computer Aided Engineering
 - Electronic Design Automation

在EDA这个阶段，最典型的特征就是出现了硬件描述语言——VHDL和Verilog；

到了现在，就出现了ESL（电子系统级设计方法）这个概念，它的本质是在说在ESL这个阶段我们希望采用具有更高抽象度的方式去描述系统行为，所以在这个阶段有两个显著特征：

• 使用高级语言（例如C或者C++），XILINX有Vivado HLS这个工具；
• 使用基于模型的设计工具——System Generator；

2. High-level Synthesis Benefits

• 对于硬件工程师，提高项目效率，不需要考虑并行性和时序的问题，直接在算法级考虑优化；
• 对于软件工程师，可以提高系统性能，原来需要CPU、GPU或者DSP才能实现的算法现在都可以通过FPGA来实现，一方面提高了吞吐率，另一方面也改善了功耗；
• 在C/C++这个层面开发算法并且验证；
• 
• 通过优化工具来高效指导转化过程；

3. Vivado HLS的综合流程

• Scheduling：确定每个时钟周期应该做什么操作，同时这个操作大概需要几个时钟周期完成，以及是否可以并行执行；
• Control Logic Extraction：控制逻辑的提取通常会生成一个状态机，这个可以在HDL代码中看到；
• Binding：确定每个操作需要用什么资源去实现，完成这样的一个从操作到资源映射过程；

下面来看一下对于这几个过程的实例：
Scheduling and Binding Example的例子如下，下面这个例子比较简单，所以只有一个状态C0;

控制逻辑的提取例子，有四个状态，在C0状态执行b+c，C1状态产生x和数组的地址，C2状态执行相应的乘法操作，C3状态将结果写入y数组的对应位，如此循环几次，直到到达循环边界退出循环。需要注意的是，生成的控制状态（左下）和状态机（右下）不是一一对应的，但它们之间非常接近。

矩阵相加的例子：

通过状态机控制这个流程。

总结：
>Vivado HLS有两个阶段:调度/控制逻辑提取和绑定
>算法流程图可以帮助分析Vivado HLS生成的控制状态
>控制状态是Vivado HLS用来将操作调度到时钟周期中的内部状态
>在RTL FSM中，控制状态和最终状态之间存在密切的相关性，但不存在一对一映射

 

4. Vivado HLS设计流程

 

• Vivado HLS的设计输入包括Test bench、C/C++和Directives，相应的设计输出有IP（在Vivado的IP Catalog中）、DCP（RTL代码综合后的网表文件）、SysGen（HLS之后的结果可以导入SysGen中使用）。
• Test bench的作用有两点：一是验证C/C++代码的正确性；二是在与RTL的协同仿真阶段，生成用于RTL级验证的Test bench;
• 对于一个工程，只可以有一个顶层的函数用于综合，这个函数下面的子函数也可以被综合，通常情况下C/C++综合后的RTL代码的结构和原始的C函数描述的结构一致（除了子函数所需要的逻辑量很小、算法功能很简单时，综合阶段不会单独有这个结构，将HLS INLINE off关掉时就会完全一致）。
• 并不是所有的C/C++语言风格的代码都能被综合，有两点需要注意：一是动态内存分配（不可综合），二是操作系统层面（不可综合）；
• 一个C/C++代码最后映射到RTL代码有三大类接口，包括Block-level IO Handshake（握手信号）、C Inputs、C Outputs；

Directives的两种方式：

• 将每个directive以directives.tcl格式作为一个Tcl命令单独存放，以"#"作为标识；
  优势在于：每个solution都有独立的directives，如果这个solution需要重新综合，那么只有这个solution下面的directive会起到作用；不足之处在于：如果C source code文件需要被给到第三方，那么需要将directives.tcl包含其中，对于一个代码需要获得同样的综合结果，那么同样的directives.tcl必不可少。

• 将每个directive嵌入到C/C++源码中，以pragma格式出现，"%"作为标识；
  优势在于：如果C source code文件需要被给到第三方，不需要单独将directives.tcl交付，对于一个代码需要获得同样的综合结果，也不需要额外的directives.tcl；不足之处在于：如果一个solution需要重新综合，那么所有的directives都要被执行。

几点小技巧：

• 为C/C++代码中的for循环单独创建标签，这会使得在创建directives时非常方便；
• 最好将directives单独存放，不要将其和源码放在一起；
• Test bench中的main()函数的返回结果值为int类型，仿真通过返回值为0，不通过才是1；
• 通常情况下RTL代码的层次和原始的C/C++代码层次一致；

补充：

1每个步骤将生成自己的文件文件夹

2每一步都应该按顺序执行

3C testbench是Vivado他的项目中的一个重要文件

4综合报告可用于检查时间资源利用率、综合性能和接口

5波形查看器是一个非常直观的方式来检查之间的时间关系的端口

每一个vivado hls的工程都可以有多个不同的solution，那么每个solution都是都会有自己不同的directives。这些directive是用来优化C综合的，可以写在source file里头也可以写在directive file里头。那么这里我们建议大家。把directive单独写在directive file里头，之后我们会结合一个具体的实例，解释一下我们为什么要这么做。

对于每份代码综合处理后的，结果可能是不相同的，具体就要根据自己的需求进行合理的优化。

查看波形