PD工程师为什么必须读懂RTL：后端的痛，大多从RTL开始

30秒摘要

• 物理设计的痛苦，大多从RTL开始。布线做得再好，也救不了坏掉的微架构。
• 逻辑综合与P&R工具是优化器，不是魔法师。巨大的多路选择器、过深的组合逻辑链、错误的时钟门控，是工具修不好的结构性问题。
• PD工程师不需要会「设计」RTL，但必须读得懂、闻得出味道、能跟前端工程师据理力争。
• 最低要求：读懂always_ff／always_comb、blocking vs non-blocking、case／generate、辨识推断出的锁存器、对扇出与多路选择器深度的直觉。
• 晚期RTL变更的成本，随着阶段往后呈指数级飙升。在掩模组动辄数百万到数千万美元的时代，「因为不懂RTL」造成的ECO，全是罪过。
• Chase的结论：从前端到后端都要摸过。从RTL开始，经过验证、综合／PD、STA／签核。只钻PD，天花板很低。

前言：不懂RTL的后端工程师会遇到什么事

物理设计（PD）工程师之间有个老笑话：「RTL是前端那些人的问题，我们只要拿到网表就好。」相信这句话、只看网表过活的工程师，最后面对的会是：熬夜的拥塞调试、解释不清的时序违例，以及流片前一周飞来的RTL ECO。

我现在在Synopsys担任PrimeTime（STA／签核工具）的Product Engineer，坐在流程的最末端——也就是芯片成形前一刻的时序。而在SiFive Korea（现SEMIFIVE），我以RTL-to-GDS全权负责的方式，做过Samsung 5nm到14nm共5次以上的流片。以走过流程两端的立场，我可以断言：读不懂RTL的PD工程师，就像没带地图开车。目的地（网表）看得见，但不知道路为什么塞、该从哪里绕。

这篇文章不是说教。先给你看4个真实发生过的战争故事，再整理PD工程师真正需要的最低限度RTL知识。不是叫你当设计师。读得懂、认得出危险模式、能用同一种语言跟前端工程师对话，就够了。

Episode 1. 巨大多路选择器造成的拥塞地狱

有个项目里，一个crossbar吃掉了整个模块的布线。打开RTL一看，是这样的代码。

// Combinational, unregistered crossbar — no pipeline register
assign data_out = (sel == 3'd0) ? data_in0 :
                  (sel == 3'd1) ? data_in1 :
                  (sel == 3'd2) ? data_in2 :
                  (sel == 3'd3) ? data_in3 :
                  (sel == 3'd4) ? data_in4 :
                  (sel == 3'd5) ? data_in5 :
                  (sel == 3'd6) ? data_in6 :
                  (sel == 3'd7) ? data_in7 : 32'd0;

完全合法的RTL，仿真也过了。但逻辑综合把它展开成数千个门，洒满整颗芯片。8组32位元输入全部汇聚到一点——从布局的角度，所有输入汇流排都得拉到同一个点，结果就是布线拥塞热点。业界确实有记载：一个4,000-to-1的多路选择器制造了「routing and timing nightmare」。合法的RTL，制造合法的灾难。

读得懂RTL的PD工程师，不会等到网表阶段，而是在RTL交接审查阶段就抓到它。「这个crossbar为什么是unregistered？加一级流水线，拥塞就能少一半」——这一句话，把三周的P&R叠代缩成三天。

Episode 2. 综合修不好的时序——问题在微架构

拿到STA报告的PD工程师日常：slack -320ps的setup违例数百条。塞buffer、放大门、跑retiming都没用。因为问题在结构里。

典型模式是这样：一个时钟周期里塞了128级的组合逻辑。宽多路选择器后面接进位链，再加上高扇出网络。综合优化卡在局部极小值里。Buffer insertion、gate resizing、retiming都没用——数学上，那个时钟里根本塞不下这么多逻辑。

这时候需要的不是工具设定，而是微架构变更：多加一级流水线，或把多路选择器拆开，或把资料路径重画。但PD工程师如果读不懂RTL，连这个判断都做不出来。得跟前端团队说「这是结构问题，请改RTL」，却因为读不懂RTL而拿不出证据。结果就是花几周只调工具选项，最后看着RTL团队加一级流水线、一小时解决。

以做PrimeTime的人补充一句：签核阶段看到最棘手的违例，大多不是「工具再努力一点就解得掉」的问题，而是「RTL阶段就该挡掉」的问题。STA工具只会说出真相，不会改变真相。

Episode 3. 晚期RTL变更与ECO地狱的经济学

芯片开发里，修bug的成本越到后面越呈指数级飙升。在RTL阶段改一行、跟P&R做完再用ECO改、跟重做掩模，是不同次元的成本。

看看公开的估计就有概念：90nm时代的掩模组约100万美元，65nm约150万美元，到了5nm以下，一组掩模轻松超过1,000万美元。流片前一周RTL变更进来，选择只有两个：靠金属层ECO硬撑，或吞下全重新流片。两个都贵，两个都让时程爆炸。

这里，PD工程师的RTL阅读能力直接等于钱。做ECO时，必须判断变更后的RTL是不是真的需要那么大的改动。有时前端下来的ECO RTL，功能一样，只是写法变了。读不懂RTL，就会变成「有改就全部重跑」；读得懂，就能判断「功能等效，用spare cell就能吸收」。这一行的判断，决定数百万美元和订单的去留。

Episode 4. 时钟门控动错一根线，生出电源网格恶梦

RTL层级的时钟门控失误，是PD阶段最难找的bug之一。例如手刻的门控时钟：

// DANGEROUS: hand-rolled 时钟门控 — glitch risk
assign gclk = clk & en;

一旦产生毛刺，拿来当时钟的网络上会出现非预期的边缘，下游的触发器跟着误动作。原本指望综合换成集成时钟门控单元，但写法不同，工具可能认不出来。于是PD阶段时钟树综合得乱七八糟，CTS做到崩溃，动态功耗乱跳，IR压降分析冒出莫名其妙的热点。

读得懂RTL的PD工程师，看到时钟结构立刻会问：「这个使能信号是glitch-free的吗？综合有认成ICG吗？时钟门控检查在STA有覆盖到吗？」差别就在于，这个问题是在P&R之前问，还是留到在硅片上调试。

PD工程师真正需要的最低限度RTL

再强调一次：不是叫你会设计。读得懂、感觉得出风险、能对话，就够了。范围如下。

1. 要读得懂的语法（Verilog／SystemVerilog）

• always_ff／always_comb／assign——循序与组合的区分，就是时序结构的区分。
• Blocking（=）vs non-blocking（<=）——仿真与综合不一致的经典原因。审查别人RTL时第一个看的东西。
• if-else／case——优先编码器 vs 平行多路选择器。case里没有default就会推断出锁存器。
• generate／parameter——参数化的模组实际会展开成几个instance，凭直觉要知道，否则估不出面积／拥塞。
• interface／modport（SystemVerilog）——现在的RTL动不动就是几百个port的模组用interface包起来。读不懂就追不了阶层。
• 复位风格——同步 vs 非同步复位、有几个复位域。复位是PD里高扇出网络的元凶。

2. 要认得出的综合不友善模式

• 巨大的unregistered多路选择器／crossbar（Episode 1）
• 过深的组合逻辑链——一个周期里逻辑级数几十级以上，就是微架构问题（Episode 2）
• 手刻时钟门控（clk & en）——ICG认不出来、有毛刺风险（Episode 4）
• 推断出的锁存器——if没有else、或case没有default就会有锁存器。时序分析的黑暗地带。
• 高扇出复位／使能——挂在数万个触发器上的全域网络。直接打击CTS和电源。
• 被推断成触发器的大阵列——该进SRAM的存储器被展开成数千个触发器，面积／拥塞爆炸。要读得懂RTL里的存储器推断。
• 时钟域跨越——没有同步器就跨过去的信号。STA里被误切成伪路径，硅片上就死给你看。

3. 跟前端对话的方法

读得懂RTL之后，对话就变了。从「时序跑不出来啦」变成「这条路径的多路选择器深度有6级，1GHz塞不下。请加一级流水线或把多路选择器拆开」。前者是抱怨，后者是工程。前端工程师也会对后者有反应——因为讲的是同一种语言。

下一步：在edu.vlsi.kr跟着从前端到后端的路线图走

读RTL不是一个人埋头苦练就能学会的，顺序很重要。VLSI Edu的RTL2GDS路线图是把RTL到GDS整个流程整理成职业生涯路径的起点。特别是想走PD的人，建议照RTL → 验证 → 综合 → PD → STA／签核的顺序走一遍。

完整的职业生涯路径地图可以在44条半导体职业生涯路径总览查看。分为Architecture & RTL、Verification、Implementation & Signoff三大类，每个角色都有阶段性技能与学习资源。（注：目前该页面以越南语呈现，韩文（/ko/roadmaps）与英文（/en/roadmaps）页面截至2026-10-11为404／渲染错误状态。网站上应该补上繁中版RTL→PD职业生涯路径详细页与STA／签核进阶教学页。）

Chase's Take

老实说，我也不是一开始就读得懂RTL。在SiFive Korea负责RTL-to-GDS全流程时，前几个月我也只看网表跑P&R。后来在Samsung 5nm项目因为拥塞赔掉三周，原因跟Episode 1一模一样——unregistered crossbar。当时RTL团队的lead走到我座位旁，摊开代码说：「这个加一级流水线就好。」一句话，三周蒸发了。从那天起，我先读RTL。

现在我在Synopsys做PrimeTime，每天看的都是时序违例报告。有趣的是，签核阶段最难修的违例，根因越是在RTL。工具很诚实，只给你数字。改变数字的是人的设计判断，而判断的材料是RTL。

所以我总是跟后辈说同一句话：「整体都要摸过。」从RTL开始，接着验证，再来综合与PD，然后STA与签核。只钻PD，眼前是轻松——会按工具就好。但天花板很低。真正的问题永远在边界上，要跨越边界，就得懂两边的语言。

在PrimeTime最末端工作的我说「从RTL开始学」，听起来可能有点讽刺。但在流程末端待得越久，看开始看得越清楚。所有痛苦的根都在RTL，那就从那里学起。

FAQ

Q1. PD工程师需要会亲手「设计」RTL吗？

不需要。目标是可读性（readability）。读得懂别人写的RTL、从时序／拥塞／功耗角度找出危险结构、能具体地跟前端工程师说明，就够了。亲手设计模组的能力是加分。

Q2. 学RTL要多久？

到「读得懂」的程度，2~3个月就够。Verilog／SystemVerilog基本语法1个月、综合怎么解读RTL（锁存器推断、多路选择器结构、资源共享）1个月、实际项目RTL审查旁听1个月。拿着这篇文章的检查清单进审查会议，进步最快。

Q3. 综合工具变强了，RTL知识不就不需要了吗？

恰恰相反。工具越强，剩下来的就越是工具修不好的结构性问题。AI工具接走例行优化之后，微架构判断这种人类的工作反而更重要。RTL理解是不会折旧的资产。

Q4. STA／签核工程师也需要RTL知识吗？

更需要。STA是「判定」时序的阶段，必须分辨违例的根因在RTL结构还是工具／约束。能读PrimeTime报告并说出「这不是SDC问题，是流水线问题」的STA工程师最值钱。

本文是基于作者实务经验的职业生涯观点文章。特定项目的数值为说明方便已简化。