XILINX HLS 入坑记录 之 写RAM 综合出 读取+写入Ram

最近使用 Xilinx HLS 来开发 算法的IPcore,使用的Vitis 2021,发现光是 EDA 工具就存在很多的bug，比如：

1.经常C综合 停留在 Using flow_target 'vivado' 不给任何报错提示，永远卡死；

2.点击coSimulation vivado 启动 后读取脚本卡死，不能正常仿真；

3.C综合给出的资源使用和IPCore实现后的资源使用相差甚远，通常C综合的LUT资源会比实现后的LUT资源高一倍以上；

遇到这种情况只能重新建立工程添加derectives ，真的太难用了，希望Xilinx 能够提供更好的工具。

以上坑都踩完了 还有一个问题卡了3天才解决，这个是使用上的问题；

问题表象是使用双端口Ram写入一段数据，使用 pipeline 后，总共的写入延时应该为Ram长度的一半，最后综合出来 pipeline 的II=2,也就是延时为整个Ram数据的长度。

　　最开始综合单独将这个循环所在的函数设置为TOP Fuction 时，延时正确的，但是这个函数是作为子模块存在更大的顶层模块中。当我设置最终的顶层函数作为顶层模块时，这个子函数的 pipeline 的II=2，延时为Ram的长度；最终查看Schedule Viewer 发现在写入双端口ram之前需要读取目标ram的数据，这是想了很久都没想明白的。最终经过不同版本的折腾和上面的踩坑过程，最后通过查看生成出verilog 代码，发现写入数据前需要和读取的数据进行与操作和其他乱七八糟的逻辑运算操作，我需要写入的数据位宽为5bit，ram的端口位宽为10bit，如果只需要写入5bit确实需要读取再写入（在没有做过HDL 开发的情况下，不清楚ram读写逻辑，通过询问做FPGA的同事才知道）。

　　为什么操作的Ram从5bit位宽变成了10bit 位宽，是因为我的顶层函数下的其他函数需要2个5bit 同时访问，因此对Ram添加了 #pragma HLS ARRAY_RESHAPE dim=1 factor=2 type=cyclic variable=xxxx,这个优化将Ram变成2倍位宽，最终改为#pragma HLS ARRAY_PARTITION dim=1 factor=2 type=cyclic variable=xxxx;就可以了。

总结： 不是说有的 ARRAY_RESHAPE  都可以替代 ARRAY_PARTITION   ，需要读写多组 数据，而且是需要单独读写其中某一个数据时 必须使用 ARRAY_PARTITION  ，仅仅需要同时读写多组数据时 就可以使用 ARRAY_RESHAPE  以便节省 ram资源。