继续码综合这一趴,可先回顾:《综合 | 概述及 library 检查》跟《综合 | LEF, QRC, DEF》。在读入lib, lef, qrc 之后下一步要读入的就是设计,设计可能是:Verilog, VHDL, SystemVerilog几种硬件描述语言的一种或多种的混杂。
驴说IC
通常,Elaborate 会做如下事情,如果需要在TOP 传递参数,也需要在这步完成。
- Builds data structures and infers registers in the design.
- Performs high-level HDL optimization, such as dead code removal.
- Identifies clock gating candidates.
- RTL除了算法架构的考虑,还要考虑最后的实现,才是好的RTL。
- 对中后端友好,PPA好的,具体来说就是,formal 容易过,对后端flow要友好,pr 实现相对简单。
- 别人看的时候没有一句一句的WTF, 但RTL 有时候可能走向两个极端,太好的RTL你也会WTF, 如:充分利用可综合语言特性及辅助综合指令,极致精简的实现,太差的是满屏ctrl c+v 的痕迹,同样会WTF.
- 最恶心的代码就是用软件思维来写。
- 对于代码的理解不透彻所有程序都强套几个编程范式的永远不是好程序员。
- 真正有硬件思维,适合写RTL的人不多,很多人写了挺多年,基本也只会加减乘除——最难的是硬件思维。
- 写rtl不光要有硬件思维,还需要思维缜密,才能经得起验证。基本功能正常,bug太多验证很难收敛。
- 一般工艺或者库变化后,我都会对比看看,主要逻辑单元的时序怎么样,写的时候有数,不该省的不要省,后期要少很多事情。
- HLS 如果想写出很高质量的代码,还需要加速pragam, 感觉也是硬件思维,还不够灵活,HLS 更合适软件或者CS.
- 通常面试一个刚毕业的,你问他『你觉得设计环节什么最重要』八九不离十的答案都是『写好codes(无论是rtl, perl.)』。
- 『可以给architecture 足够的support 能够参与讨论;可以写很好的spec, 在spec 阶段基本把design 构思完成,并有很大一部分已经具体细化; 能够很好的和VE 沟通cover corner case 』,在这种广义定义下,写代码才算比较有竞争力。
- 一个能兼顾硬件实现的算法 ,可以带来一个顺畅的rtl design, 遇到一个算法。
- RTL 设计主要还是经验,大概能预测之后可能的问题。如:sram 的工艺不一样,接口输入和输出的时延模型定义不一样,导致之前的设计,时序就变得很紧张。总之,rtl如果能多考虑以后的时序问题,以后就会少麻烦,改流水线容易,改loop难。
- 先搭电路架构,再去用verilog 表达。
- 两个人写cache, 一个连最长路径多少门都想到了,一个人就是实现功能,结果出来真的是差好多。
- 做架构就是这样的,眼睛里看的是matlab 的C, 脑子里想的全是流水线,加法器,乘法器,并行度,然后才能输出一份指令集。
- 很久以前,我遇到一个老工程师,写verilog 是把所有信号都写成表达式。他写的是usb 控制器,我就是从那个代码里面领悟到了:写RTL 真的必须用心感受所有信号传递路径,因为硬件所有信号都是并行传递的。
- 硬件,任何器件,都是同时工作,多了一维。
- 大神写的代码,要是不加注释,你都看不懂是啥意思,ppa好,但是可读性真的...
- 我第一家公司的技术总监写RTL 都用宏拼,有个验证说这里不对,他画了个图说我的行为应该是这样的,那个验证一看:我去真是我理解的不对!近年应该有60 了,写了好几十年的RTL, 看着像火星文很短实现的功能又极其复杂。
- 太好的代码也会被吐槽,人家压根写的不是代码,是电路。
驴说IC