相比于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代码的对应关系。
没有回复内容