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里头,之后我们会结合一个具体的实例,解释一下我们为什么要这么做。
对于每份代码综合处理后的,结果可能是不相同的,具体就要根据自己的需求进行合理的优化。
查看波形