棋子 · 1月12日

小蔡IC人物访谈录2——STA工程师的成长之路

往期文章链接:

小蔡IC人物访谈录1——Top PR工程师的成长之路

本期访谈人物为“小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)加入技术交流群,请备注研究方向。
推荐阅读
关注数
10965
内容数
1214
主要交流IC以及SoC设计流程相关的技术和知识
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息