4、调度器微架构：调度器内部模块划分、指令缓存与取指单元、Scoreboard与依赖追踪

好，咱们今天聊聊调度器内部到底长什么样。说白了，调度器就是GPU的“大脑”，它决定哪条指令该什么时候跑。我做了这么多年芯片，见过太多调度器设计翻车的案例——要么是取指跟不上执行，要么是依赖追踪把自己绕晕了。今天我把这些坑都摊开来讲。

4.1 调度器内部模块划分

一个典型的调度器，内部可以拆成几个关键模块。我个人习惯把它们分成三块：取指单元、Scoreboard、发射逻辑。你想想看，这就像一条流水线——先拿指令，再查依赖，最后决定谁先跑。

具体模块如下：

• 指令缓存（I-Cache）：存放从显存取来的指令。嗯，这里要注意，I-Cache的大小直接决定了你能隐藏多少延迟。
• 取指单元（Fetch Unit）：负责从I-Cache中取出指令，并做初步解码。
• Scoreboard：记录所有寄存器的状态，谁在用、谁空闲。这是依赖追踪的核心。
• 发射队列（Issue Queue）：存放等待发射的指令，等待Scoreboard放行。
• 仲裁器（Arbiter）：决定哪条指令优先发射到执行单元。

4.2 指令缓存与取指单元

指令缓存，说白了就是GPU的“小本本”。它存着接下来要执行的指令。取指单元呢，就是那个翻本本的人。

取指单元的工作流程大致如下：

1. 从I-Cache中读取指令地址。
2. 判断是否命中缓存。如果没命中，就得去显存取——这很慢。
3. 取到指令后，做初步解码，提取出操作码、目标寄存器、源寄存器等信息。
4. 把解码后的指令送到Scoreboard和发射队列。

我曾经在一个项目中，发现取指单元总是卡在I-Cache miss上。后来一查，原来是缓存行大小设置不合理。GPU的指令密度很高，缓存行太小会导致频繁miss。我建议你至少设置128字节的缓存行，配合预取机制，效果会好很多。

取指单元的硬件实现，我一般用状态机来控制。核心状态就三个：IDLE、FETCH、DECODE。代码示例如下：

// 取指单元状态机（简化版）
typedef enum {
    IDLE,
    FETCH,
    DECODE
} fetch_state_t;

always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
        state <= IDLE;
    end else begin
        case (state)
            IDLE: begin
                if (fetch_enable) state <= FETCH;
            end
            FETCH: begin
                if (icache_ready) state <= DECODE;
            end
            DECODE: begin
                if (decode_done) state <= IDLE;
            end
        endcase
    end
end

4.3 Scoreboard与依赖追踪

Scoreboard，这个名字听起来挺唬人，其实就是一个大表格。它记录着每个寄存器当前的状态：是否被占用、被哪条指令占用、什么时候释放。

依赖追踪的核心逻辑是这样的：

• 每条指令都有源寄存器（读）和目标寄存器（写）。
• 如果目标寄存器和某条正在执行的指令的目标寄存器相同，那就是写后写（WAW）依赖。
• 如果源寄存器和某条正在执行的指令的目标寄存器相同，那就是写后读（RAW）依赖。
• 读后写（WAR）依赖在Scoreboard中一般不用管，因为GPU的寄存器文件支持乱序读。

你想想看，如果Scoreboard设计得不好，依赖追踪就会变成瓶颈。我记得有一次调试，发现Scoreboard的更新延迟太高，导致发射队列空转了好几个周期。后来我把Scoreboard的更新逻辑从组合逻辑改成了流水线寄存器，问题就解决了。

Scoreboard的硬件实现，我一般用CAM（内容可寻址存储器）来做。CAM可以快速查找某个寄存器是否被占用。但CAM面积大、功耗高，所以需要权衡。我建议你只在关键路径上用CAM，其他场景用SRAM+比较器即可。

下面是一个Scoreboard的简化表格：

寄存器编号	占用状态	占用指令ID	预计释放周期
R0	空闲	-	-
R1	占用	Inst_5	Cycle_12
R2	占用	Inst_8	Cycle_15
R3	空闲	-	-

依赖追踪的流程，我习惯用伪代码来描述：

// 依赖检查逻辑
for each instruction in issue_queue:
    for each src_reg in instruction.src_regs:
        if scoreboard[src_reg].busy:
            // 存在RAW依赖，等待
            instruction.ready = false
            break
    for each dst_reg in instruction.dst_regs:
        if scoreboard[dst_reg].busy:
            // 存在WAW依赖，等待
            instruction.ready = false
            break
    if instruction.ready:
        // 可以发射
        issue_to_execution(instruction)
        // 更新Scoreboard
        for each dst_reg in instruction.dst_regs:
            scoreboard[dst_reg].busy = true
            scoreboard[dst_reg].owner = instruction.id

嗯，这里要注意，Scoreboard的更新和发射是同步的。如果发射逻辑和Scoreboard更新不同步，就会出现“幽灵依赖”——明明寄存器已经释放了，Scoreboard还显示占用。我曾经因为这个bug调了整整两天。

好了，这一章就讲到这里。下一章我们会聊聊发射逻辑的具体实现，包括仲裁策略和乱序发射的硬件代价。到时候见。