往期文章链接：
本期访谈人物为“小A”，在访谈他时，他对内容做了思维导图，让我很感动，小A说技术问题不能说错，由此可见小A对技术的态度。
1.问：能简单讲一下你做过的工作吗？比如PR几年？STA几年？
小A：PR做过三年，做过比较难的模块，比如DDR、SERDES、高速核。
2. 问：项目Signoff最重要也是最耗时是STA,你觉得STA为什么这么重要？为什么最后Fix Timing最耗时间？
小A：
重要性：
（1）芯片核心竞争力是PPA，其中一个是性能Performance，STA是静态分析，相对于动态验证（只能覆盖部分case），是全覆盖的，保证芯片所有寄存器以及Path都可以分析到。保证性能和功能都是正确的，保证芯片生产出来能跑到特定的频率，而且不会出问题，对应STA验证的两个大方向setup和hold，所以比较重要。
耗时长：
（1）先进工艺分析的mode比较多，各个mode需要同时signoff，有可能存在不同mode互卡的情况；
（2）在项目后期，flatten 验证run time比较长；项目比较大，path比较多，需要快速分析问题的能力，能找到修复策略，这个很耗时间，这个需要很丰富的项目经验和很强的脚本能力；
（3）Timing Fix策略：先修复什么，后修复什么，需要STA负责人整体把控；项目前期，Top Only加Block ETM Model分析方式，可能分析的不准。ETM Model本身就不准。还有sdc的一致性，top only和flatten sdc一致性，block 和top 切的block sdc的一致性（block sdc和flatten sdc的负责人可能不是一个人，对design的理解不一致，比如频率不一样、block port进去两个时钟是异步的，但是在flatten是同步的、block 的path exception block加了，flatten没加，flatten的sdc一般比较滞后，根据block的往上集成，写flatten sdc的人对block sdc有个理解的过程，需要准确理解block sdc的意图，不能多，也不能少），前期没有验证到，后期Flatten 发现了，Debug起来很费时间；STA后期迭代是跟着PA/PV一起迭代的，任何PA/PV的改动都会影响Timing，所以要保证同时收敛就很麻烦。
3.问：为什么Block之间(接口)的Timing比Block内部的Timing更难收敛？会存在由于前期Floorplan不合理或者别的原因修不掉的情形吗？
小A：
（1）在实现的时候block owner一般关注内部的timing，不会关注接口的timing，发现问题的时候就相对滞后了；
（2）接口涉及到两个方向：block跟block之间、block跟top only之间。这两种方式，clock在top only都会分叉，导致非common path比较长，derate吃掉setup margin比较大，导致setup不好收敛。对应block和top only（两个block相距比较远）还涉及到插pipeline，pinpeline需要怎么摆放和打几拍需要验证（可以按照频率和距离计算，最好保守操作），前期ETM不准可能验证不好，top pr对pipeline和第一级寄存器之间处理不好，也不容易收敛。
（3）Block和Block是不是pin to pin？block in to reg和reg to out data path是否干净，最好是in 到reg和reg 到out，至少保证reg 到out是干净的，不要插太多逻辑。否则到top再插一堆逻辑，本身就是不可满足的，风险很大。还有block A输入时钟和 top only要做同步，接口reg to out和in to reg方向寄存器的时钟skew，能不能保证tree是平的，有可能会整体推tree，比如整体block tree比外面长或者短一些，整体推tree就可以整体少很多Fix的时间；但如果tree长的不平，一推就会出现反向的时序违例，其实是提前规划的问题。
有，没有遇到过救不会来的，项目前期和设计、系统的同事沟通时钟/复位方案的时候，太长或者分叉太早，有的在top crm就分叉了，需要在两个block收敛，应该提前规避这种问题（设计的人可能意识不到这种风险，需要STA负责人提出收敛风险，所以STA负责人需要在项目前期就介入，后期都物理实现了，STA能做的就很有限）。
（1）pipeline插得比较远，第一级寄存器离block输出比较远，项目后期需要ECO加拍解决；
（2）block长的太长，比如3ns以上，OCV吃的太多，top only本身就长，这样把setup margin吃的就差不多了。
4. 问：为啥异步约束（异步复位，同步释放）或Multicycle等这种SDC比较容易出错？却难检查出来，之前遇到过后仿才检查出来，项目已经到非常后期了，感觉风险很大，对此有什么好的检查办法吗？
小A：不好检查。
（1）STA收敛的人不负责SDC交付（可能每个公司不太一样）。STA收敛的人只是验证在SDC约束下有没有问题，不会验证SDC本身有没有问题。有时候从一些细节上也会看到存在的问题。比如，check_timing的时候unconstrain endpoint或者看timing exception文件的时候，A timing exception path、B timing exception path，B的优先级高，把A的overwrite了，这也需要看到。
（2）写path exception的人，对SDC的理解不够。比如约从A reg到B reg的max_delay，如果起始点约到CP端和Q端是完全不一样的工具行为。如果约到Q端，同步路径全完蛋了，就是异步路径或者只是一个max_delay路径，只会看到A到B，A到正常路径的同步path就看不到了，导致约束意图和SDC不匹配，导致漏约。这个需要看详细的rpt和log。
（3）继承性的IP，from hier/ * ,有可能只是reg0和reg1 需要做multicycle，但是综合的时候做成4位的muti-bit reg，这种就多约。path exception往上集成需要非常小心。对对于A时钟和B时钟的exception更麻烦，有可能path exception在block没有问题，但是集成到top就会有问题，可能多约。漏约不怕（比如multi-cycle没约上，按照同步处理，没有问题），怕多约。
（4）跨时钟的处理：如果前端处理不够或者忘记处理，需要不定态的传播，后端插出来，需要向前端确认。
设计意图--SDC约束（不漏约，不过约）--工具行为，都需要了解到位，才能做好。
前端仿真会对这些做仿真，spyglass仿CDC检查。但是不一定能查全，需要大家互相检查，互相弥补。
5.问：Clock Tree做的好不好对Full Chip Timing收敛很关键,从Timing收敛的角度讲对Clock Tree有什么建议？Clock Tree需要做到哪种程度才能迭代Full Chip Timing？
小A：对于做tree来说输入SDC准确性很重要，可以指导写spec的人写出好的spec，其次好的tree就是最终好的时序，block的tree关注的比较少，top only的tree必须要做好，做好的指标是到postroute top only的时序是可控的，其次到block接口tree的长度需要固化，每一版数据之间是可预测的，不能80%网表收敛没有问题，100%网表长tree方案变了，导致80%网表工作就白费了，长tree策略是固定的，latency是可控的，这样在80%网表结束的时候基本有一套修复方案（可以修不完，但是知道怎么修）。主要是top only tree的质量，不能有太大crosstalk传进block。H tree和常规工具长tree latency和OCV相差很大（前期策略很重要）。
6.问：对于不同公司Uncertainty、Derate、Signoff Corner设置约束不太一样但是流片回来测试都能过，这是为什么？
小A：
（1）corner的选择和芯片的应用场景有关，比如这个芯片就会在m40C工作，那timing收敛的时候就可以不考虑WCL的情况；有的纯粹就是冲频，可以升压或者保证工作温度，就可以放松；
（2）uncertainty没有那么多要求，先进工艺要求就是pll jitter（仿真准确性），T的要求就是pll jitter加上5ps或者10ps，一般公司加的会比signoff文档严一些，保证良率高一些。
（3）derate：一般会按照最悲观的来，最后做不下去可以放松一些。做的好的公司都是自己K库，按照自己的derate设置，TSMC给的设置没有问题，保证下限。
这三个合起来是一整套signoff 策略。
7.问：对于综合和后端STA岗位SDC分别需要掌握到什么程度？掌握SDC对Timing分析的重要性体现在哪？
小A：
（1）我是从后端转到综合的。就会从后端的角度做综合，知道怎么约对STA收敛更友好，知道每一个SDC命令工具是怎么理解的，是怎么分析timing path的。可以理解同一组group设async和physical_exclusive的工具行为的区别。如果设async，timing window就是无限的，如果设置physical_exclusive就不会检查两个时钟之间的crosstalk。其实是从设计，到综合和DFT，到工具行为的理解，最好是都理解通。综合是要把设计的意图翻译过来，写成SDC，双方要能理解双方都能听懂的话。
（2）1.懂设计才能写出好的SDC，好的SDC才能保证更好的STA收敛；2.好的SDC可以指导TOP PR的人做时钟树，做出来timing就会好一些，timing就能更好的收敛；3.top pr和sta sdc一致性问题，如果不一致，全芯片debug会很费时。
8.问：脚本能力是不是对做STA很重要？有种说法是Fix Timing就是脚本的处理，你怎么看？
小A：如果前期时钟架构规划好，后期就分两个方向：1.从很多后端报告中提取想要的信息，这就是脚本能力；2.就是分析能力。能从抓出来的信息归类找到问题。脚本只是能帮助你快速分析的手段。Flatten sta刚开始违例path 几十万条，看一条条看不行，每个人都有每个人能的策略，每个人都有自己用的顺手的脚本，可以写很详细的脚本，把需要关注的信息都抓出来，抓大放小，尽快找到fix的策略。
9.问：定Signoff标准是不是STA中最有技术含量的，定好了就剩迭代Fix了？
小A：个人感觉在大公司可操作性不大，大公司有成熟的标准，即使悲观，为了保证不出错也不会轻易改变。算标准的话（根据Foundry提供的文档，corner会有明确说明；uncertainty根据jitter算，操作空间不大，可以稍微加点margin；derate也是根据文档算的），对于工作两三年的人也可以教会。有的公司有专门的signoff团队，根据自己的很多回片测试经验是会放松一些标准，可以做到更高频。如果有自己的std cell，mem，IP、IO团队，就知道自己库文件的底线在哪里，可以不follow foundry建议。
10.问：后端STA岗位和哪些岗位工作会有交集，能简单聊一下交互内容吗？
小A：产品部门、设计部门、综合SDC、DFT SDC。所有的需求都是从产品部门传到设计部门，如果传递不准确就可能导致过约问题。
11.问：对于新入门的员工，学习STA有什么建议？
小A：建议从PR开始，后端的核心是PR（Floorplan和CTS，做CTS很考验功力，sdc和做tree的spec，spec最好自己会写），都是围绕PR转的，指导PR怎么做的，才能更好的指导PR的人fix timing；基础知识要扎实，比如STA工具、命令，静态时序分析的一些算法、脚本能力（一次修1000条和100条差很多），必须了解的很透彻；STA考验的就是分析能力，一通百通，再看所有问题都是同一类型问题。STA岗位很辛苦，准备好加班。
作者：小蔡
文章来源：小蔡读书
推荐阅读
更多IC设计干货请关注IC设计专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
