CPU与简单模型机设计实验：从数据通路到控制器的完整方案

简介：这是计算机组成原理课程中“CPU与简单模型机设计实验”的完整实验报告PDF，面向高校计算机相关专业学生和正在学习CPU组成、微程序控制器的读者。报告以TD-CMA实验系统为平台，从运算器、微程序控制器、通用寄存器、指令寄存器、程序计数器和地址寄存器等部件出发，完整演示由简单CPU扩展主存与输入输出部件、构建模型计算机的过程，并定义了IN、ADD、OUT、JMP、HLT五条机器指令及对应微程序。资源仅含1个PDF文件，压缩包约830KB，内容覆盖实验目的、设备、原理、数据通路图、微程序流程图、二进制微代码表、手动与联机写入校验等关键资料，便于课前预习、实验对照或课后复习。已有2805人学习下载，适合需要理解整机概念、微程序设计与机器指令执行过程的读者。

1. CPU与简单模型机设计实验.pdf：为什么照抄数据通路也会翻车

刚拿到《CPU与简单模型机设计实验.pdf》的时候，很多人以为这是又一份照着画的电路图：连一连寄存器、放一个ALU，再写一段Verilog就完事。但真正动手就会发现，最难的不是把模块例化在一起，而是一条指令从取指到写回，每一步都要靠控制信号在正确的节拍里出现或消失。比如你让ALU算完一个加法，但寄存器的写使能早了一个节拍，读到的还是旧值。这个实验就是用一台十几条指令的小模型机，逼你把“指令→二进制编码→控制信号→数据通路”这条链路彻底打通。它适合计算机组成原理课程的学生，也适合想补CPU基础的嵌入式开发者。这篇文章会把我在类似实验里的完整方案和踩过的坑按步骤讲清楚。

2. 先把骨架立起来：指令格式、总线结构与存储器的设计顺序

在写任何代码之前，先把模型机的“图纸”画出来。这一章解决三个问题：指令长什么样、数据从哪里走到哪里、存储器和寄存器组怎么安排。很多同学一上来就写模块，结果后面改指令格式牵一发动全身。你先要确定的是设计边界：这是单周期还是多周期？支持几条指令？寄存器用几个？这些参数都直接来自实验PDF里的验收要求，但PDF往往只给目标，不给中间选择。我的习惯是先把最保守的版本定下来：16位定长指令、8个寄存器、单总线多周期，跑通后再考虑扩展。

2.1 指令位长与格式：决定模型机复杂度的第一张图纸

模型机实验最常用的是16位定长指令。为什么是16位？因为8位指令塞不下足够多的操作数，32位指令对初学模型机来说浪费太多控制逻辑。16位指令可以拆成：

这个格式适合寄存器-寄存器指令，比如ADD R0, R1, R2。但存储器访问指令需要地址，所以还要设计第二条格式：操作码(4位) + 寄存器(4位) + 立即数/地址(8位)。立即数指令和跳转指令共用这个格式。我在类似实验里，指令集只保留了12条：ADD、SUB、AND、OR、XOR、LOAD、STORE、MOVI、JMP、JZ、HLT、NOP，操作码从0000到1011，留出冗余，方便以后扩展。

完整指令集设计如下表。这里操作码是二进制前导0补满4位，寄存器编号为十六进制单字符：

定义指令集时最好用脚本生成一个编码映射表，避免手写一条条二进制。下面是一个用Python生成机器码表的脚本片段：

# 指令编码映射：操作码 -> 助记符 # 4位操作码，16进制表示，高位在前 OPCODES = { "ADD": 0x0, "SUB": 0x1, "AND": 0x2, "OR": 0x3, "XOR": 0x4, "LOAD": 0x5, "STORE": 0x6, "MOVI": 0x7, "JMP": 0x8, "JZ": 0x9, "HLT": 0xA, "NOP": 0xB } def encode_rr(op, rd, rs1, rs2): # 寄存器型：操作码4位 + 3个寄存器各4位，共16位 assert 0 <= op < 16 and 0 <= rd < 16 assert 0 <= rs1 < 16 and 0 <= rs2 < 16 return (op << 12) | (rd << 8) | (rs1 << 4) | rs2 def encode_imm(op, rd, imm): # 立即数型：操作码4位 + 寄存器4位 + 8位立即数/地址 assert 0 <= imm < 256 return (op << 12) | (rd << 8) | imm if __name__ == "__main__": print(f"ADD R1, R2, R3 = 0x{encode_rr(OPCODES['ADD'], 1, 2, 3):04x}") print(f"MOVI R0, 0x55 = 0x{encode_imm(OPCODES['MOVI'], 0, 0x55):04x}")

逻辑说明：encode_rr用移位把每个字段放到固定位置，encode_imm把8位立即数放在低字节。使用脚本的好处是，后续模拟器、汇编器和Verilog测试向量都从同一份映射生成，不会出现某条指令编码对不上的问题。参数说明里需要注意：操作码位宽4位不代表只能用4位，如果你有15条指令以上，可以考虑扩展操作码字段，但为了让控制器简单，一开始就固定4位更稳。另一个坑是JZ指令的条件判断，需要指定一个寄存器而不是用标志位，这样可以省去状态寄存器，但代价是每条分支指令前要显式比较。

指令格式确定后，还要定义内存映射。我在这个实验里把程序放在地址0x00-0x1F，堆栈放在0x20-0x3F，数据区从0x40开始。这样LOAD/STORE的8位地址可以直接寻址，不需要分段。如果你用的RAM深度只有64，地址映射就要重新规划，否则程序写满后会覆盖数据区，排查起来非常费时。

2.2 数据通路选型：单总线、双总线与三总线对控制信号的影响

数据通路决定了指令执行要分几个节拍，也决定了控制器要产生多少控制信号。模型机实验最常见的三种：

如果实验PDF没有强制要求单周期，我一般会选单总线。原因很朴素：控制信号少，出问题好查。单总线模式下，一条ADD指令至少需要三个节拍：取指（把PC对应的指令取到IR）、读源操作数（把R1、R2先后送上总线）、执行写回（ALU输出送总线再写入R0）。虽然慢，但每个节拍做什么一目了然。

画数据通路图的时候，要标出每个部件的数据输入输出是否受三态门控制。有一个血泪经验：单总线上挂太多输出端，如果忘记给某部件加输出使能，总线就会出现多驱动冲突，仿真看到的高阻态Z就是从这里来的。所以选单总线结构后，第一件工作是列出总线输出源列表：

这些输出使能信号在控制器里用xxx_EN命名，后面写控制信号真值表时一一对应。这里要多说一句：单总线结构并不是每个节拍都必须把数据放到总线上，很多节拍总线是高阻态Z，只有当某个部件的输出使能拉高时才驱动总线。如果你在仿真里看到总线一直是Z，不要慌，这是正常的；但如果某个应该出数据的节拍总线还是Z，就要检查对应的输出使能信号是否被译码或时序逻辑截断了。

选型时还有一个容易被忽略的因素：实验指导书里的验收波形。如果PDF要求展示几条指令连续执行时的总线状态，那么单总线的多周期方式更符合“一个地址、一个数据”的直观时序。如果PDF要求单周期CPU，即每条指令在一个时钟周期内完成，那就要选择并行度更高的通路，此时控制器不再是复杂的多节拍状态机，而是纯组合逻辑，难度转移到“如何在同一个节拍内让取指、读寄存器、ALU计算、写回互不干扰”。我建议严格按照PDF要求来，不要为了追求先进选三总线，最后验证时序对不上。

2.3 存储器和寄存器组：地址位宽、时序和读写冲突怎么定

模型机的程序存储器和数据存储器可以共用一块RAM，也可以分离。共用一块RAM时，LOAD/STORE和取指都会访问它，需要避免同一拍里既要取指又要读写数据。这里的常见做法是把取指安排在节拍T0，数据访问安排在T2，这样冲突自然错开。但如果你做的是单周期CPU，就必须用哈佛结构，把指令存储器和数据存储器分开，否则同一拍内会读出两个不同地址的数据。

寄存器组我建议只做8个寄存器，地址3位，但为了对齐16位指令格式，寄存器字段仍然给4位，高位置0即可。这样以后扩到16个寄存器也不用大改。寄存器组的Verilog模板如下：

module regfile #( parameter ADDR_W = 4, // 寄存器地址位宽，支持16个寄存器 parameter DATA_W = 16 // 数据位宽 )( input clk, input rst_n, input [ADDR_W-1:0] raddr1, input [ADDR_W-1:0] raddr2, input [ADDR_W-1:0] waddr, input [DATA_W-1:0] wdata, input wen, output logic [DATA_W-1:0] rdata1, output logic [DATA_W-1:0] rdata2 ); // 寄存器堆用二维数组 logic [DATA_W-1:0] regs [0:2**ADDR_W-1]; integer i; // 异步复位，所有寄存器清零 always_ff @(posedge clk or negedge rst_n) begin if (!rst_n) begin for (i = 0; i < 2**ADDR_W; i++) regs[i] <= 0; end else if (wen) begin regs[waddr] <= wdata; end end // 读操作是组合逻辑：读地址直接得到当前寄存器值 assign rdata1 = regs[raddr1]; assign rdata2 = regs[raddr2]; endmodule

这段代码在仿真里能跑，但有个隐患：读端口是组合逻辑，如果同一拍wen写入waddr，而raddr1恰好等于waddr，读到的还是旧值，因为非阻塞赋值regs[waddr] <= wdata的结果要到下一个时钟沿才生效。这是你自己会不会踩的坑取决于控制器时序。我在多周期模型机里把“读寄存器”放在执行节拍的开始时，“写回”放在节拍结束时，利用时钟沿把读写天然错开，所以组合读不会造成问题。

存储器的设计参数也值得列一张表：

如果你用FPGA平台，存储器的初始化文件通常有两种格式：.mem和.coe。.coe文件每行一个十六进制数，带逗号，最后一行分号；.mem文件每行一个十六进制数，不需要分号。实验PDF如果给了模板，直接用它的格式；如果没给，我一般用.coe，因为好多IP核工具默认支持。初始化文件的内容就是2.1节用Python生成的机器码表，脚本直接输出这种文件，省去手工录入。

读写冲突还有一个常见来源：RAM的读使能和输出数据之间有一个时钟周期延迟。如果仿真用的异步RAM模型没有管脚延迟，仿真波形很干净，但上板后换成同步RAM就会读错。最稳妥的办法是在设计寄存器堆和RAM之前，先确认平台提供的RAM原语或IP核的读延迟参数，再决定数据通路里要不要多等一拍。这一拍之差就是“仿真全对、上板翻车”的头号来源。

3. 控制器：把操作码翻译成节拍，硬布线和微程序怎么选

指令格式和数据通路都定下来后，核心就是控制器。控制器的任务很简单：在正确的节拍，合上正确的开关。但实现方式有两条老路：硬布线控制器和微程序控制器。这一章会带你确定选型，并且把控制信号真值表列清楚。

3.1 硬布线控制器：最直观但最繁琐的状态机设计

硬布线控制器本质上是一个有限状态机。每个状态对应一个节拍，组合逻辑根据当前状态和指令操作码产生所有控制信号。优点是速度快，适合几十条指令以内的CPU；缺点是每改一条指令就要重新画状态图、改逻辑方程，指令一多直接失控。

我习惯先在纸上画出三类状态：取指（FETCH）、译码（DECODE）、执行（EXECUTE）。在单总线多周期架构里，每个状态内部还可以细分T0、T1。比如ADD的执行阶段需要两个节拍：T2把R1、R2送ALU，T3把结果写回寄存器。而LOAD需要三个节拍：T2传地址，T3读存储器，T4写寄存器。

下面是一个用SystemVerilog描述的状态机骨架，只展示关键逻辑：

typedef enum logic [2:0] {FETCH, DECODE, EXEC1, EXEC2, HALT} state_t; state_t state, next_state; // 状态转移：最后一个执行节拍回FETCH always_comb begin // 默认下一状态为当前状态，避免未赋值锁存器 next_state = state; unique case (state) FETCH: next_state = DECODE; DECODE: next_state = EXEC1; // 译码完成后必然进入执行 EXEC1: next_state = EXEC2; // 简单指令可能不需要EXEC2 EXEC2: next_state = FETCH; // 回到取指 HALT: next_state = HALT; // 停机 endcase end

这个状态机故意简化了“不同指令有不同执行周期数”的情况。真正的做法是在DECODE段根据操作码覆盖next_state：比如NOP指令从DECODE直接回FETCH，加法走EXEC1+EXEC2，存储指令也走EXEC1+EXEC2。如果用硬布线，你要为每条指令单独确定“需要几个执行节拍”。我维护过一套25条指令的硬布线状态机，最难受的是每增加一条指令，所有状态转移分支都要重新审查。所以后续实验，我更多转向了微程序。

硬布线的控制信号输出常用always_comb实现。一个容易犯的错误是只写状态转移，不写输出信号，导致综合时把输出推断成锁存器。我建议把“状态转移逻辑”和“输出逻辑”分成两个always_comb块：第一个只计算下一状态，第二个根据当前状态和指令操作码给所有控制信号赋值。分块后，排查某个控制信号为什么不拉高，比在几百行的大组合逻辑里找要快得多。

3.2 微程序控制器：用“指令解释指令”的灵活方案

微程序控制器的思路是：把控制信号按顺序存进一个小RAM（控存），每条机器指令对应一小段微指令序列。CPU每次先取指令，再根据操作码决定从控存哪一行开始读取微指令，逐行执行。这样“指令系统”变成了“微程序库”，改指令只需要改控存内容，不需要动硬布线逻辑。

微指令的格式可以分成“控制字段”和“下址字段”两块。控制字段的每一位都代表一个控制信号，例如：

微程序表可以用文本定义，再用脚本生成ROM初始化文件。下面是一段ADD指令对应的微指令序列（伪代码，不是直接可综合的最终格式）：

# ADD R0, R1, R2 对应的微程序 # 每行一个节拍，字段顺序按上述表格 # 取指序列（所有指令公用）： FETCH1: IR_EN=1, PC_EN=1, ALU_OP=0x0, ALU_OUT_EN=0, RF_WE=0 FETCH2: IR_EN=0, PC_EN=0, ALU_OP=0x0, ALU_OUT_EN=1, RF_WE=0 # 译码后按操作码跳到ADD执行序列 ADD_EX1: ALU_OP=0x0, RF_WE=0, ALU_OUT_EN=1 # ALU计算 R1+R2 ADD_EX2: RF_WE=1, ALU_OUT_EN=0 # 把结果写进R0

这种格式的好处是每一步的信号一目了然。你把这个表填成完整真值表后，就可以用脚本把它转成.mem或.coe文件，下载到控存ROM。微程序控制器的硬件结构也不少：除了控存，还要有微指令寄存器（μIR）和微程序计数器（μPC）。μPC负责给出取微指令的地址，通常有顺序加一和跳转两种来源，跳转地址由操作码译码得到。设计时要注意：微程序计数器不能和普通PC共用一个模块，否则取指和取微指令会互相干扰。

微程序的缺点也很明显：每条机器指令要执行多段微指令，速度比硬布线慢；而且控存宽度不能太小，否则一个节拍需要的控制信号塞不下。我遇到的一个翻车现象是：设计微指令字段时图省事，把两个互斥但同一个节拍需要的信号编到了同一个位，导致控制信号只能二选一，ALU结果和写使能永远不能同时有效。所以在定义微指令字段前，一定要对照数据通路把所有控制信号列全，宁可多留几个冗余位。

3.3 控制信号真值表与时序安排：让每个节拍都“对得上”

无论选哪种控制器，最终都要落实到一张“节拍 × 指令 × 控制信号”的真值表。这张表是整个设计的检查依据。我用过的格式如下，以单总线多周期ADD指令为例：

这张表里的关键参数是ALU_OP编码：我习惯让0x0代表ADD，0x1代表SUB，0x2代表AND，0x3代表OR，0x4代表XOR。控制器在T1译码时从指令操作码映射到ALU_OP，在T2把它输出到ALU。注意T2和T3必须是两个节拍：如果T2同时开ALU_OUT_EN和RF_WE，组合逻辑的毛刺可能在时钟边沿被采到。

其他指令的真值表也要按这个思路画。比如STORE需要T3拉高MEM_WR，且不能让RF_WE同时有效；LOAD需要T2送地址，T3拉高MEM_RD，T4拉高RF_WE；JMP需要在T1直接把地址送入PC并拉高PC_EN。把每一条指令的节拍都画成一行，控制器写起来就不再是盲写。我一向建议先在Excel或文本里把这张表填完整，再开始写状态机，直接写代码很容易漏信号。

信号产生的时序也要统一。我一般让所有寄存器在时钟上升沿采样，而控制信号在下降沿变化。这样在一个时钟周期内，先有稳定的控制信号，再有寄存器采样，天然避免了竞争。用SystemVerilog描写就是：

// 在时钟下降沿更新控制信号，保证上升沿采样时信号已经稳定 always_ff @(negedge clk or negedge rst_n) begin if (!rst_n) begin ctrl_sigs <= '0; end else begin ctrl_sigs <= ctrl_comb; // ctrl_comb由状态和指令操作码组合逻辑产生 end end

这个“下降沿打一拍”的做法，看起来浪费了半个周期，但能减少大量亚稳态问题。尤其在上板调试时，触发的错误会少很多。你不需要把这个技巧写进实验报告，但它的价值会在上板那一刻体现出来。

4. 从仿真到上板：五个典型故障的定位与排查

控制器写好后，接下来是仿真和调试阶段。这一章专门讲我遇到的五个高频故障，每一条都按「现象 → 原因 → 解决」展开，方便你对照排查。调试方法论先说一句：不要开着全速波形找错，要把时钟放慢，逐拍看状态寄存器、PC、总线数据；最好先用仿真定位，再上板确认，否则会被时序抖动带偏。

4.1 清零和复位不同步导致第一条指令跑飞

现象：仿真刚开始时，PC并不是0，有时是0x0000，有时是0xFFFF；或者第一条取出的指令不是ROM里的第一个程序，而是随机值。

原因：PC、指令寄存器、寄存器堆分别使用了不同的复位逻辑。比如PC用的是异步复位，但程序存储器的输出在复位释放瞬间还没有稳定；或者复位信号只复位了部分模块，导致状态机进入了非法状态。另一个常见来源是仿真文件的initial块里给PC赋了初值，但综合后的FPGA没有相同的上电初始化机制。

解决：统一使用一个全局异步复位信号，所有时序逻辑都在negedge rst_n下清零。仿真时不要在initial里手动给PC赋值，而是使用复位信号驱动。如果实验平台是FPGA，还要检查复位按键是否做了消抖。我的习惯是复位释放后等几个时钟周期再让CPU开始取指，用一条FETCH_WAIT状态占住前两个周期，然后再进入正常取指。这样无论复位释放时序如何，第一条指令一定是RAM地址0的内容。

检查手段：在仿真的时间轴最开头，看复位信号释放前PC是否为0、IR是否为0、状态机是否处于FETCH。如果PC在复位释放后第一拍变成X或Z，就要查复位树的连线，是不是有的模块用了rst，有的用了rst_n，极性反了。

4.2 ALU运算结果没有寄存就下一条指令覆盖

现象：连续执行ADD指令，第一次算出的结果写到R0，紧接着第二次ADD使用的R0却还是旧值；波形里明明看到了ALU输出，但寄存器值更新晚了一拍。

原因：ALU是组合逻辑，输出变化很快；寄存器堆写使能RF_WE如果和ALU输出使能同时在T2拉高，那么数据必须在同一个时钟沿之前稳定。单总线模型里，寄存器堆的写入数据来自总线，而总线上的值只有在T3节拍才是ALU结果；如果RF_WE在T2就有效，寄存器写入的是无效值或旧值。

解决：把指令执行分成“结果产生”和“结果写回”两个节拍。T2让ALU对源操作数运算，T3把ALU输出送上总线且RF_WE拉高。还有一种做法是在ALU输出后面加一个缓冲寄存器，T2把结果暂存在缓冲里，T3将缓冲内容写入寄存器堆。这个缓冲寄存器是我认为最值得加的一个小模块，它能让你彻底摆脱总线时序的纠缠。注意：使用缓冲寄存器后，控制信号里需要多一个ALU_REG_EN，不要漏掉。

检查手段：在波形里把ALU输出、总线、RF_WE、寄存器R0的值放在同一组。看R0的变化是否发生在RF_WE有效的那个上升沿，而不是ALU输出翻转的瞬间。如果R0在一个非预期的沿变化，说明写控制信号时序错了。

4.3 存储器读写时序冲突：读出的数据总是慢半拍

现象：LOAD指令执行后，写入寄存器的数据不是当前RAM地址的内容，而是上一次访问该地址的值；或者同一段仿真代码，换一个RAM模型结果就不同。

原因：异步RAM和同步RAM的读时序完全不同。实验提供的模拟RAM模型常常是always @(posedge clk) begin if (rd) data_out <= mem[addr]; end，读使能有效后，数据输出要下一个时钟沿才更新。如果你在同一个节拍既给地址又读数据，组合逻辑读到的还是旧值。仿真时因为信号顺序问题可能看着是“对的”，实际上已经慢了一拍。

解决：查清实验PDF里RAM模型的读延迟参数。如果读延迟为1拍，就把“取指”定义为两个节拍：T0将PC地址送到RAM地址端口并拉高MEM_RD，T1将RAM数据输出采入IR。LOAD指令同理，地址送到RAM后需要多等一拍才能把数据写回寄存器。如果是FPGA工程，直接例化FPGA厂商的RAM IP，设置读延迟为1，避免用仿真模型上板后行为不一致。我见过的最严重一次，是仿真用了0延迟RAM，上板后所有LOAD结果偏移一两个字，排查了整整一天。

检查手段：看RAM的地址输入、读使能、数据输出三者的时序。如果数据输出在“读使能拉高后的下一个上升沿”才变化，说明读延迟为1拍；如果数据输出在读使能拉高后立即变化，说明是异步RAM。仿真前先确认这一点，比上板后猜要快得多。

4.4 控制信号默认值悬空：未闩锁的信号造成随机跳转

现象：仿真波形里出现大量高阻态Z或不定态X，状态机没有按设计跳转，PC偶尔变成不确定值。综合时还会报出“incomplete assignment creates a latch”警告。

原因：状态机代码的case没有写default分支，或者输出信号在always_comb里没有所有路径都被赋值。组合逻辑的锁存器或悬空输出在综合后被优化成奇怪电路；仿真时这些信号在未发生赋值时为X，进而传播到PC、状态寄存器。

解决：在always_comb块开头先给所有输出赋默认值，再用case覆盖特例。例如：

always_comb begin // 默认：所有控制信号无效，状态保持 next_state = state; ir_en = 1'b0; pc_en = 1'b0; rf_we = 1'b0; mem_rd = 1'b0; mem_wr = 1'b0; unique case (state) FETCH: begin ir_en = 1'b1; pc_en = 1'b1; mem_rd = 1'b1; end // 其他状态覆盖... endcase end

这个习惯能同时消掉仿真X态和综合锁存器警告。我早期写硬布线状态机时，经常漏给mem_wr赋值，导致STORE指令在波形里看着没有写存储器，其实就是因为默认分支里没赋0，信号一直保持上一个状态的值。

检查手段：在仿真波形里搜索Z和X。如果控制信号出现Z，说明三态门输出使能没拉高；如果出现X，说明组合逻辑的某个输入路径没被初始化。修复后，波形中所有控制信号都应该只出现0或1。

4.5 仿真波形“对了”但上板后不稳定：时钟振荡、毛刺与复位键抖动

现象：用仿真工具测试所有指令都正确，烧进FPGA后偶尔正确、偶尔跑飞；用按键作为CPU时钟时，按一下可能执行好几条指令。

原因：上板环境里时钟不是理想信号。按键作为时钟时，机械触点抖动会产生多个上升沿；组合逻辑产生的时钟信号会有毛刺；全局复位不是同步释放也会导致触发器无法初始化。

解决：CPU时钟统一由板载晶振经PLL生成，不要把按键直接接到CLK端口。如果实验要求单步执行，不应该用按键做时钟，而应该做一个“单步脉冲”，让按键信号经过两级触发器和边沿检测电路，只在按键释放瞬间产生一个宽度为系统时钟周期的脉冲。代码如下：

logic key_r1, key_r2, key_pulse; // 两级触发器同步异步按键信号，消除亚稳态 always_ff @(posedge clk) begin key_r1 <= key_in; // key_in是原始按键信号 key_r2 <= key_r1; end // 边沿检测：检测到按键按下沿，产生一个时钟周期的脉冲 assign key_pulse = key_r1 & ~key_r2;

把这个脉冲作为CPU时钟使能（clk_en），而不是作为时钟接入。这样CPU的always_ff仍然由统一时钟驱动，但只在clk_en=1时改变状态，可以从根本上消除按键抖动。另一个常见隐患是组合逻辑产生的时钟，比如用比较器输出直接驱动CLK。这种电路在仿真里很整齐，但上板后的门级延迟会制造毛刺，必须改成同步时钟使能方案。

检查手段：用示波器或逻辑分析仪看真实时钟信号，确认没有负毛刺；单步按键测试时，连续按10次，观察PC是否每次都只前进一步。如果有一次跳两步，说明按键抖动没消除。

5. 让模型机真正被验证：单步调试、指令回归与后续扩展

模型机写完后，不要急着把程序烧进去炫成果，先用一种可靠的验证方法：指令回归。我把每条指令的执行结果和黄金参考模型比对，而不是只看单条指令波形。具体做法是写一段测试程序，覆盖所有指令和边界情况。下面是我常用的一段测试序列，用于快速验证ADD、MOVI和JMP：

# 假汇编：假设R0=0，R1=2，R2=3 MOVI R0, 0 # 0: 0x7000 MOVI R1, 2 # 1: 0x7102 MOVI R2, 3 # 2: 0x7203 ADD R0, R1, R2 # 3: 0x0012 JMP 6 # 4: 0x8006 HLT # 5: 0xA000 # 6: 这里放结果

用仿真工具跑完之后，检查R0是否等于5、是否停在了地址6。这一步看起来基础，但能筛掉一大半总线冲突问题。进阶手法是把这段汇编转成机器码，再用脚本在模型机上跑随机指令序列，每个序列都从复位开始，最后把寄存器堆和内存快照与行为模型比对。如果全对，就说明数据通路的控制时序基本没有竞态。

调试习惯上，我一般会加一个单步使能端口，用前面提到的按键脉冲实现单步执行。在单步模式下，每个时钟沿只执行一个节拍，逐拍查看状态寄存器和总线值。不要全速跑波形，全速跑只能看到结果错了，根本看不到错在哪个节拍。养成这个习惯后，我很少再熬夜找X态。

后续扩展可以从两个方向走：一是加指令，比如加入移位指令，需要扩展操作码和ALU控制；二是加寻址模式，把LOAD/STORE的8位地址改成基址寻址，让指令多一个寄存器字段。这些都需要回到第2章的图纸去改格式、改总线分配、改控制信号，从正面倒逼你理解指令集扩展的代价。

我每次都遵循一个原则：一次只改一个模块，改完立刻跑回归；哪怕只是把ALU加了一个操作码，也要全量跑一遍所有旧指令。有一回我急着演示，把控制器改成微程序后没跑回归，结果所有跳转指令都偏了一拍，现场翻车。自此我习惯先写好回归脚本，再动代码。模型的验证一致性，比你临时加多少条指令都重要。希望这些方法对你有用，希望帮到你。

本文还有配套的精品资源，点击获取