IC设计中通常基于设计时间线/业务线分为前端设计和后端实现,这个也是大家通常所能理解和接受的。类似下图
可以看到这里的FE/BE有一个明显的桥接地带,就是逻辑综合(synthesis),所以在实际的公司业务部门分部上,会有下列三种情形存在:
- 将综合部分会划归为前端
- 将综合划归为后端
- 将综合单独出来,变为中端(ME:middle-end)
这里的三种方式笔者都有接触,相对于不同业务各有优缺点,但是从芯片的整体规模日益增大的趋势下,第三种的情形未来应该会越来越多
方式 | 适用情形 | 优势 | 不足 |
---|---|---|---|
综合划给前端 | 后端专注于版图,并且前端对综合的支持确实可以到位 | 减轻后端工作量。SDC/UPF的迭代更快速高效 | BE接入SDC/UPF过少,一些真实的问题可能会传播下去;前端人员工作量变得比较大,不利于推进功能收敛 |
综合划给后端 | 前端出具RTL,SDC和UPF,后端来s跑 综合。后端有一点前端基础,中间地带共同承担工作和风险 | 后端完成综合,很多问题可以尽早暴露;前端可以更专注代码,SDC/UPF只需基本了解 | 模糊地带,容易扯皮,每一版本的RTL更新,后端人员可以完全不了解,但是出了问题就需要去仔细排查,返工的次数会明显增加 |
综合划给中端 | 前后端都很忙,没精力/业务基础去做。前后端相互的独立性也比较强,交流不多的情形,使用这种方式比较合适 | 中端人员负责综合相关的一切,包括SDC/UPF/synthesis_release甚至后面的timing signoff等,业务专注度高,项目也可以从第三极的维度去瞻前顾后,只要中端转的流畅,前后端都会产出更好 | 公司需要额外的费用去搭建ME团队;ME团队的业务本质更像平台部门(类BE),当前的市场繁荣度还是稍逊于FE/BE |
这个话题放到前几年,可能还不是很敏感,从2020年开始,国内的初创公司多了很多,大部分都是BEless的模式。从保护自身核心利益触发,RTL代码是不便于公开的,所以采用网表交付就成为最优解,上述基本流程变成了
公司的中端部门基本就是公司的对外数据交付部门了,所有的数据出口都是这里,后端外包团队的结果会直接去到FAB进行TO。这里的中端组的权责就是:给外包团队提供数据和业务支撑,确保最终流片。
这种模式主要是服务于初创公司第一版的业务模式,快并且时间可控,费用自然会高。当然,简单的用一把资金能解决的问题一定只是部分解决。这种模式里的伤与痛,也只有真正经历过的同学可以体会的到吧。这个流程也是一种中间产物,从业务收敛上讲,最后还是会回归本文的开票所述的三种模式之一。
从结构图上看,中端犹如项目的腰(类核心力量),承上而启下,这个部位的带宽一定要足,确保前后端无缝衔接,犹如连接两个马达之间的传动轴,一定是需要细心呵护和用心经营的。
随着芯片规模和复杂的不断地增大,前两种模式通过类似一种刷前端/后端机时的方式已经很难在高速的发展中继续跟进了,专业的人做专业的事,独立的中端部门可以很好的解决下面的问题场景
-
SDC质量:不是不好,是不够好
- 时钟有,但是不全
- gen-clock都有,但是和master的关系不清楚
- clock的定义点不太合适
- CGU的写法对于后端实现的友好性
- DFT对SDC的影响考量
- clock 结构优化
- 使用MCP替换UPF
- IO约束的合理性
- 时钟树的重聚和细节(launch vs capture)
- 等等
-
UPF的各种小issue
-
load_upf可以,但是check_mv有error
-
isolation/LS插入的质量细节商榷
-
power-domain/power-state的合并和优化
-
对层次化设计的支持
-
全芯片rail的logic和physical的布局
-
等等
-
以上种种,看起来都什么大问题,但是对于大芯片而言,哪个细节出问题都是回导致大问题。芯片设计是一个很难收敛的硬设计,要保证系统的稳定性(stability),就必须降低/剪除系统的冗余性(Redundancy)/多义性(ambiguity)。这个特点对于静态的时序分析和低功耗分析的挑战尤甚,如果还是对此不太理解的话,可以想象一下RTL在跑linting的时候的信息量,就可以感知到静态分析的威力了。
类似的,对于综合(DC/Genus),静态时序分析(PT/Tempus),低功耗分析(vclp/LEC_low-power)的各种信息分类:info,warning和error(严格上讲,error是需要全部消灭的),也是需要中端团队查验的,
中端的任务是平抑前后端的差异,最终的服务对象还是后端团队,这里有一些简单的案例可以分享给大家,可能一点点的工作,就可以让后端的实施变得平滑通过是提高项目静态质量。
-
时钟的定义点必须是leaf cell的output pin:有时候为了方便,前端会把时钟的点位定义点放到CGU的一个hierarchy的输出pin,这样很容易下约束,但是会面临port punch的挑战,最惨代价就是在BE侧,导致这个时钟丢失。
综合view
APR cts view
这个情形,clock_out依然是一个clock point,但是由于APR 工具的push port,这个点依然是有clock 属性,但是却没法真实的驱动后面的逻辑了,也就相当于把这个clock弄丢了。
-
时钟的定义点需要尊重原著:有时候,clock是从外部的PAD进来的,但是由于PAD都是双向口,那么进来的那一只一定是固定的pin,可能会有同学用这个点定义clock, 譬如这里的C pin
这个从原理上讲,没有问题,但是却没有精确反应实际情形,有实际的风险,真实且正确的定义是这样的:
这样做是有它的道理的,不仅仅是点位的问题,一起看一下下图
可以看到,从PAD进到C的timing arc在rise和falling的线性度不是非常一致,这里在核算min-pulse width之类问题的时候,结果会比之前定义到C点上要悲观很多;如果定义到C点,回导致sign-off乐观,往往芯片最怕乐观,这种木桶效应的伤害,都是每个经历者的终身遗憾啊!所以这里的clock的定义点需要修正到PAD上。
常言道:精品必出于细品,只有好好品味把玩自己的数据库,才能做出真正的精品项目,只要比对手强一丢丢,那么你的出货可能就不止这么一丢丢了。各位同学,关注中端就从今天开始吧。