UltraFast设计法实践(1) -- 初始设计检查

zoukankan html css js c++ java

UltraFast设计法实践(1) -- 初始设计检查
目录
1. report_failfast
1.1 命令使用
1.2 优化
1. 2.1 LUT Combining
1.2.2 control_sets
1.3.总结
2.report_timing_summary
3. report_methodology
4. 总结
5.遗留问题
参考文献：
平台：Vivado16.4

芯片：xc7a200

《UltraFast Design Methodology Timing Closure Quick Reference Guide 》(UG1292)第一页的主题是初始设计检查，这一步是针对综合后或者opt_design阶段生成的dcp，该阶段主要要读懂三个操作生成的报告，这三个操作是：
1. report_failfast
2. report_timing_summary
3. report_methodology
1. report_failfast

1.1 命令使用

有的平台一开始并不能直接使用report_failfast命令，需要安装Xilinx Tcl Store，安装方法见：干掉Vivado幺蛾子（1）-- Xilinx Tcl Store。

在工程综合完成之后，需要打开synthesized design（open synthesized design)，使用Tcl命令：xilinx::designutils::report_failfast ，会在Tcl Console窗口得到一张图表，如下图所示：

这张表反映的是工程对资源的使用情况，包括参考(推荐)比例、实际比例和状态。当各项实际使用率都符合参考的话，工程进行后续的过程才会相对可靠。我们尤其要关注状态为“REVIEW”的项，它表示超过的参考推荐值，可能存在风险。

我的报告中状态为“review”的有两项：LUT Combining和Control Sets。

1.2 优化

1. 2.1 LUT Combining

先看LUT Combining，查阅《UltraFast Design Methodology Guide for the Vivado Design Suite》（UG949）中关于它的含义。文中对其的描述如下：

LUT combining reduces logic utilization by combining LUT pairs with shared inputs into single dual-output LUTs that use both O5 and O6 outputs. However, LUT combining can potentially increase congestion because it tends to increase the input/output connectivity for the slices. If LUT combining is high in the congested area (> 40%), you can try using a synthesis strategy that eliminates LUT combining to help alleviate congestion. The Flow_AlternateRoutability synthesis strategy and directive instructs the synthesis tool to not generate any additional LUT combining.

大意是有的LUT pairs共用一些LUT的输入，从而把O5和O6都用上，然后导致线路拥堵。

随后看到这样一个tip:

意思是让我执行report_qor_suggestions，试试看，反馈了一些结果，建议opt_design -remap，完成之后再report_failfast，结果反而恶化，但LUT使用减少，如下图

随后，UG949中建议尝试方法：
- synthesis setting -- strategy -- Flow_AlternateRoutability
说可以采取修改综合策略的方式来优化，将策略改为Flow_AlternateRoutability可以减少LUT combining，从而可以优化拥堵的情况。改后综合，report_failfast报告如下，LUT combining确实减少了，但LUT增加了，这是可以理解的，因为LUT Combining就是复用一些LUT的结果，现在不复用了，所以LUT的使用率增加了。

1.2.2 control_sets

先不管LUT，因为这个可以后期优化掉或者精简代码实现。现在只剩control_sets了，查UG949中对control_sets的描述，如下：

Often not much consideration is given to control signals such as resets or clock enables. Many designers start HDL coding with "if reset" statements without deciding whether the reset is needed or not. While all registers support resets and clock enables, their use can significantly affect the end implementation in terms of performance, utilization, and power.

大致理解是跟一些使能或者复位信号的不合理使用相关。使用report_control_sets -verbose 获取control_sets的详细情况，貌似是导致control_sets的一些设计，然后发现我的模块中大量的跟以下这样一个信号有关，而这个信号大量的作为使能信号。
```
 assign w_divisor_valid = (mult_cnt == 6'd39);       // control set 过高可能有这个原因
```
这样设计是有问题的，故改为时序设计：
```
    always@(posedge clk or negedge rst_n) begin
        if(rst_n == 1'b0) begin
           w_divisor_valid <= 1'b0; 
        end
        else if(mult_cnt == 6'd38) begin
            w_divisor_valid <= 1'b1;
        end
        else begin
            w_divisor_valid <= 1'b0; 
        end
    end
```
之后，再综合--report_failfast，满足要求了！！

1.3.总结

report_failfast生成的项目报告，查看哪些项是REVIEW，然后针对每项内容是什么含义，导致的可能原因，建议的优化方法等都可以从UG949中查看，不断反复尝试，直至可以接受的结果为止。

2.report_timing_summary

report_timing_summary可以生成时序报告，除了查看时序违例路径之外，该报告还可显示时序约束是否存在潜在问题。注意：此阶段主要关注的是主要的时钟约束有没有加上？有没有loop？ 即基本的时序设计有没有问题，至于一些时序裕量不足的情况，个人认为，此阶段要完全解决是不太现实的。毕竟这是设计初期，想要解决所有问题是不可能的，后面还有很多优化过程要完成。

3. report_methodology

在有个工程的report_failfast报告中，有几项有关TIMING的项报REVIEW，看不出哪个条线路或者环节出了问题，从UG949中并不能找到详细的答案，这个时候就需要用到report_methodology。

执行该命令，主要检查的是涉及到时钟的RTL代码设计，尤其需要关注Bad Practice，这就会详细的风险问题出在哪个环节。

4. 总结

第一阶段的初始设计检查主要根据report_failfast报告的内容逐一优化REVIEW项，结合report_timing_summary和report_methodology 生成的报告，看看RTL和时序层面有没有设计问题，反复迭代，尽可能使三个报告“干净”。再次强调（当然是个人拙见），初期解决所谓时序问题是不太现实的，后面还有很长的优化过程，也许还有不断反复迭代，

5.遗留问题
- 实际上在report_failfast报告中有关TIMING的几项，并没有很好的理解其中的含义，换言之，为什么会出这些问题，时钟之间到底存在哪些关系。
参考文献：
1. UG949
2. UG1292
3. 深度解析ug1292（1）
查看全文