企业官网建设流程全解析

1. 从“仿真能过”到“综合能收”：AI生成RTL的真正短板

先讲个我自己的经历。大半年前我沉迷于让大模型帮我写RTL，那会儿朋友圈里晒的都是“AI一分钟写出UART”“ChatGPT生成流水线CPU”，看起来一片繁荣。我也跟着试，让模型写了一个带优先级仲裁的队列管理模块，仿真确实一把过，功能波形挑不出毛病。我当时还挺高兴，想着这下前端效率要翻倍了。

结果等我把这段代码丢到OpenROAD里做综合，麻烦就来了。时序报告一拉出来，WNS负了0.23纳秒，关键路径长得离谱。更尴尬的是，我说给模型听“这段代码综合出来时序违例了”，它根本不知道我在说什么。它只见过RTL文本，没见过RTL被综合器翻译成门级网表之后的样子。

这就是我想聊的“PPA-RTL”概念的起点：如果大模型写RTL只关心语法正确、功能正确，却不关心这段代码综合出来之后功耗、性能、面积到底怎么样，那它本质上还是在“纸上谈兵”。

1.1 为什么功能正确的代码会在物理设计阶段“翻车”

很多做软件出身的朋友不太理解这一点：芯片设计的验收标准不是“仿真过了”就行，而是“综合能收”。所谓综合，是把Verilog/VHDL这种行为级描述，映射到特定工艺库下的门级网表，再经过布局布线，才算真正接近物理实现。这个过程中，代码的写法对结果的影响极其巨大。

举个例子：同样是实现“四输入优先级仲裁”，有人写成串行的if-else嵌套，有人写成并行的优先级树。两者功能完全等价，仿真波形一模一样，但综合出来的关键路径延迟可能差出20%到30%。前端RTL工程师如果只盯着仿真看，永远发现不了这类问题；只有把综合报告拉出来，看到WNS、TNS、逻辑级数，才知道自己写的代码到底行不行。

更要命的是，大模型生成RTL时，脑子里并没有“物理实现”这个概念。它从海量代码片段里学习到的规律，大多是“功能怎么写才对”，而不是“结构怎么排才优”。于是AI生成的RTL经常出现一种通病：代码style很规范，注释很齐全，仿真也很干净，但一综合就露出原形——要么组合逻辑链太长，要么高扇出信号满天飞，要么到处是 latch。

1.2 PPA三件套：频率、面积、功耗到底在反馈什么信息

既然要让模型“关心”综合结果，首先得把PPA这三个字母拆开看清楚。

• P（Performance）：主要指最高工作频率，落实到报告里就是WNS（最差负裕量）和TNS（总负裕量）。WNS是全局最差的那条路径的时序裕量，它决定了芯片能不能跑到目标频率；TNS则是所有违例路径的裕量之和，反映整体的时序健康程度。我在项目中看WNS看的最多，因为它是一个项目能不能按时收敛的“体温计”。
• P（Power）：功耗分为动态功耗和泄漏功耗。动态功耗跟翻转率、负载电容、供电电压相关；泄漏功耗跟工艺节点、单元阈值电压相关。低功耗设计在移动端和AI推理芯片里是硬指标，大模型如果不知道怎么通过RTL结构调整数据通路来降功耗，生成的代码很难直接商用。
• A（Area）：面积直接决定成本。同样的功能，组合逻辑打散了重写、状态机编码方式换了，面积可能差一大截。对FPGA来说，对应的是LUT、FF、DSP、BRAM的用量；对ASIC来说，就是标准单元总面积和利用率。

这三个指标之间还存在典型的跷跷板关系。插入流水线寄存器能提频率，但会增大面积和功耗；把组合逻辑做并行化能提频率，但会增加资源占用；采用低阈值电压单元能提时序，但泄漏功耗会上升。所谓的“PPA优化”，本质上就是在这三个维度之间反复博弈，找一个满足约束的平衡点。

1.3 PPA-RTL想做的事：把综合报告变成模型的“眼睛”

我理解的“PPA-RTL”，不是一个具体的工具，也不一定是一个新语言，而是一种工作范式的转变：让大模型在生成RTL之后，能“看见”这段RTL综合出来的真实结果，并根据结果进行迭代修改。

这意味着两件事。第一，要在RTL生成流程里接入综合工具，跑出真实数据；第二，要把综合报告里的海量信息，压缩成模型可以理解、可以行动的上下文。前者属于流程搭建，后者属于提示词工程和数据结构设计，两者缺一不可。

现在的公开大模型，大多做过代码生成训练，写RTL的正确率已经不错了。但它们缺乏“感知下游物理实现”的能力。你问它“这段代码综合出来频率多少”，它只能根据经验猜一个大概，没法真正知道。而PPA-RTL的思路，是把这个缺失的环节用工程手段补上——把综合报告喂回去，让模型看到自己写的代码在工艺库映射下到底长什么样。

我做了三轮迭代实验之后，最大的感受是：模型一旦能“看到”WNS和逻辑级数，它给出的优化建议，跟盲猜完全是两个水平。下面两章我把完整的方法和实测过程展开讲。

2. 搭建PPA反馈回路：从综合报告到模型可读的优化提示

要让大模型关心PPA，核心工程问题是：综合工具输出的报告，和模型能消费的文本上下文，中间的翻译层怎么做。

直接拿整份综合报告喂给模型是行不通的。一份稍微复杂点的设计，report_checks跑出来可能有几百条路径，加上面积报告、功耗报告，动辄几十KB的文本，既超出上下文窗口，里面还充斥着大量模型不需要看的中间细节。你需要的是先提炼，再结构化，最后转换成优化提示。

2.1 一个可复现的基线环境：OpenROAD加标准单元库

我实验用的基线环境是开源的OpenROAD流程，配合一组开放的标准单元库，比如Nangate45或者SkyWater 130nm。这套流程的好处是完全可以脚本化，适合做自动化迭代。

先准备一个综合脚本，核心步骤大致是这样：

# run_flow.tcl 片段 set ::env(CLOCK_PERIOD) 2.0 read_verilog rtl/arbiter_ppar.v read_liberty -lib Nangate45.lib read_sdc constraints/arbiter_ppar.sdc link_design arbiter_ppar synth -top arbiter_ppar -generic report_checks -path_delay max -digits 4 -format end > reports/timing.rpt report_area -digits 4 > reports/area.rpt report_power -digits 4 > reports/power.rpt

注意几个细节：读入的库和SDC约束，必须跟真实设计目标一致，不能随便拍脑袋写一个。CLOCK_PERIOD设成2.0ns，对应500MHz，这是我这次实验的目标频率；如果实际场景是低频低功耗，约束就完全不同。

跑完综合后，OpenROAD会在reports目录下生成三份文本报告。我的做法是写一个小的解析脚本，把关键数据抽出来，拼成一段结构化的“PPA摘要”。

2.2 报告解析：从WNS、面积、功耗文本中提取关键事实

OpenROAD的时序报告格式大致长这样，我截取关键几行：

Startpoint: req_masked[0] (input port clocked by clk) Endpoint: grant_int[1] (internal endpoint) Path Group: clk Path Type: max Delay Time Description --------------------------------------------------------- 0.0000 0.0000 clock clk (rise edge) 0.0000 0.0000 clock network delay (ideal) 0.0000 0.0000 input external delay 0.1644 0.1644 input slew ... 0.0988 5.0428 data path 0.1240 5.2300 clock uncertainty -0.2300 0.0000 slack (VIOLATED)

解析脚本不需要很复杂，把WNS、TNS、单元面积、总功耗这几个字段抽出来就够了。用Python写个几十行的脚本最顺手：

import re def extract_timing(path): wns = tns = None with open(path) as f: for line in f: m = re.search(r"wns\s+([-\d.]+)", line) if m: wns = float(m.group(1)) m = re.search(r"tns\s+([-\d.]+)", line) if m: tns = float(m.group(1)) return wns, tns

当然不同工具输出格式不一样，Vivado的report_timing_summary、Design Compiler的report_qor、OpenROAD的report_checks，格式各有差异。解析逻辑也要跟着变。但它们的共同点都是：最终落到几个数字上。我们要的就是这几个数字，以及违例路径里最集中的逻辑级数分布。

抽完数据之后，我习惯拼成下面这段摘要，作为喂给模型的上下文：

PPA 摘要 for arbiter_ppar (Nangate45, 500MHz约束): - WNS: -0.230ns (最差路径违例230ps) - TNS: -3.710ns (共12条违例路径) - 关键路径逻辑级数: 32级 - 面积: 8425 um^2 (单元数 31247) - 总功耗: 43.2mW (动态 38.9mW, 泄漏 4.3mW) - 高扇出信号: grant_int[1] 扇出 256

这段摘要信息量其实已经很大了。逻辑级数32级，说明组合逻辑链太长；高扇出信号256，说明某个内部信号驱动的负载过重。模型拿到这些事实，才有“诊断”的依据。

2.3 反馈提示模板：不让模型“瞎猜”，只让它做“结构分析”

光有摘要还不够，得设计提示词的结构。我的做法是给模型一个明确的角色和工作范式，限制它不要乱改接口，也不要一上来就输出完整代码，而是先给“结构诊断”再给“修改建议”。

以下是我实验里实际用过的提示模板，分享出来供参考：

你是一位熟悉数字电路物理设计的RTL优化工程师。 下面是某个模块综合后的PPA摘要： {PPA摘要} 请按下面的步骤输出： 1. 用两三句话概括当前的主要性能瓶颈，指出最可能导致时序违例的结构问题。 2. 给出最多三条具体的RTL修改建议。每一条必须包含： - 修改位置（哪个模块/哪个信号） - 为什么这样改能改善PPA（比如缩短组合逻辑链、降低扇出） - 预期收益 - 可能的副作用（比如面积增加、功耗上升、流水延迟变化） 3. 不要改变模块端口列表和对外接口协议。 4. 如果当前问题靠RTL层面无法解决，请明确说“需要工具层面/后端介入”，不要硬给方案。

这个模板看起来简单，但作用很明显。它把模型从“自由发挥写代码”拉回到了“有依据地做工程分析”的轨道上。模型看到WNS是负的，就会主动去猜关键路径在哪个模块；看到高扇出信号，就会想到打散复制寄存器。这比直接问“帮我优化这段RTL”要有效得多。

3. 三轮实测复盘：仲裁器从WNS=-0.23ns到满足设计约束

理论讲完，必须上实测。我选了一个很小的设计来做PPA-RTL实验，模块是一个四输入负载均衡仲裁器，大概一百行Verilog。选它的原因很简单：结构不复杂，但组合逻辑链和高扇出问题很典型，非常适合验证反馈回路是否有效。

3.1 初始设计：功能没问题，时序一言难尽

初始版本我用大模型直接生成，代码能跑，优先级轮询功能正常。核心逻辑的核心问题在于，我用了一层嵌套的if-else来做轮询优先级选择，结构大概长这样：

// 轮询优先级选择逻辑，简化的意图展示 always @(*) begin if (masked_req[0]) begin grant_candidate = 2'd0; end else if (masked_req[1]) begin grant_candidate = 2'd1; end else if (masked_req[2]) begin grant_candidate = 2'd2; end else if (masked_req[3]) begin grant_candidate = 2'd3; end else begin grant_candidate = 2'd0; end end

把这段代码综合之后，第一轮报告的表格如下：

WNS负到230ps，按2ns的时钟周期来看，这意味着关键路径实际需要2.23ns才能稳定，目标频率500MHz完全跑不到。我把这份报告摘要丢给大模型，它给出的第一轮诊断是：嵌套if-else生成了串行比较链，建议改成树形比较结构，同时把grant信号的最终输出用寄存器寄存一拍，打破组合环路。这个建议方向是对的，但执行起来需要想清楚代价。

3.2 第一轮：拆长组合链，WNS涨了但是面积也涨了

按照模型的建议，我做了两部分修改。一是把if-else的优先级比较改成逐级比较的树形结构，让关键路径深度从O(N)降到O(logN)；二是在grant输出之前加了一级寄存器，把组合逻辑的尾巴截断。

改完RTL再跑综合，结果如下：

WNS从-0.23涨到了-0.08，逻辑级数从32降到18，说明拆链有效果。但注意，面积和功耗都涨了，因为树形结构需要更多并行逻辑，而且新增寄存器也带来了面积开销。这验证了我前面说的跷跷板关系：性能改善，代价是面积和功耗上升。

不过WNS仍然是负的，意味着一轮优化还不足以让设计收敛到500MHz。这时候如果继续盲目加流水线，可能会导致吞吐率变化，甚至引入功能正确性问题。我把第二轮报告再喂给模型，让它继续诊断。

3.3 第二轮：并行优先级树才是真正的转折点

第二轮反馈中，模型指出了一个新的关键问题：关键路径并不全在仲裁逻辑本身，还有一部分在“轮询指针更新”和“请求mask生成”的路径上。原来的设计里，轮询指针更新逻辑跟请求mask逻辑串在一起，导致下个周期的grant输出必须要等当前周期的grant结果算出来，形成了一条很长的“跨周期组合链”。

模型的建议是：把轮询指针的更新逻辑单独拆开，用一组独立的寄存器提前计算下一轮指针，并将grant选通逻辑改为低扇出的并行查找结构。

我照着改了。核心变化是引入了预先计算好的一组候选grant值，而不是等请求mask稳定后现场算。相当于用面积换时序，把“计算”提前了。第二轮结果：

到这轮结束，WNS转正，所有路径都满足时序约束，设计跑到了目标频率500MHz。代价是面积比初始版本增加了17%，功耗增加了16%。在某些低功耗项目里，这个代价可能不可接受；但在这个实验的目标是“时序收敛优先”，所以结果可接受。

这轮迭代给我最大的启发是：模型在看到了第二轮WNS从-0.08只涨到-0.08之后，并没有继续建议“拆链”，而是转到了“跨周期结构”这个更深层的诊断。这就是PPA反馈回路的价值——模型不再盲目优化，而是根据真实数据判断瓶颈在哪。

3.4 第三轮：AI“卷”出来的激进改动，怎么甄别和拒绝

有意思的是第三轮。在WNS已经转正之后，我又故意问了一遍“还能不能继续优化面积”，模型给出的方案是：把轮询指针的并行查找表改成共享时序单元，并把grant信号从8bit压缩到4bit编码再解码。它甚至说“可以节省大约600um²的面积”。

我实际试了一下，面积确实降了一些，但代价是组合逻辑又变深了，WNS重新回到了-0.03ns。也就是说，这个建议在面积和时序之间偷偷做了一个不利于时序的权衡。换做是人工工程师，大概率会直接否决这个方案，因为当前设计的时序余量只有50ps，非常脆弱，为了省600um²的面积把时序推向悬崖，风险太大。

这个例子说明一件事：大模型给的优化建议，不能全盘照收。它会在你不知道的时候给你挖坑。我现在的处理方式是，收到模型建议之后，先让它在建议里标注“风险等级”，并强制要求它列出“如果改坏，对WNS的估计影响值”。然后我再结合当前项目的PPA预算来做判断。

第三轮我们没有继续采纳激进改动，最终保留第二轮的结果作为收敛版本。整个迭代过程的经验，我浓缩成一张表：

4. PPA-RTL能走多远：落地形态与评测方法的一些思考

实验做到这一步，我开始认真思考一个问题：这个框架能不能真正落到工程流程里，甚至成为评价“大模型懂不懂硬件”的一种新方法？

4.1 预期定位：不是替代工程师，而是给芯片团队配一个“PPA顾问”

我个人的判断是，短期内PPA-RTL不应该是全自动的RTL生成器，而是一个“PPA顾问”角色。它先把综合报告变成简明摘要，再给出结构层面的优化方向，最后仍然由人来把控关键取舍。

这样做的好处是，它能大幅压缩工程师在“仿真—综合—看报告—改代码”这个循环里花的时间。以前我排查一条关键路径可能要半天，先把report里的路径展开看，再去RTL里定位，再改再综合再验证。现在这个循环里很大一部分“从报告到结构诊断”的工作，模型可以直接做掉，剩下的人工干预集中在对设计意图的把握上。

我在实际使用中的体会是：模型给出的建议，至少有七成是靠谱的，但最后的三成往往需要人工修正。它擅长识别“组合链太长”“扇出太高”这类模式化问题，但在涉及特殊设计约束、工艺库特性、跨模块时序预算的时候，还是需要人来做最终判断。所以定位成“顾问”而不是“替代者”，是现阶段最务实的路径。

4.2 工程化挑战：工具链闭环、约束一致性和回归成本

如果把PPA-RTL真正集成到流程里，会面对几个很现实的工程问题。

一个是工具链闭环。模型的上下文里必须包含真实综合结果，那么这个综合流程就得能在一个可控的、分钟级的时间内跑完。大设计综合一次可能要跑几小时，根本没法做在线迭代。目前的解决办法是把综合拆成“模块级综合”和“顶层集成综合”，PPA反馈回路只在模块级生效，顶层仍然靠人工把控。

另一个是约束一致性。如果SDC约束跟实际工作条件不一致，那综合报告里的WNS、功耗数字本身就没有意义，模型根据错误数据给出的优化建议当然也会跑偏。所以每次实验前，必须确认工艺库、时钟频率、输入延迟、输出负载这些信息都已经正确写入约束文件。

回归成本也是一个躲不开的话题。每次模型改完RTL，不能只看WNS一个数字，还需要做功能仿真回归，防止优化过程引入行为偏差。在我的实验流程里，每轮修改之后都会跑一遍完整的仿真用例集，确保仲裁结果、输出协议没有变化。这一步虽然费时间，但它才是“优化”和“破坏”之间的安全网。

4.3 怎么评测一个大模型是否“真的关心PPA”

最后我想聊一个更发散但很有意思的问题：怎么评测一个大模型懂不懂PPA。

目前公开的大模型榜单基本都在刷代码生成准确率、推理能力这些通用指标，几乎没有人关注“模型生成的RTL综合出来PPA表现如何”。这其实是一个被严重忽视的评测维度。我的建议是，可以设计一组“等效功能、不同结构”的RTL生成任务，让模型在不同的PPA约束条件下生成代码，再统一跑综合，看它能否根据约束动态调整自己的生成偏好。

举例来说，给模型同一个功能需求，分别附加“优先低功耗”“优先高频”“优先小面积”三条不同的约束，然后看三条输出代码在综合后的PPA差异是否明显。如果模型输出的代码在三组约束下几乎没有区别，那说明它对PPA只是嘴上关心，没有真正转化为代码结构上的选择。反过来，如果它能针对低功耗约束主动选用门控时钟、操作数隔离这类技术，针对高频约束主动插入流水线，那才算有了“PPA意识”。

这种评测方式比单纯问“你知道什么是WNS吗”要硬核得多，因为它是从结果倒推能力。我觉得未来如果出现“RTL综合评测榜单”，这里面的空间非常大。对做AI芯片工具链的团队来说，这甚至可能成为大模型选型时的重要参考维度。

我在实验结束之后，把整套PPA-RTL的反馈回路固化成了一个小脚本。现在每天生成新的RTL模块时，不再只跑仿真就收工，而是顺手跑一次综合，把PPA摘要打印出来。这个习惯看着简单，但对设计质量的提升是实打实的。如果你也在用大模型写RTL，不妨也搭一个这样的闭环，让模型真正看见自己写出来的代码综合出来是什么样。