ICC2分析时序的神器 analyze_design_violations

如何分析并解决时序违例是挡在新手面前的一座大山，而降频，用LVT，撑面积，便是三板开山斧，当然并非所有拍板儿的都那么好说话，所以学会分析和解决时序违例就成了后端工程师居家旅行必备的技能（挥动三板斧也要师出有名）。

ICC2提供analyze_design_violations的命令，辅助用户分析时序违例，免去了大量时序违例逐条分析的痛苦过程。

analyze_timing_violations支持setup、hold分析，transition、noise，only_lib的分析。这里以hold violation的分析报告为例：

icc2_shell> analyze_timing_vilations -type hold

先看一下，hold violation都有那些原因，对应的条数又有哪些。

根据报告可以看到，519条“Small violations”，这种小到平时也懒得分析的path先放到一边，着重看看其他问题原因：

H1：Large clock skew（LCS）两条，使用图形界面展开clock tree分析，输出定义generate clock的reg到相同时钟域的sink之间的hold violation，setup余量不足，摆在面前的两条路，要么调tree，想办法把tree做短，要么分析data path，硬着头皮修。这里有一个冷知识，delay cell在不同pvt corner下的延迟偏移比较大，如果你发现path上插了一堆delay cell，hold violation还没修掉，setup余量就不够了，可以试着把delay cell换成buffer，再通过插buffer去修。

这里可以通过report_clock_timing -type skew -from xx/CK -to xx/CK来报告launch clock与capture clock之间的local skew，相较于report_clock_qor，report_clock_timing报告local skew是考虑derate的，也就符合report_timing看到的clock network delay。

除了skew引起的violation问题，报告中还有一项H9：Remaining violation （OT），这部分属于未分类的timing violation，不过不用担心，工具还提供net分析，如下图，虽然path分析上没有归类，但是只要有violation，工具总会给一个理由。

继续分析timing violation，在报告中找到没有分类的（OT）的violation path。

虽然path 分析没有给出violation原因，但是net分析时却告知了这条path上有一条net经过了high density area（DEN），在图形界面选择这条net，如下图，得出结论，局部利用率过高导致hold insert buffer找不到地方。

至此时序分析告一段落了，后面该调tree调tree，该插buffer插buffer，实在解决不了还可以降频，换VT，撑面积嘛。