企业官网建设流程全解析

一、协同仿真失败分类
1.C/RTL协同仿真直接报错，并有报错提示哪里出现错误
2.C/RTL协同仿真直接报错，但是没有提示错误的原因
3.C/RTL协同仿真不报错，但是提示deadlock
4.C/RTL协同仿真不报错，不提示deadlock，仿真一直不提示进度或者完成
5.C/RTL协同仿真不报错，不提示deadlock，仿真一直有进展，并且超过了100%，还在运行
以上5类协同仿真问题，从简单到复杂的排列，其中4和5这个是最难排查和定位的，几乎没有特别好的手段，只能看代码。

二、RTL协同仿真失败的可能原因
1.环境变量设置存在问题
2.使用的pragram指令存在不合理或者不正确
3.使用的pragram指令出现误用
4.测试激励存在问题
5.C语言代码存在问题
6.C语言代码的串行和并行结构存在rtl翻译问题
7.消耗的资源太多
8.时序存在问题
9.逻辑资源占用太大
10.浮点运算太多
11.数组的bank撞车
12.dependence依赖的误用
13.数组越界
14.detph设置不合理
15.设计latency太过庞大

三、关于指令使用的问题
1.首先看代码中有没有使用dependence约束指令
如果你的代码设计中使用了dependence指令，先尝试将dependence指令去掉，看看
是否能够协同仿真成功，如果可以，说明你这个约束方式存在问题；

2.顶层接口的指针是否使用了volatile
注意interface接口的指针的detph是一定要指定的，如果接口使用了volatile修饰指针，那么这个指针使用depth来约束的时候，
必须指定每个传输事务，也就是说必须指定每次执行C语言顶层函数中，端口被读写的次数

3.是否对FIFO使用了dataflow最优化
首先确认，使用乒乓buffer是否可以协同仿真成功；
其次检查不指定FIFO的depth下，是否可以协同仿真成功；
然后，在不确定FIFO的depth大小的时候，设置一个比较大的depth，然后逐渐减小depth，直到仿真失败，
这样就能确定depth的最合适的值。

4.不要随意使用ap_ctrl_none
初级工程师，要无脑的使用ap_Ctrl_hs，不要触碰ap_ctrl_none,
ap_ctrl_none的使用会让设计变得无比复杂和不可控。

5.接口的指令是否合理使用

6.接口上的数组，不要瞎用指令

7.数组的优化，要合理，不要bank撞车

四、C语言测试激励的问题

五、C语言可综合代码存在的问题