4.3 逻辑综合与优化

4.3 逻辑综合与优化

RTL 写完只是"描述"，综合把它变成"电路"：工具读入代码与约束，吐出门级网表。这一步的微妙之处在于它是个半自动的谈判过程——工具会优化，但优化方向全由你给的约束决定；约束给错，工具会勤勤恳恳地把你带沟里。读完本节，你应当明白综合的输入输出与内部工序，能写出表达真实意图的时序约束，并看得懂一份质量报告在说什么。

从描述到网表的翻译官

综合的内部工序可以粗分为四步。读入与解释：把 RTL 解释成通用的逻辑表达式。工艺映射：把通用逻辑映射到目标工艺库里具体的标准单元——同样的加法，映射成行波进位还是超前进位，面积与速度天差地别，映射由约束推动。优化迭代：在面积、速度、功耗三个目标间反复腾挪，修剪冗余逻辑、重定时、复制寄存器。输出：门级网表，加上一份详尽的质量报告。记住一个心智模型：综合器是个极其听话、毫无常识的优等生——你约束说这条路要五百兆赫，它就死磕这条路；你没说，它就按默认值办，办完了绝不提醒你默认值合不合理。

正因为听话，约束文件才是综合的灵魂。约束里最重要的三类：时钟定义（每个时钟的频率与波形）、路径例外（哪些路径不按常规时序检查，比如多周期路径与伪路径）、输入输出延迟（芯片边界上信号什么时候到、什么时候必须走）。一份诚实的约束应当与 3.1 节的时钟方案、2.3 节的带宽承诺逐条对应——约束文件本质上是用工具的语言复述架构承诺。

# CK770 计算域的约束节选（TCL 风格示意）
create_clock -name clk_cpu -period 2.000 [get_ports sys_clk]   ;# 计算域五百兆赫
create_clock -name clk_peri -period 10.00 [get_ports peri_clk] ;# 外设域一百兆赫

# 跨时钟域路径：同步器已由设计保证，声明为伪路径，免除工具徒劳优化
set_false_path -from [get_clocks clk_cpu] -to [get_clocks clk_peri]

# 外设寄存器接口是多周期访问，两个周期内到达即可
set_multicycle_path 2 -from [get_pins peri_bus/reg_addr*] -to [get_pins peri_bus/reg_data*]

# 输出延迟：上行接口数据相对发送时钟的窗口
set_output_delay 0.400 -clock clk_peri [get_ports {uplink_data*}]
​

注意注释里那句话的分量：伪路径声明是"免除检查的合同条款"。你声称跨域路径由同步器保护，工具从此不查它——如果设计里那两根线其实没加同步器（4.2 节的纪律被违反），伪路径声明就把真问题藏进了免检通道。5.3 节的排错实录里，这正是事故链条的起点之一。约束权力越大，核对责任越重。

图：综合流程与它的三个谈判回合

读懂质量报告：三张表

综合报告信息量大，工程上盯三张表就够。时序摘要表：每个时钟组的建立与保持余量，正值为过、负值为违例；这里要特别留意"约束路径覆盖率"——没被约束到的路径工具会乐观放行，覆盖率不满九成五的报告先补约束再谈优化。面积表：按模块列出的单元数与面积占比，它是架构成本核算的落地版；某个模块的面积明显偏离 2.2 节存储估算时，通常是存储被综合成了触发器堆（该用存储编译器的写成了寄存器阵列），这类错误在面积表上一眼可见。功耗初估表：按时钟域汇总的动态功耗，是第七章功耗预算的第一次实测对账。

三张表共同指向一个习惯：每次综合后把数字记进台账。CK770 的台账里有完整的综合记录序列，面积与时序随约束迭代的变化曲线，在后来与第六章的"综合 versus 布局布线"差异争论里提供了关键证据——纸面数据留存的习惯，到后端阶段会变成话语权。

案例复盘：一次三回合的收敛谈判

背景：CK770 首轮综合，报告显示计算域时序违例集中在互连矩阵的跨簇路径，最差余量为负；同时面积比架构估算高出约一成半。两个问题同时出现，典型的"约束与实现打架"局面。

操作。 第一回合，查约束而非改代码：核对发现互连的跨簇路径被误标为伪路径——当初为了压综合时间粗暴声明了整组豁免。取消误标后，工具立刻对这些路径全力优化，最差余量回正，但面积进一步上涨。第二回合，做架构级置换：互连矩阵里两处宽位宽的多路选择结构改成分时复用（吞吐换面积，2.3 节的预算余量足够覆盖），面积回落超标幅度的大半。第三回合，微调映射策略：对采集通路的中等深度组合链加"中速优先"权重，让它不再抢高速单元，高速单元集中供给真正的关键路径。

结果。 三回合后报告全面达标：时序余量为正且分布均匀，面积回到估算带内，约束路径覆盖率九成八。复盘时团队把三回合的每一步改动与效果记进台账，形成该项目的"收敛手册"——第六章布局布线阶段遇到类似病灶时直接按手册抓药，省了不止一轮迭代。

解读。 这场谈判的方法论浓缩成一句话：先怀疑约束，再怀疑代码，最后才动架构。多数"综合不收敛"的病灶在约束的误标与缺标；约束干净之后仍不收敛，才轮到 RTL 重构；架构级置换是最后的底牌，动它要带着 2.3 节的预算余量一起评估。反着来的团队（一不收敛就改代码、改完架构）会把三轮的路走成十轮，因为前面的病灶根本没除。

变式。 若报告显示的不是个别路径违例而是全域崩塌，问题多半在时钟定义或工艺库版本这类"地基"上，先核对输入再谈优化；若时序轻松达标而功耗初估表超预算，方向要反转为"降频加并行"或提前启动第七章的门控方案——综合阶段的每一张表，都是下游某个章节的开卷题。

常见问题辨析

问：报告里"未约束路径"为什么是红灯而不是绿灯？

因为分析工具对未约束路径的处理是放行——没有时序要求，就没有违例报告，路径处于"未受检"状态。绿灯的前提是"检查过且合格"，未检查的路径连参赛资格都没有。这就是约束覆盖率必须先核对的逻辑：覆盖率的分母是全部路径，分子是受检路径，分母不清零，所有绿都是局部绿。CK770 把覆盖率九成五设为签核前置门槛，正是给这道逻辑上了锁。

问：面积与时序两目标打架时，听谁的？

听产品需求的那一档。面积指标背后是成本结构（die 尺寸与良率），时序指标背后是性能承诺，两者都换算成钱之后才能比较——单独在工具参数层面谈"面积优先还是时序优先"是伪问题。工程上的可执行做法是把二者的预算线在约束文件里都写死：时序余量的下限（签核要求）与面积的成本上限（成本核算），工具在两线之内自由优化；两线打架时升级到架构评审，用 2.3 节式的量级账当裁判，而不是让某个环节默默替产品做决定。

本节要点回顾

• 综合器是听话而无常识的优等生：它优化的方向由约束决定，约束的质量决定结果的质量。
• 约束文件是架构承诺的工具语复述：时钟定义对齐 3.1 节方案，路径例外要逐条核对，伪路径声明是免检合同。
• 质量报告盯三张表：时序摘要看余量与覆盖率、面积表对架构估算、功耗初估给第七章对账。
• 收敛谈判的顺序铁律：先查约束、再改代码、最后动架构，每一步留痕成手册。

RTL 与网表都已就绪，是时候让 CK770 动起来了——下一节是一次完整的动手实验：从空目录开始，搭一颗能在仿真器里点亮的最小 SoC。