今天给大家分享一条经典的时序报告（Timing Report）。
利用这个时序报告，小编自主命题了一道经典的时序分析笔试题。
透过这套题，我们可以学到如下知识点：
时序报告类型
Clock Skew合理性分析
RC反标
时序优化方法
多周期时序路径约束及setup，hold检查机制
下图所示为一条timing path的Prime Time timing report。
请根据这个report回答以下几个问题：
1）这是setup还是hold的timing report?
从时序报告中的Path Type：max和Library setup time都很容易得出这是一条setup的timing report。
这里可以拓展下，这个library setup time 0.33ns是如何计算出来的?（今年秋招小编面试过程必问）
2025届双非学员IC秋招学习经历分享
2）当前design是否已经做完clock tree synthesis? 如果已经做过CTS了，当前这条path的clock skew是多少？
从PT报告中的propagated这项就可以知道当前设计是已经做了时钟树综合的，后面的数值就是clock path的delay。
所以当前这条timing path的clock skew是1.53-0.85=0.68ns 。需要注意的是这个clock skew是巨大，而且是postive skew，它对当前这条timing path的setup反而是有利的，但对hold是不利的。
3）时钟clk和div_clk是同步还是异步时钟？
同步时钟，div_clk是clk的二分频。这里需要画出clk和div_clk的波形图。默认情况最严格的setup检查就是launch edge和capture edge分别是4ns和8ns时刻。
4）解释下当前timing path clock skew值可能得原因？
其一，分频寄存器Reg delay大，其二是当前Zro_Flag_reg寄存器的tree被后面其他clock path分支拖长了。
5）当前timing path RC反标是否正常？
当前timing path的net RC并非真实RC反标。 真实的RC反标符号是&。
6）如果要修复这条path的timing，都有哪些方法？
第一，优化data path delay
第二，设置多周期路径。如果当前这条timing path clock skew比较balance，timing violation会更大。但是当设置多周期multicycle path后，即便local clock skew非常小，这条timing path也是meet的。
需要说明的是我们设置多周期multicycle path约束，一定要找前端设计确认是否可以设置。
对于多周期时钟路径的时序约束，setup和hold检查机制，可以查看下面这种图。这里涉及慢时钟到快时钟和快时钟到慢时钟的多周期时序检查路径，大家一定要搞清楚这里面的-start选项和-end选项。
