阎浮提 · 2022年03月21日

后端进阶系列:Setup&Hold互卡问题和Useful Skew的影响

最近工作告一段落,终于有时间和大家继续分享后端知识~

想写本篇的初衷源自于最近的几次面试提问。小编自认为并不是喜欢刁难人的面试官,对“面试造火箭,工作拧螺丝”的现象也感深恶痛绝,因此许多提问都是针对实际中可能遇到的问题。最近面对多名面试者,有两个问题很少有人能准确地给出答案,不管是工作一两年还是三五年甚至六七年的,总有很多人不能完全理解,甚至不少人的理解根本就是错的。今天特地开篇详细阐述这两个问题,希望对大家有所帮助。

问题一:setup与hold timing互卡(conflict)现象的成因主要有哪些?如何解决?

首先,有人可能会问:“我做了好几个项目也没怎么遇到这种问题,真的有必要弄明白吗?”其实这可能主要归功于所在公司完善的流程和设计迭代,而这类现象在实际中其实并不少见。比如在流程不太完善的初创公司中很难早期发现这类问题,加上不少工程师本身经验不足,在PR阶段没有详细检查结果就进入ECO,等ECO走到最后才发现少量path出现这类问题。这个时候再返工PR显然不太现实,只能硬着头皮修,因此这个问题绝对是有讨论的意义的。

从成因上来说,个人总结setup&hold互卡主要有几种因素的影响:

a) 不同PVT条件下的cell delay variation较大
b) 某些cell的library setup time或library hold time特别大
c) setup与hold的uncertainty或者derate约束较为严格或悲观
d) launch, capture的clock common path很短,OCV因素导致setup和hold都很难收敛

有些path是某一种原因导致的,另外一些path可能是几种因素叠加而产生的互卡。

从path的类型上来说,小编认为setup&hold互卡主要有三种情况:

1) 同一endpoint的setup&hold互卡,但startpoint不同
2) 相同startpoint与endpoint的setup&hold互卡,但中间经过的data路径不同
3) 相同startpoint与endpoint的setup&hold互卡,且经过的data路径完全相同

其实1, 2两种情况相对简单,只要仔细分析大概率可以找到有margin的点去修hold或者setup,最麻烦的是3)这种情况。在了解上面几种因素的基础上,我们可以看一条具体的path来分析这个问题。以下path的delay值根据实际案例做微小修改以突出问题的症结。

例:假设下面的path在worst PVT条件下的setup slack如下所示:

image.png

而对应的best PVT条件下的hold slack如下:

image.png

可以看到setup和hold的slack都是负的。仔细分析delay值可以发现,导致这种情况发生的原因是多样化的:

1) 不同PVT条件下clock line的delay大概呈2倍比例,而data line的delay比例高达3.4
2) clock line完全没有common path,计算slack的时候没有任何CPPR的补偿
3) library hold time数值过大
4) hold corner的derate比setup更严格(悲观)

明白了上述原因,再想解决办法就相对简单了。library hold time本身如果lib没有问题,后端很难去改善,如果是sram的话设计早期还可以考虑换类型,但是到ECO基本就没有办法了;hold corner的derate属于signoff约束,一般也不能轻易改动,否则很难保证STA的准确性;因此我们能做的就是在原因1)与原因2)上想办法:

对于1)来说,就是很多人常说的某些cell在不同corner下的variation较大,我们可以去一一对比找出该cell的类型,将其替换成variation更小的cell;

对于2)来说,我们可以想办法增加两条timing path的common clock path,这样CPPR就可以扣掉部分悲观量,从而缓解setup与hold的slack。一般可能需要多管齐下才能很好地解决这种问题。非常建议大家对照上述公式计算一下考虑CPPR的情况下slack会有怎样的改变

问题二:useful skew解setup violation的具体做法有哪些?分别有什么影响?

Useful skew的概念本身很多人都知道,工作一年半载的人都能侃侃而谈,但是具体如何做其实很多人并不清楚,只知道把工具的CCD/CCOpt功能打开并且认为这就是useful skew的全部内容。其实useful skew本身是为数不多的纯粹属于数字后端工程师的修timing技能,它的应用也绝对不是工具的命令和option。

我们考虑下面一组timing path:

image.png

上图中有三条timing path: A, B和C,有4条clock路径到达各个DFF分别为1, 2,3和4。如果现在timing path B的endpoint上有setup violation,我们可以怎样调整clock可以修掉它呢?根据setup的定义可以知道,做短clock路径2和做长clock路径3都可以修掉B处的setup(不考虑实际情况是否允许做短和做长)。那么这两种方案分别有哪些影响呢?

方案一:做短clock路径2,也就是path B的launch clock。

其影响在于path B本身的hold会变差,同时path A的setup也会变差,因此需要分别检查二者是否有足够的margin支持将clock路径2做短。

方案二:做长clock路径3,也就是path B的capture clock。

其影响在于path B本身的hold会变差,同时path C的setup也会变差。因此需要分别检查二者是否有足够的margin支持将clock路径3做长。

其实这个问题的本质并不复杂,大家需要记住和理解的是:**对同一条path来说,setup变好hold就要变差,反之亦然。同时capture变长对setup有利对hold有害,反之launch长对hold有利对setup有害。

来源:数字后端设计芯讲堂
作者:数字后端设计芯讲堂

推荐阅读

如果大家有任何后端技术与职业发展方面的问题,抑或关于数字后端感兴趣的技术话题想要了解和探讨,欢迎关注我的知乎专栏: 数字IC后端设计工程师修炼之路
同时欢迎关注微信公众号:数字后端芯讲堂,一起探讨技术,共同提升!
本极术专栏也会同步更新芯片设计后端的技术干货,也请关注数字IC后端设计工程师修炼之路
推荐阅读
关注数
3845
内容数
46
本专栏致力于将数字芯片后端设计的技术,经验和技巧介绍给想入门或提高的你。一方面从基础知识方面的讲解使初学者少走弯路,另一方面用实际工作中的经验技巧方便从业者提高和交流。
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息