罗风 · 2021年07月05日

综合 | 分工,方法学可讨论的点

最近胖懒累乏,欠更新,不安。最近跟一些朋友讨论了一些摸不着的“泛技术”话题,码一码。

111.jpg

综合,分工

“分工”是任何群居生物的基本合作模式,最原始的分工目的无非是为了提高效率、最大化群体效益、提高群体存活几率。人类社会得益于“吃铁丝拉笊篱”的编故事能力,分工可谓五花八门,且不可避免地会受“人为因素”的影响,安陵容使尽了浑身解数,都给雍正下了迷情药也没得到“协理六宫”的职位!

222.jpg

回到数字实现领域,以现行状况大概可切成:综合、DFT、PnR、signoff、DFM等几个任务段,分工通常也都按照任务覆盖点进行,不同的公司不同的产品分工虽有所差异,但以目前可谓“成功”的中大型公司论,大致有以下几种分法:

1、前/中端:综合+DFT+ timing signoff;后端:PnR+ other signoff + DFM.

2、前/中端:综合+DFT;后端:PnR+ signoff+ DFM.

3、前/中端:综合;后端:PnR;DFT、signoff、DFM 分别独立成组。

分工无优劣,更多的是取决于公司的“产品形态”跟“传统习惯”,但可见的是公司规模越大分工越细,分工越细对公司而言效率会越高,但对工程师越不“友好”越“浪费”,因为它局限,是真正地把铁杵变成针,原本可以横杵立键盘一人干出半颗芯片,被局限了之后只会针尖戳鸡眼就瞅中那一点!工程的东西又不是高深艰的科学,一辈子钻一个点就够了,吾辈当奋强,别自我局限!当然,不是所有人都喜欢做杵都适合做杵,世上的事就是这样,不是大好不是小好,是不大不小持久才好。

333.jpg

再说回综合,一个综合工程师的自我修养,大致需要修炼:

1、要去分析所用的库;

2、要懂RTL ,要去看datapath 要去分析时钟结构,要去看以软件思维写得很恶心的RTL 如何改才能对工具友好;

3、要懂sdc,知道每一条命令的定义方式跟作用域;

4、要懂power domain,要会写1801,要会debug 为什么插不上为什么插错,什么地方该插什么地方不该插;

5、要懂physical, lef 跟qrc 都用来表征什么,def 里有什么,分别是做什么用的,哪些是多的,少了哪些?如何调整macro 如何确定datapath 跟macro的位置关系,是否需要blockage 是否需要region,怎么加,row  是什么track 是什么,congestion map 怎么分析等等;

6、再就是输出部分,对产生的任何一个report,都要有分析的能力,要知道问题是什么?可能是什么原因造成的?有什么办法可以尝试去解决。

7、要对timing 跟 power的计算十分熟悉,要对congestion 的计算熟悉,要对怎么调整设计怎么调整工具参数十分熟悉。

8、再就是工具端,当前世面上的综合工具都是通用工具,要根据当前设计的特点跟目标去调整相应的变量或命令,以最大限度地榨取工具。

9、还要懂一些dft,可以不懂它怎么生成,但要知道怎么插入。

10、还要保证形式验证没问题,还要保证CLP clean. 还要满足后端大爷的各种需求。

4.jpg

综合被如何分工取决于:工具的能力跟现有工程师的技能。理想状态当然是RTL 进GDS 出一波人搞定,但就目前状况而言还远远无法达到理想状态,其原因大致可概括为:

1、工具端无法支撑,近几年虽然工具被工艺逼得有了长足进步,但依旧无法脱离开人的不断干预从头走到尾,除非一些极简单设计。要脱离人还是要依靠AI,当人工智能可以完全替代人之后,当某一家工具从前到后都称得上最优秀之后,工具端才足以支撑RTL 进GDS 出;如果到了那一天,其实也不用从RTL 开始也不用从C++/system C 开始,直接上spec.

2、工程师技能不足于支撑,毫不夸张地讲,目前地球上活着的前后端通吃的人绝对不过百,技术达到这一境界的人也大多“逃离”了一线,到背后做军师运筹帷幄。前后端看似相近,其实有一堵巨高无比的墙,还没有窄门,老驴最近努力尝试了解一些后端基本知识,眼前是茫茫一片海后端东西太繁杂,思维方式也不一样,从逻辑到物理绝对比从姑娘到媳妇的跨度大。

3、数字实现过程并不是线性串行的,尤其对于先进工艺节点,许多阶段几乎都是并行开始的,这也许是越大的公司切分越细的原因之一吧,各项任务并行执行,可以大大缩短研发周期。

分工,在公司立场当然是效率为先,但在个人立场,“任何公司”都不会像蚁群蜂窝是“终生社群”,所以没必要做工蜂工蚁,除了公司的效率之外要更多地考虑自身的成长跟发展——这也是一个重要的TradeOff!

555.jpg

综合,方法学

综合,在方法学上有哪些值得讨论的点?这是个值得思考的问题,老驴此处抛个砖,有兴趣的可以一起讨论。

1、设计空间探索:借助工具分析设计特性,以确定什么样的coding style 对工具更友好;以确定不同目标不同应用场景的设计如何差别对待以更多获得更看重的好处;以去芜存菁缩减成本……

2、工艺空间探索:分析库,传统工艺库中每种cell 都有不同size 不同VT,对于某一特定设计是否存在一个库的子集,在这个子集中可以得到更好的PPA 和TAT;分析设计,对于某一特定设计是否有某一逻辑pattern 多次出现,是否可抽取出对应的逻辑pattern 定制成特殊的复杂cell 以获得更多的PPA 收益?是否可以偷margin?

3、流程探索:是否所有设计都有必要做physical aware synthesis? 是否对所有设计physical aware synthesis 都要比其它优化策略得到的PPA 更好?如何将early clock flow、early floorplan、mix place、feedthrough 等这些新的后端技术切到综合中?每一种技术的应用场景跟带来收益各是什么?如何处理低功耗设计?对leakage, dynamic power, glitch power 各有什么手段?优化策略是激进还是保守?

666.jpg

天地不仁以万物为刍狗,圣人不仁以百姓为刍狗。海纳百川,有容乃大!张开自己,接受一切。

作者:陌上风骑驴
原文链接:https://mp.weixin.qq.com/s/0tntgx5K\_UjTU3rYxbr\_EA
微信公众号:
陌上风.jpg

相关文章推荐

更多IC设计技术干货请关注IC设计技术专栏。
推荐阅读
关注数
19303
内容数
1296
主要交流IC以及SoC设计流程相关的技术和知识
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息