在进行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视图，如下：

可以看到，设计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视图，如下：

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

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

查看该视图的顶层调用Code，如下：

图中红色框中的这两个信号是传递给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视图如下：

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

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