传统的RTL设计流程
在RTL设计流程中，是这样的设计流程：
- 设计Verilog VHDL SV代码代码
- 设计TB文件
- 进行RTL级仿真不断修改
- 综合实现
- 系统级调试
注意在综合分析时要根据需要满足资源布局还有时序的要求
C语言设计流程
在HLS工具的使用中最大的不同是你只需要进行C语言的编写设计和测试代码，通过HLS工具即可自动完成对RTL的代码生成，进过C综合后通过声明的操作进行对代码不同的优化。
完成C综合后即可导出RTL级代码进行RTL级的综合分析。后面过程与传统的RTL分析过程相同。
HLS的系统级ip使用流程
一个C/C++代码最后映射到RTL代码有三大类接口，包括Block-level IO Handshake（握手信号）、C Inputs、C Outputs；
生成调用后可以在system generate或者vivado的block design中添加到IP库中即可进行调用。
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++语言风格的代码都能被综合，有两点需要注意：一是动态内存分配，二是操作系统层面；
HLS的设计操作流程
- 添加设计文件
- 添加测试文件
- 进行C仿真
- 进行C综合
- 进行联合仿真
- 导出RTL
注意： 在C综合时候，我们可以通过添加声明来对代码进行优化和约束。
hls界面中的操作流程
SOLUTIONS
对于每份代码综合处理后的，结果可能是不相同的，具体就要根据自己的需求进行合理的优化。
查看波形
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++代码层次一致；
