继续码综合这一趴，可先回顾：《综合 | 概述及 library 检查》跟《综合 |LEF\,QRC\,DEF》。在读入lib, lef, qrc 之后下一步要读入的就是设计，设计可能是：Verilog, VHDL, SystemVerilog几种硬件描述语言的一种或多种的混杂。
综合工具都支持读入单个文件或读入一个文件列表，综合工具在读入RTL 时，会做对应的语法检查，并报出Warning 或 Error 等信息，综合工程师需要对每一类Warning 跟Error 做进一步确认，工具默认在读RTL 时如果遇到错误会停下来，如果是初次进综合工具，可以设变量让工具一气儿读完，把该报的错都报出来，找Designer 去确认修正。对于可忽略的Warning 可以不管，如果不想让工具报这些可忽略的Warning 有对应的命令将其设掉，但是非常不建议，可以限制一下这类Warning 的个数，但不要全设掉；对于不能忽略的Warning, 则需要一个一个的去看，最好让设计修掉。
在设计正确读入之后，需要对设计做elaborate, elaborate 就是综合三大步中的 "translation", 它将设计从Verilog, SV, VHDL 描述转换成GTECH 描述，GETCH 是独立于工艺的『基本逻辑门』描述，每家都有自己一套独立的GTECH 描述，相互之间不通用。在做elaborate 时，工具同样会报许多Warning 或Error, 综合工程师同样要检查每一项，而且十分建议把大部分Info 也过一下，可以从Info 给出的信息得知RTL 中的结构被映射成了什么。
通常，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.
在同步设计中，有三类错一定要加倍小心：Latch, Loop, unresolve, 这三货除非是设计意图，否则一定要修掉，关于Loop 可回顾《点论 | 组合逻辑环 Combinational loop 知多少》。
通常，做完elaborate 之后都需要做一步uniquify, 对多次例化的module 做『克隆』, 工具在优化时，会根据每个例化的『外部环境』对『克隆体』进行优化，避免了相互牵扯，以充分享受『环境红利』。
做完uniquify 之后，一定要做check\_design, check\_design 会报出许多Warning, 综合工程师要对每一类Warning 知根知底，且对有害之处做修正。
如果read\_hdl, elaborate, check\_design 的结果都水清木明，都胸中有数，那恭喜你又进了一步。但每当提及设计，尤其是在综合端，就不得不提及Coding sytle, 就不得不质问『什么样的RTL 算是好的RTL？』。
综合工具它不能吃铁丝拉笊篱，能做出什么样的结构极大程度取决于代码质量，Coding Sytle 并非老生常谈，近些年随着EDA 技术的发展，如何Coding 对工具更友好能更好地利用工具的能力已经发生了许多变化，关于这趴话题，一两句说不清以后有机会码一文。
关于『什么样的RTL 算是好的RTL』，在IC 圆桌派群里大家聊过许多，高老师也做了总结，搬运一些到这里，仅供参考：
- 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, 看着像火星文很短实现的功能又极其复杂。
- 太好的代码也会被吐槽，人家压根写的不是代码，是电路。
作者：陌上风骑驴
原文链接：https://mp.weixin.qq.com/s/XTsk6e3f-OWAwnp1hSV3pg
微信公众号：
相关文章推荐
更多IC设计技术干货请关注IC设计技术专栏。
