UG1270 Reading Notes(1)

UG1270
Chapter 1 Introduction
1.优化过程由两部分组成：指明采取何种优化的指示（directives）和优化应该以怎样方式确定而有效被施加的原则（methodology）
2.SDSoC虽然支持HLS Pragmas，但是不支持施加于接口的pragmas（interface、array partition、data_pack等）

Chapter2 Optimizing the Hardware Function

1. 施加硬件函数优化的两种流程：自顶向下（Top-down）和自底向上(Bottom-up)。前者指程序到硬件函数的分解在SDSoC环境中进行，让系统编译器自动生成函数流水线在数据流模式下工作，最后每一个硬件函数的微体系结构使用HLS来优化；后者指每个硬件函数首先独立用HLS进行优化，使用生成的已经优化的硬件函数在SDSoC环境中集成为一个系统。
   
   上图为优化步骤

   Improve Area指的是减少所用PL资源，事实上，在性能达标的情况下，为了减少资源而强行对设计进行优化没有什么额外的好处。

2. 在施加任何优化之前，首先必须了解硬件函数的基线指标。基本性能评估的三大指标是：计时(timing)、间隔(interval)、时延(latency)，这三大指标可以在综合后生成的报告中查看。

   计时（timing）：展示了目标时钟频率和当前设计估测的时钟频率。如果估测的时钟频率超过目标时钟频率，说明可能此设计满足不了设计目标。此时可以调整期待的目标时钟频率（Data Motion Network Clock Frequency）。特别的，如果超过的并不多（20%以内），那么此设计有可能在后续的优化中满足目标要求。

   启动距离（Initiation Interval，II）：表示的是函数可以接受下一轮新输入需要经过的时间，这对于一般的系统来说是最重要的参考指标。最理想的函数应该是每一个时钟就处理一个新的数据样本，比如传入函数的参数最大长度是N，那么最好能达到的II=N+1，表示设计在N个时钟周期内完成了N个样本的处理，并在下一个时钟周期可以接受新的数据。
   当然也可以生成II<N的设计，但是那是没有必要的，也会耗用大量的PL资源，其实设计可以以一个比系统其他组成部分更快的速度运行就完全足够了。类似的，循环启动距离(loop initiation interval)表示要下一轮循环开始处理数据的时间。

   时延（latency)：表示函数需要完全计算出所有输出结果的时钟周期，它仅仅指数据从提供到结果被算出这段时间。循环迭代时延(loop iteration latency)是指完成一次循环迭代需要的时钟周期，循环时延(loop latency)则表示完整完成一次循环的时间。这里还有一部分不太理解：
   
   Area Estimate：这部分强调的是此设计占用了多少PL资源，最重要的衡量指标是使用率（utilization），超过100%表示资源使用超额，但是就像timing一样，后续的优化有可能会减少所用资源的开销。

3. 对指标的优化：LOOP_TRIPCOUNT,当设计中含有循环，而循环的次数为变量值时，综合之后的报告无法正确的报告时延或间隔，取而代之的是?。这时候我们可以用LOOP_TRIPCOUNT来为HLS手工指定一个我们自己对循环次数的的预估值帮助它完成性能评估报告，此优化不对设计本身的综合产生任何影响。

4. 对性能的优化：流水线（PIPELINE,DATAFLOW,RESOURCE,Config Compile） PIPELINE:使一个循环或者函数的内部操作并行执行来减少启动距离。
   DATAFLOW:启动任务级并行，使得函数和循环可以并行执行。
   RESOURCE:在变量被实现为硬件时指明对硬件资源流水化，比如说我们将数组综合为双端口RAM，当循环展开时，就可以借助双端口RAM实现并行化。（一般来说很少用到，除非要榨干最后一点并行化）
   Config Compile：在自底向上的设计流程中，让循环能够按照它的迭代次数自动流水化。 注意以下几点：
   A．有些函数包含子函数，在子函数没有流水化的情况下，将主函数流水化性能提升可能会很有限，这部分瓶颈就是子函数没有流水化导致的。

   B．有些循环包含子循环，当使用PIPELINE来指导综合时，这部分会将子循环全部展开（unroll all loops），这会耗用大量的逻辑资源，一般来说在较低层循环来实现流水化更加有意义。

   C.将包含子循环的循环流水化（PIPELINE）不可避免时，要注意子循环中含有变量循环边界的循环没办法展开，以这些变量循环边界作为子循环的上层循环也没法流水化。为了解决这个问题，可以考虑将这些含有变量循环边界的循环流水化，并且用DATAFLOW来将它们任务级并行起来。顺带提一句，当把一个设计流水时，在流水段内部不允许有时序逻辑的存在（废话一句，删掉😊）

5. 硬件函数流水策略：首先介绍两种C/C++函数，Frame-Based和Sample-Based，对于HLS而言，两种编程风格的不同影响了directives是如何被应用到这些函数上的。

   Frame-Based的C代码：它的一个重要特征是函数处理的是多个数据样本（通常是数组或指向特定连续空间的指针），数据在多层循环中被处理。

   Sample-Based的C代码：它的重要特征是函数处理的是单一数据样本
   一般来说，想要达到最高的硬件效率，需要将流水化在单一样本处理的那一个维度上施加，所谓一个样本就是函数功能的独立处理单元，比如图片中的一个像素，这需要按照函数目的确定。
   这部分手册展示了一个非常漂亮的例子，在此把结论简单记录：

   Frame-Based：
   A.对于Frame-Based风格的代码，最好的流水施加点是单一样本处理点
   B.如果切流水的层次太高，会造成一次读入大量数据，并且由于子层次的循环全部展开，会产生大量的硬件逻辑，而受限于带宽，无法全部并行，所以这部分的展开是白白浪费的，对吞吐率并无贡献。
   C.如果切流水的层次太低，也就是在单一样本的处理算子上流水化，这部分速度就太慢了，需要很多个时钟才可以处理一个样本，跟不上PS端的处理速度。
   D.如果有多个层次相同的循环，那么可以考虑将每一个循环按照上述方法分别流水化之后，再将多个循环用DATAFLOW来任务级并行。

   Sample-Based：
   A.Sample-Based类型的C代码一次只处理一个样本，并且往往在函数内部有一个静态变量。
   B.最好的方法就是在函数一级流水化