对当前 HLS 技术的一些思考

vector.ws

HLS 目前的问题是能解决一些问题 在数字信号处理方面编程 是要比DSP简单， 功能要强大，
但是应用领域 扩大 ， 各种问题就来了

HLS 简单的说就是 把C /C++ 语音 转换成 fpga 上的 verilog 描述， 代码的运行原理其实 和Cuda 的 SPMD 也没有什么区别， 但是一切并不像看起来的那样完美， 常常有各种坑，
比如， 谁都明白 一个 dataflow process 同时读一个 memory array 是没有问题， 但是 综合结果却经常报错， 然后问了一遍 说是要叫stable， 用stable 限定 memory在dataflow region 执行的时候 memory 不会更新，  难道编译器不知道 dataflow region执行的时候 我没有更新memory ？
说实在的， 我用C/C++ pthread 写代码 都没见过这么难理解的， 说白了就是说 这个工具提供的 executing model 其实有很多问题 ，  关于数据在并发下访问同步的问题， 除了stable， 在dataflow 里面还有  什么 fence， stream_of_blocks, pipo, 这一大堆玩意 ， 感觉HLS 就是一个缝合怪 ， 每种东西直接拼凑 在一起，  毫无关联，trap一个接一个



还有interface， 本人做了嵌入式开发十几年， 初次接触HLS ， 简直被interface 搞晕了， 怎么就一个 function call 就能 把数据传送过去了， 我想kernel 执行的时候，在testbench里面 read 一个fifo 的结果， 然后做出处理以后生成 另外一个fifo interface 的输入该怎么做？  软件testbench 根本没法写， 只能按照function call 语义写， 然后根本没办法测试  异步的 interface 通信

在回到以前的cuda 的比较， 其实HLS 的执行模式和cuda  SPMD 没有太大区别， 但是搞出这么多事情恶心的坑， 主要原因就是出在
1.  循环嵌套， top function 被调用 多次， 其实是可以的看作 循环的 body， 然后 多个body 的多次execution 是 overlap  ，
2. cuda 是多个 执行overlap的，  而 cuda 是没有这个问题， cuda 的多次执行输入数据， 是已经准备好了， 每个执行 只是读取和写出属于自己的输入 输出memory 空间， 实在是需要多个thread 之间通信， 需要显示的调用thread 同步机制， 交换数据。  但是HLS 的每次执行 ， 输入 输出memory 可以是只属于自己的， 或者是 多个执行共享的， 只要一个输入 输出 的momory 存在冲突， 就会导致 两个 kernel 的执行 需要同步数据，  根本没有任何机制 让你同步数据

其实 HLS 不应该 既要 保留fpga的灵活， 有想抄袭 spmd 程序模型的简单易懂，  搞到最后 就是一个缝合怪 ，
如果让我设计 ， 我觉得把SPMD 模型彻底彻底舍弃掉， 做好一个 HLS 应该只做好 pipeline 的调度， 多个pipeline 之间的数据同步就行了
国产FPGA 如果能上HLS ， 其实现在很多生态问题都能解决了 当然前提是不要搞这种 恶心的SPMD 的HLS