report_design_analysis可以用来对时序问题的根本原因进行分析，进而寻找合适的时序优化方案，达到时序收敛的目的。
一、分析时序违例路径
Vivado工具会优先对最差的路径进行时序优化，最终并不一定成为critical path。因此分析时序违例路径时，并不仅仅关注critical 路径。以下tcl命令可以报告最差的50条setup timing path。
report_design_analysis -max_paths 50 -setup
时序报告如下图所示：
首先关注逻辑延时（Logic Delay）和线延时（Net Delay）根据逻辑延时和线延时的比例不同，路径分析方向也略有不同。
1、逻辑延时较长
a)逻辑级数过多（Logic Levels）：一般可以修改代码，增加寄存降低逻辑级数
report_design_analysis -logic_level_distribution -logic_level_dist_paths 5000 -name design_analysis_prePlace //分析设计中逻辑级数的分布
通过上述命令可以对设计中的逻辑级数分布进行分析，进而判断是否存在不满足时序要求的逻辑级数。报告如下所示，该设计最长逻辑延时为5，推荐最长逻辑级数根据时钟频率和器件不同而不同。
如果需要进一步确定逻辑级数最长的路径可以采用如下命令：
report_timing -name longPaths -of_objects [get_timing_paths -setup -to [get_clocks cpuClk_5] -max_paths 5000
-filter {LOGIC_LEVELS>=16 && LOGIC_LEVELS<=20}]
//筛选cpuClk_5时钟域逻辑级数在[16,20]之间的路径
b)存在DONT_TOUCH或者MARK_DEBUG等约束，阻碍工具进行逻辑优化
c)路径上存在逻辑延时较长的单元，比如DSP和BRAM等
2、线延时较长
a)扇出较大：加max_fanout选项或修改代码手动复制高扇出信号
report_high_fanout_nets -fanout_greater_than 50 -max_nets 100
执行上述tcl命令可以报告扇出大于50的100条最长路径。
命令生成的报告如上，可以分析fanout和驱动类型，推荐最大fanout与器件和设计频率相关。
对于较大的fanout，最好改为寄存输出，如下所示的LUT输出是不推荐的。
b)物理位置较远（比如分属不同的pblock）
c）SSI器件是否存在跨die信号
d)拥塞引起走线不正常
一般可以通过device视图中观察，如果走线路径比较扭曲，明显不是最优路径，可以考虑是由于拥塞引起，需要进一步分析该区域的congestion程序
二、经验总结
1、时序分析应该贯穿整个综合实现流程，综合后就可以采用report_design_analysis命令对扇出、逻辑级数等进行分析，增加迭代速度；
2、优先采用default策略进行实现，可以避免工具过多的优化设计，更好地暴露时序问题的根本原因；
3、不同器件、不同设计频率下，推荐最大逻辑级数和扇出不同，例如ultrascale器件，设计频率大于400MHz时，最长逻辑级数尽量控制在3以下；
4、跨SLR信号建议源和目的模块各寄存一级
注：参考文档为《ug906-vivado-design-analysis》。