4.2 前端设计与RTL编码

4.2 前端设计与 RTL 编码

开发节奏由 4.1 节定好，本节进入编码现场。RTL（寄存器传输级）是硬件工程师的母语：它不描述算法步骤，而描述"每个时钟沿寄存器里存什么、组合逻辑怎么算"。这门语言的最大特点是你在描述并行发生的电路，而不是在写顺序执行的程序——绝大多数编码事故都源于用软件思维写硬件。读完本节，你应当掌握一套过得了综合与验证两道门的编码纪律，并能识别最常见的三类反面教材。

可综合这道门槛

RTL 代码有两个读者：仿真器（什么都懂）与综合器（只认电路）。仿真器能执行的语法，综合器未必能变成电路——延迟控制、文件读写、动态内存这些"验证专用"语法，出现在设计代码里就是事故。这道门槛叫可综合性，它的判断标准朴素得可爱：这句话能对应一片电路吗？寄存器赋值对应触发器，组合运算对应逻辑门，条件分支对应多路选择器；对不上电路的，综合器要么报错、要么悄悄按它的理解改写——后者更危险，因为"悄悄改写"往往和你想的不一样。

比语法门槛更深的门槛是时序与组合的边界感。硬件设计里只有两类逻辑：时钟沿触发的寄存器，和始终活跃的组合逻辑。写 RTL 就是在给每段逻辑归类：这段是"打一拍再走"（时序），还是"穿过即算"（组合）？归类错误的两个典型症状——该打拍的路径上没打拍，综合后关键路径长得离谱；不该有锁存器的分支里变量没给全，综合器替你补了一个锁存器，时序分析立刻冒出一堆意外路径。4.3 节综合报告里的问题，一大半能回溯到这里。

下面用一段真实的反面示例开场，再给出修正版。场景是一个带握手的数据接收模块：收到有效数据就置标志，软件取走后清标志。

// 反面教材：三宗罪
module rx_bad (
    input  logic        clk,
    input  logic        rst_n,
    input  logic        data_valid,
    input  logic [7:0]  data_in,
    input  logic        software_taken,   // 软件取走
    output logic        flag,
    output logic [7:0]  data_buf
);
    always_latch begin                  // 罪一：误用锁存器，data_buf 在部分分支下保持旧值
        if (data_valid) data_buf = data_in;
    end

    always_ff @(posedge clk or negedge rst_n) begin
        if (!rst_n)
            flag <= 1'b0;
        else if (data_valid && flag)
            flag <= data_valid && flag; // 罪二：自我赋值，写法混乱，逻辑意图不明
        else if (data_valid)
            flag <= 1'b1;
        else if (software_taken)
            flag <= 1'b0;               // 罪三：software_taken 与 data_valid 同时到时，两个分支都合法，优先级靠书写顺序决定——这就是隐式优先级陷阱
    end
endmodule
​

这段代码在仿真里可能"看起来能跑"，三个雷却都埋进了硅片：锁存器带来意外的时序路径，自我赋值让评审者猜意图，隐式优先级让两个输入同时到达时的行为依赖代码书写顺序。修正版把意图摊开：

// 修正版：数据通路与标志位分离，优先级显式
module rx_good (
    input  logic        clk,
    input  logic        rst_n,
    input  logic        data_valid,
    input  logic [7:0]  data_in,
    input  logic        software_taken,
    output logic        flag,
    output logic [7:0]  data_buf
);
    // 数据寄存：只在有效时更新，标准时序写法
    always_ff @(posedge clk or negedge rst_n) begin
        if (!rst_n)
            data_buf <= 8'd0;
        else if (data_valid)
            data_buf <= data_in;
    end

    // 标志寄存：清除优先于置位，意图写死在代码结构里
    always_ff @(posedge clk or negedge rst_n) begin
        if (!rst_n)
            flag <= 1'b0;
        else if (software_taken)
            flag <= 1'b0;              // 先判清除
        else if (data_valid)
            flag <= 1'b1;              // 再判置位
        // 其余情况保持
    end
endmodule
​

两个版本的行数差不多，但第二版里"数据怎么存、标志怎么管理"的意图一眼可读——这正是 RTL 编码纪律的第一原则：让评审者读意图，而不是读字符。

图：从规格语句到电路的门类归属

三条高频纪律的展开

位宽显式。运算与赋值里的位宽截断，编译器只警告不阻止，仿真里截断值恰好"看起来对"的案例比比皆是。纪律是：跨位宽赋值一律写显式转换或扩展，比较运算两边位宽必须一致，位宽演进（比如计数器从八位涨到九位）要靠参数化而不是手工改。CK770 的帧计数器就吃过亏：八位计数器在压力测试里悄悄溢出回卷，功能验证全绿，压力场景直接错乱——这颗雷在 5.1 节的覆盖率分析里才被揪出来。

复位完整。每个时序块必须有明确的复位分支，且全芯片统一复位极性与风格。复位遗漏的寄存器在仿真里有初值、在硅片上是不定态——不定态会顺着组合逻辑扩散，上电行为变成抽签。这条纪律与 8.4 节的启动可靠性直接挂钩：启动链上任何一个不定态寄存器，都可能让"十次点亮九次半"。

跨时钟域显式声明。信号从一个时钟域进另一个时钟域，必须走同步器，且代码里要用命名与注释把来源域标清楚。这条纪律是 5.3 节整个排错实录的预防针，那里有一个省略同步器导致的真实事故——这里先把纪律立好。

案例复盘：一场代码评审拦下的状态机缺陷

背景：CK770 的串口接收模块评审。提交的代码里，接收状态机有五个状态，转移条件写在三个不同的条件分支里。评审人按"状态转移表逐行核对"的老规矩办事。

操作。 评审人把代码里的转移条件手工整理成一张五乘五的状态表，与规格书的状态图对照。两处出入当场现形：其一，规格书里"帧错误态"在任何时刻收到复位命令都应转回空闲，代码里只在两个状态下处理了复位命令，其余三个状态会吞掉它；其二，错误计数器的清零条件写在转移分支内部而非状态内部，导致"停在错误态但计数已清"的中间态——规格书里不存在这个状态。

结果。 提交人当场修改：转移条件全部收拢到单一分支结构，按状态表逐行书写；错误计数器改为独立时序块管理。修改后的代码用状态表做了自动化比对，两个缺陷均被回归用例覆盖。这场评审耗时四十分钟，拦下的是两个上仿真都未必立刻现形、上了硅片必然偶发的缺陷。

解读。 案例的方法论价值大于战果本身：状态机缺陷的克星是"表格化"。人眼扫代码抓不出"三个分支里的隐式优先级"，但表格能——逐格对照是机械动作，机械动作不会漏。团队后来把"状态机必须附转移表"写进了提交模板，评审时间平均省下一半。另一个值得记的细节：缺陷二的本质是"状态与数据没有分离"，与前面修正版示例里"标志与数据分块"是同一条原则的两个化身。

变式。 若状态机规模再大（几十个状态），手画表格不现实，此时该上的工具是形式等价检查或断言：把规格书的状态图写成断言，仿真器自动逐拍核对——第五章功能验证一节会展开这套方法。小状态机靠表格、大状态机靠断言，工具变，"表格化对照"的思路不变。

本节要点回顾

• RTL 的两个读者（仿真器与综合器）标准不同：可综合性是设计代码的入场券，"能仿真"远不等于"能上硅"。
• 编码的第一件事是归类：每段逻辑要么时序要么组合，归类错误的两大症状是意外锁存器与超长组合路径。
• 位宽显式、复位完整、跨域显式声明是三条高频纪律，各自对应一类真实的硅片事故。
• 状态机评审的关键动作是表格化对照：把代码的转移条件还原成状态表，逐格与规格书核对。

代码写完了，但它还只是"描述"。下一节请综合器登场，把这些描述变成真正的门级网表——并教你与工具谈判的手艺。