Vitis HLS 2022.1：如何阅读C Synthesis生成报告

相比于Vivado HLS，Vitis HLS在C Synthesis之后生成的报告内容更加丰富，更有利于工程师对设计进行分析。这里我们以Vitis HLS 2022.1为例，看看C Synthesis之后的报告都包含哪些内容。

总体而言，整个报告由8部分构成，如下图所示。Vivado HLS通常只包含前五部分内容。其中General Information部分呈现project名称、solution名称和具体的芯片型号。Timing Estimate部分则展示了目标时钟周期和预估时钟周期。

Performance & Resource Estimates是报告的重点部分之一，具体内容如下图所示。从Performance角度看，显示了每个子模块/循环的Latency以及整个设计的Latency，如图中桔色方框所示。同样也显示了相应的II（Initial Interval），如图中红色方框所示。对于循环，还能看到循环次数（Trip Count），如图中蓝色方块所示。无论是函数还是循环，是否使用了Pipeline，会以no或yes来表示，如图中绿色方框所示。从Resource角度看，报告会呈现主要资源如BRAM/URAM、DSP、LUT和FF的使用量，如图中紫色部分所示。

如果C Synthesis之后，无论是Performance还是Area未能达到预期目标，工具会给出违例类型，如下图红色方框所示出现了II违例。

Performance & Resource Estimates报告中的资源利用量是预估值，与RTL综合后的结果相比，有时会有较大出入。例如，上图中显示LUT的用量为33k，而RTL综合之后的报告显示只有6k，如下图所示。造成这种偏差的一个主要原因是Vivado在进行RTL代码综合时会进一步对设计进行优化，从而降低了资源利用率。

HW Interfaces会显示生成的RTL代码顶层对外接口，包括顶层控制接口，如ap_rst、ap_start、ap_done、ap_ready等，如下图所示。

SW I/O Information部分除了显示顶层C函数的形参信息外，还会显示形参与生成的RTL代码输入/输出的对应关系，如下图所示。

Pragma Report则会显示设计中使用并生效的Pragma，如下图所示。这对判断Pragma对设计性能和资源的影响非常有利。对于未生效的Pragma，也会在这部分以Ignored Pragmas列表显示。此外，有些Pragma尽管生效，但会有警告生成，这样就会以Pragmas With Warnings列表形式显示。

Bind Op Report则会显示设计中的一些算术运算、涉及到浮点数的运算以及消耗DSP的运算的实现形式，如下图所示。图中op列表明运算类型，Impl列表明实现方式，这里的fabric就说明使用的是SLICE里的资源实现的，Latency列则体现该运算输入到输出的时钟周期个数。从这个报告中包含Op的每一行都可以到C源文件中，这样就可以清晰地看到Op与原始C代码的对应关系。

Bind Storage Report则会显示设计中的数组在转成RTL代码后的具体实现方式，是采用LUTRAM、BRAM还是URAM。

总体而言，Vitis HLS的报告内容比Vivado HLS更为丰富，信息更为全面，例如不仅有生成RTL代码的输入/输出接口，而且还有顶层C函数形参与之的映射关系。同时，从报告可以直接到C代码，直观地体现了报告内容与C代码的对应关系。

Copyright @ FPGA技术驿站

转载事宜请私信 | 获得授权后方可转载