第1章：RTL设计与综合约束

各位同学好，我是老李。做数字IC设计十几年了，今天咱们聊聊RTL代码风格对综合的影响，以及常用的综合约束。说实话，我刚入行那会儿，觉得写RTL就是实现功能，综合是工具的事。后来被现实狠狠教育了一回——同样的功能，不同写法，综合出来的面积和时序能差出一大截。

1.1 RTL代码风格对综合的影响

先说说代码风格。很多人觉得这玩意儿是形式主义，其实不然。综合工具虽然智能，但它不是神仙。你写出来的代码，它得能读懂、能优化。

1.1.1 组合逻辑的写法

我个人习惯，组合逻辑尽量用always @(*)块，配合case或if-else。这里有个坑——if-else的优先级结构会生成优先级编码器，而case语句生成的是并行结构。

// 不好的风格：嵌套if-else，综合出优先级链
always @(*) begin
    if (sel == 2'b00)
        out = a;
    else if (sel == 2'b01)
        out = b;
    else if (sel == 2'b10)
        out = c;
    else
        out = d;
end

// 好的风格：case语句，综合出多路选择器
always @(*) begin
    case (sel)
        2'b00: out = a;
        2'b01: out = b;
        2'b10: out = c;
        2'b11: out = d;
    endcase
end

我在项目中遇到过，有人用嵌套if-else写了一个16选1的MUX，综合后面积比预期大了30%。为什么？因为工具推断出了优先级链，而不是并行MUX。你想想看，16级优先级链，那延迟得多大？

1.1.2 时序逻辑的写法

时序逻辑，我建议统一用非阻塞赋值（<=）。这不是什么玄学，而是仿真和综合的一致性要求。阻塞赋值（=）在组合逻辑里用没问题，但用在时序逻辑里，仿真行为和综合结果可能对不上。

// 推荐的时序逻辑写法
always @(posedge clk or negedge rst_n) begin
    if (!rst_n)
        q <= 1'b0;
    else
        q <= d;
end

1.1.3 资源共享与代码结构

综合工具会自动做资源共享，但前提是你的代码结构得让它能识别。比如两个运算共用同一个加法器，你得写清楚。

// 工具可以自动共享加法器
always @(*) begin
    if (sel)
        result = a + b;
    else
        result = c + d;
end

// 这种写法，工具可能推断出两个加法器
always @(*) begin
    if (sel)
        result = a + b;
    else
        result = c + d;
    // 实际上是一样的，但有些工具对复杂条件判断会保守处理
end

说白了，你写代码时心里要有硬件结构图。每个always块对应什么硬件，数据流怎么走，这些想清楚了再下笔。

1.2 常用的综合约束

约束是综合的灵魂。没有约束，工具就像没头苍蝇。我见过太多人，RTL写得漂亮，但约束一塌糊涂，最后综合出来的结果根本不能用。

1.2.1 时序约束

时序约束是最核心的。说白了，就是告诉工具：我的芯片要跑多快，哪些路径是关键路径。

约束类型	命令/语法	说明
时钟定义	create_clock	定义时钟周期、占空比
输入延迟	set_input_delay	输入信号相对于时钟的延迟
输出延迟	set_output_delay	输出信号相对于时钟的延迟
伪路径	set_false_path	不需要时序检查的路径
多周期路径	set_multicycle_path	需要多个时钟周期的路径

// 一个典型的时序约束示例
create_clock -name clk -period 10 [get_ports clk]
set_input_delay -clock clk -max 2 [get_ports data_in]
set_output_delay -clock clk -max 3 [get_ports data_out]
set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b]

1.2.2 面积约束

面积约束，说白了就是告诉工具：别给我整太大，我芯片面积有限。常用的命令是set_max_area。

// 设置面积约束
set_max_area 10000  // 单位取决于库，通常是um²

嗯，这里要注意。面积约束和时序约束是矛盾的。你让工具拼命优化时序，它就会多用组合逻辑、多插buffer，面积自然就大了。反过来，你死压面积，时序可能就崩了。

我在项目中遇到过，有个模块时序很紧，我设了很严格的时序约束，结果面积比预期大了40%。后来和架构师商量，放宽了部分路径的时序要求，面积才降下来。这就是trade-off。

1.2.3 功耗约束

功耗约束现在越来越重要。特别是移动芯片和AI芯片，功耗是硬指标。常用的方法有：

• 时钟门控：综合工具会自动插入时钟门控，但需要你在RTL里写清楚使能信号
• 操作数隔离：当输出不被使用时，屏蔽输入数据的变化
• 多阈值电压：在时序宽松的路径上用高阈值单元（漏电小），关键路径上用低阈值单元（速度快）

// 功耗约束示例
set_max_dynamic_power 100  // mW
set_max_leakage_power 10   // mW

1.3 综合策略的选择

综合不是一键搞定的事。不同的设计目标，要用不同的策略。

设计目标	推荐策略	约束重点
高性能	激进优化时序，允许面积增大	严格的时钟约束，多周期路径要少
低功耗	优先使用高阈值单元，插入时钟门控	功耗约束优先，时序可适当放宽
小面积	资源共享，减少冗余逻辑	面积约束严格，时序满足即可

你想想看，如果做的是手机芯片，功耗和面积都很敏感。但如果是服务器芯片，性能才是第一位的。所以，约束没有标准答案，得看你的应用场景。

1.4 综合后的检查

综合跑完了，别急着高兴。得检查几个关键点：

• 时序报告：看setup和hold是否满足，slack是正是负
• 面积报告：对比预估面积，看是否超标
• 功耗报告：检查动态功耗和静态功耗
• 网表质量：有没有悬空引脚、有没有组合逻辑环路

好了，这一章就讲到这里。总结一下：RTL代码风格直接影响综合结果，好的风格让工具事半功倍；约束是综合的指挥棒，时序、面积、功耗三者要平衡。下一章我们聊聊综合工具的具体使用和脚本编写。

记住一句话：写代码时想着硬件，设约束时想着应用。这样你的设计才能既快又稳。