Felix

技术源于积累,成功始于执着! 个人邮箱:justlxy@mail.dhu.edu.cn QQ:1576109464

Synplify Pro的RTL视图与Technology视图以及优化分析

3
阅读(3493)

在进行Verilog/VHDL Coding的时候,很多人喜欢先通过检查设计的RTL视图是否符合预期,然后在通过功能仿真和时序仿真来验证设计的功能正确性。

以Lattice Diamond/Radiant 开发工具中集成的Synplify Pro为例,用户可以在弹出的Synplify Pro的界面中的HDL-Analyst->RTL打开RTL视图(综合完成之后)。需要注意的是,RTL视图所显示的内容只是综合工具对设计的第一步优化,这一过程优化过程中会自动删除一些比较明显的没有用到的逻辑,并在Report中列出被优化的原因(一般是该逻辑/模块的输出继没有驱动其他逻辑/模块,也没有输出到IO或者FPGA内部的Harden Core;或者是某些内部未被有效使用的寄存器或者其中的部分bit)。但是,RTL视图显示的并不是Synplify Pro的最终综合结果,因为RTL视图只是Compile阶段的结果;而Technology视图显示的则是Synplify Pro (Pre-) Map的结果,该过程会对用户的设计做进一步的优化,同时插入GSR(如果用自己没有插入的话,同时使能了Force GSR选项)以及IO Buffer,并将RTL转换为LUT和FPGA内部的Harden资源等等。

当然,如果设计者进行了时序仿真,即使不查看Technology视图也能发现设计的功能存在问题,但是可能不如查看Technology视图来的直观。但是问题是,有些人只做一遍功能仿真,几乎不做时序仿真,也不去查看Technology视图以及综合报告。这样有些隐藏的问题可能就很难发现了。下面将举例说明:

在跑完Compile之后,查看RTL视图,如下:

blob.png

可以看到,设计RTL视图符合预期,一共有6个模块,分别是wb_tlc,wb_intf,wb_tlc_req_fifo,wb_tlc_cpld,wb_tlc_cpld_fifo和wb_tlc_cr。和Verilog Code是一致的。

进一步运行Pre-Map,得到Technology视图,如下:

blob.png

可以看到在Technology视图中,原本的6个模块少了两个,wb_tlc_cpld和wb_tlc_cpld_fifo被优化掉了。这说明了,RTL视图和Technology视图并不一定是完全对应的,Synplify Pro在Pre-Map的过程中会对用户的设计做更深层次的优化。

下面,我们来分析这两个模块被优化的原因。

查看该视图的顶层调用Code,如下:

blob.png

图中红色框中的这两个信号是传递给wb_tlc_cpld_fifo的,而在wb_tlc_cpld_fifo模块中,这两个信号则是输出使能,当这两个信号任意一个值为0时,wb_tlc_cpld_fifo中的状态机将一直停在某一个状态,等待这两个信号变成非零值。Synplify Pro认为这是无效的逻辑,因此在Pre-Map过程中直接将wb_tlc_cpld和wb_tlc_cpld_fifo优化掉了。

当我们将这两个信号的值改为非零值时,重新Compile并Pre-Map,得到的新的Technology视图如下:

blob.png

可以看到,此时的Technology视图是和RTL视图一致的,也就是说wb_tlc_cpld和wb_tlc_cpld_fifo没有被优化掉了。


总结:在Verilog/VHDL Coding的时候,可以将Technology视图作为分析的手段之一,而不是仅仅去看一看RTL视图。为了保证设计的正确性,尽量进行时序仿真,一方面是分析时序问题,另一方面也可以看看是否存在设计被优化的情况。

Baidu
map