仿真器出bug了？分频时钟竞争的诡异仿真现象

带有分频时钟的仿真有时候看起来完全pass的，但采样的数据却是错的。这种bug比X态更阴险，因为它会让你误以为设计没问题，结果上板或流片后功能全乱套。

场景是这样的：clkb是clka的4分频，用clkb去采样clka域的多bit数据。按理说clkb上升沿到来时，data应该已经在clka域稳定了，采样到的应该是"旧值"。

但仿真结果是：每次都采样到"新值"。

go 复制代码

reg [7:0] data_a;  // clka域的数据
reg [7:0] data_b;  // clkb域采样后的数据
reg [1:0] div_cnt;
reg clkb;

// clka域产生数据和分频时钟
always @(posedge clka) begin
    data_a <= data_a + 8'h1;  // 每个周期递增
    
    div_cnt <= div_cnt + 1;
    if (div_cnt == 2'b11)
        clkb <= ~clkb;
end

// clkb域采样
always @(posedge clkb) begin
    data_b <= data_a;
end

// 预期（真实芯片）：data_b = 0x00, 0x04, 0x08, 0x0C...
// 仿真器结果：    data_b = 0x04, 0x08, 0x0C, 0x10...  
// 整体偏移一个数据

整个数据流都错位了，功能完全不对。

为什么会这样

核心原因是仿真器的事件调度机制。在一个时刻，有两个事件同时发生：

clka上升沿：触发data_a <= data_a + 1
clkb上升沿：触发data_b <= data_a

仿真器必须选择一个顺序来执行这两个事件。由于Verilog标准规定同一个always块内的非阻塞赋值在时间槽末尾才更新，但不同always块之间的执行顺序是未定义的，仿真器可能会：

go 复制代码

仿真器处理流程：
Step 1: 执行clka的always块
        → data_a的调度队列中加入新值0x3C
Step 2: 执行clkb的always块  
        → data_b的调度队列中加入data_a当前值
Step 3: 时间槽结束，所有赋值同时生效
        → data_a变成0x3C
        → data_b也变成0x3C（错误！）

问题在于Step 2执行时，data_a虽然还没更新，但仿真器的调度队列里已经有了新值的信息。某些仿真器会让data_b读到这个"即将生效"的值，导致采样错位。

更要命的是仿真能通过

这种问题最坑的地方在于：仿真有可能完全不报错，波形看着也很正常。data_b确实在clkb上升沿更新了，数值也是合法的，只不过采样时机整体偏移了一拍。

如果测试激励设计得不够严密，比如只检查"数据有没有更新"而不检查"具体更新成什么值"，这个bug能一路绿灯通过仿真验证。等到芯片回来上电一测，发现功能完全对不上，才开始疯狂debug。

go 复制代码

// ❌ 这种testbench检查不出问题
always @(posedge clkb) begin
    if (data_b_old != data_b)
        $display("Data updated");  // 通过，但采样错了
end

// ✓ 必须这样检查
integer expect_cnt = 0;
always @(posedge clkb) begin
    expected = expect_cnt * 4;  // 应该是4的倍数
    if (data_b != expected) begin
        $error("Wrong! Got 0x%h, expect 0x%h", data_b, expected);
        $stop;
    end
    expect_cnt = expect_cnt + 1;
end

真实芯片为什么没事

因为综合工具和STA工具看的是物理时序，不是仿真器的事件顺序。在真实电路里：

go 复制代码

物理时序关系（以T4为例）：

CLKA上升沿 → data_a触发器Tco → data_a输出稳定（旧值0xA5）
                                          ↓
CLKA上升沿 → 分频器逻辑延迟 → CLKB上升沿 ← 此时采样到0xA5

即使clkb在同一个clka周期内产生，它也必然经过分频器的组合逻辑延迟。这个延迟保证了当clkb上升沿到达时，data_a已经稳定在旧值上了。

只要STA验证满足：

go 复制代码

Tclk_to_clk (CLKA到CLKB的延迟) > Tco (data_a的时钟到输出)

那么采样就是安全的。物理定律保证了正确性，仿真器的调度顺序反而是错的。

怎么让仿真也正确

方法1：显式建模延迟

go 复制代码

reg clkb_raw;
wire #1 clkb = clkb_raw;  // 仿真延迟1个时间单位

always @(posedge clka) begin
    if (div_cnt == 2'b11)
        clkb_raw <= ~clkb_raw;
end

强制让clkb晚于data_a更新。综合工具会忽略#1延迟，不影响实际电路。

方法2：回归单时钟域设计

go 复制代码

reg [7:0] data_b;
reg clkb_en;

// 全在clka域操作
always @(posedge clka) begin
    div_cnt <= div_cnt + 1;
    clkb_en <= (div_cnt == 2'b11);
    
    if (clkb_en)
        data_b <= data_a;  // 用使能信号代替分频时钟
end

不用真正的分频时钟，改用使能信号。仿真和实现完全一致，这是最保险的方案。

这个问题揭示了一个事实：仿真通过不代表设计正确。Verilog仿真器只是个行为模拟工具，它模拟的是代码的逻辑行为，不是真实电路的物理时序。

分频时钟看起来是同步的，在仿真上实际上仍然属于多时钟域 问题。仿真器不认这套逻辑。它只认事件调度顺序，而这个顺序跟真实硬件可能完全相反。