C/RTL协同仿真失败问题

一、协同仿真失败分类1.C/RTL协同仿真直接报错并有报错提示哪里出现错误2.C/RTL协同仿真直接报错但是没有提示错误的原因3.C/RTL协同仿真不报错但是提示deadlock4.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语言可综合代码存在的问题