简介：这份资源面向计算机组成原理课程学习者与备考北航相关课程的学生，系统整理了从P0到P6各阶段的实验成果，覆盖数字逻辑电路设计、汇编语言编程与CPU实现三大方向。包内共441个文件，以Verilog源码（.v）、Logisim电路（.circ）、Mars汇编（.asm）及C语言源文件为主，辅以工程配置、仿真数据与文档说明，压缩包约10.17MB，按实验阶段分目录组织，便于对照检索。内容上既有用Logisim搭建的斐波那契数列电路、Moore与Mealy型有限状态机及单周期CPU，也有基于Verilog的单周期与多周期流水线CPU实现，还包括Mars平台下的哈密顿回路、循环递归、矩阵转化等汇编题目代码，可帮助读者理解从逻辑门到流水线CPU的完整设计链路，并对照参考实现排查自身电路与代码问题。目前已有3507人学习下载，适合需要系统梳理组成原理实验、查漏补缺的中高年级学生参考。
1. 从一根导线到一个能跑程序的 CPU：为什么“搭出来”和“讲清楚”是两回事
很多人第一次接触计算机组成，是从一张 Logisim 电路图开始的：几根导线、几个与或门、一个寄存器，拼出一个加法器，仿真跑通，灯亮了，就以为懂了。可一旦把时钟频率调高、把指令条数堆上去，电路开始出现莫名其妙的时序错乱，或者 MIPS 汇编在 Mars 里跑得好好的，搬进自己搭的 CPU 就卡死——这时候才发现，之前那点“跑通”只是把黑匣子换了个壳。这份围绕 Logisim、ISE&Verilog、Mars 汇编和 CPU 流水线展开的组成原理实践资源，真正想解决的不是“画出一个能亮的电路”，而是让你把从门电路到指令执行这条链路，每一层为什么这么设计、数据怎么流动、时序卡在哪，全部讲得出来。搞懂它，你面对的不再是玄学般的仿真失败，而是能定位到具体某一级的握手信号。
2. 单周期 CPU：一条指令走完全程，为什么反而最难调
单周期是组成原理里最“直觉”的模型：取指、译码、执行、访存、写回，五个阶段在一个时钟周期内串行走完。看起来简单，但它恰恰是后面所有坑的源头。理解单周期，重点不在“能跑”，而在看清每条指令对数据通路提出的具体要求，以及为什么这种“一周期一指令”的假设在真实频率下站不住。
2.1 数据通路的本质：一条指令就是一次对寄存器和存储器的读写编排
把 CPU 拆到最底层，它做的事只有一件：根据指令里的操作码，决定这一拍里哪些多路选择器导通、哪些寄存器允许写入、ALU 做哪种运算。以一条典型的 R 型加法指令为例，它的执行路径是：PC 给出地址 → 指令存储器取出 32 位指令 → 译码器拆出 rs、rt、rd 和 funct → 寄存器堆读出两个源操作数 → ALU 按 funct 做加法 → 结果写回 rd。整条链路上，任何一个控制信号给错，结果就是错的，而且往往错得很隐蔽。
常见的实现思路是把控制单元做成一张真值表：输入是指令的 opcode 和 funct 字段，输出是 RegWrite、MemRead、MemWrite、ALUSrc、PCSrc 等一组控制信号。这张表就是单周期 CPU 的“大脑”，它的每一行都对应一类指令。下面这段伪代码展示了控制信号是如何从指令字段推导出来的，注意注释里标出的每个信号对应的硬件动作：
// 控制单元核心逻辑：根据 opcode 生成各部件使能信号 always @(*) begin case (opcode) 6'b000000: begin // R 型指令 RegDst = 1'b1; // 写回目标选 rd 而非 rt ALUSrc = 1'b0; // ALU 第二操作数来自寄存器 MemtoReg = 1'b0; // 写回数据来自 ALU 结果 RegWrite = 1'b1; // 允许写寄存器堆 MemRead = 1'b0; MemWrite = 1'b0; ALUOp = 2'b10; // 交给 ALU 按 funct 细分 end 6'b100011: begin // lw 加载指令 RegDst = 1'b0; // 写回目标选 rt ALUSrc = 1'b1; // ALU 第二操作数来自立即数 MemtoReg = 1'b1; // 写回数据来自存储器 RegWrite = 1'b1; MemRead = 1'b1; // 触发数据存储器读 MemWrite = 1'b0; ALUOp = 2'b00; // ALU 做加法算地址 end // sw、beq、j 等其余指令分支略 endcase end这段逻辑的关键在于：RegDst 决定“写哪个寄存器”，ALUSrc 决定“ALU 的第二个操作数从哪来”，MemtoReg 决定“写回的数据是 ALU 结果还是内存读出的值”。三个多路选择器各管一件事，任何一个翻转，整条指令的语义就变了。参数上，ALUOp 是给 ALU 的粗粒度提示，真正的运算类型还要结合 funct 字段二次译码，这种“两级译码”是单周期设计的典型做法。
2.2 为什么单周期在真实频率下必然翻车：关键路径决定时钟周期
单周期 CPU 的时钟周期必须大于等于整条指令最长的那条组合逻辑路径，也就是关键路径。取指要过指令存储器，译码要过寄存器堆，执行要过 ALU，访存要过数据存储器，写回还要过寄存器堆的建立时间。把这些延迟加起来，时钟周期被拉得很长，频率上不去。更麻烦的是，每条指令都按最长路径来定周期，短指令白白浪费了大量时间。
这就引出一个设计取舍：单周期用“硬件简单”换“频率极低”。它的价值在于教学——数据通路一目了然，控制信号和指令语义一一对应，适合建立第一层认知。但一旦你想让它跑得更快，就必须把一条指令拆成多个周期，让不同指令的不同阶段重叠起来，这就是流水线的动机。理解单周期的关键路径，是理解流水线为什么能提速的前提：流水线不是让单条指令变快，而是让多条指令的阶段并行，从而提高单位时间完成的指令数。
2.3 用 Mars 汇编验证数据通路：每条指令都是一次可观测的状态迁移
在 Mars 里写一段汇编，单步执行，观察寄存器和内存的变化，是验证数据通路最直接的手段。比如下面这段代码，它把两个数相加后存回内存，每一步都对应数据通路上的一次状态迁移：
# 模拟项目X：验证 lw/add/sw 三段数据通路 lw $t0, 0($zero) # 从地址 0 加载第一个操作数到 $t0 lw $t1, 4($zero) # 从地址 4 加载第二个操作数到 $t1 add $t2, $t0, $t1 # ALU 执行加法，结果写入 $t2 sw $t2, 8($zero) # 把 $t2 写回地址 8单步执行时，lw 指令会让 MemRead 有效、MemtoReg 选通存储器输出；add 指令会让 ALUSrc 选寄存器、RegDst 选 rd；sw 指令则让 MemWrite 有效、RegWrite 无效。把 Mars 里每条指令执行后的寄存器快照，和你 Logisim 电路里对应时刻的寄存器值对照，就能定位到底是哪个控制信号给错了。这种“软件侧观测 + 硬件侧对照”的方法，比单纯看波形图高效得多，也是排查单周期问题的血泪经验。
3. 流水线：把一条指令拆成五段，冲突就从这里开始
流水线的核心思想是把指令执行拆成五个阶段，每个阶段用独立的硬件资源，让不同指令的不同阶段在同一拍里并行。理想情况下，每个时钟周期都能完成一条指令，吞吐率提升接近五倍。但理想归理想，真实流水线里，数据冲突、控制冲突、结构冲突会轮番上阵，把这条“流水”搅得七零八落。理解流水线，重点不是画出一张五级流水图，而是搞清每一类冲突的成因，以及前递、停顿、分支预测这些机制分别在哪一层兜底。
3.1 五级流水的阶段划分与流水寄存器：每一拍都在搬运“半成品”
经典五级流水把指令执行分为 IF（取指）、ID（译码）、EX（执行）、MEM（访存）、WB（写回）。相邻阶段之间用流水寄存器隔开，每一拍把当前阶段的输出锁存进寄存器，供下一拍的下一个阶段使用。这些流水寄存器里存的不只是数据，还有控制信号——这一点常被忽略。控制信号必须跟着指令一起往后流，否则到了 EX 阶段就不知道该让 ALU 做什么运算。
常见的实现思路是：IF/ID 寄存器保存 PC 和取出的指令；ID/EX 寄存器保存两个源操作数、立即数、目标寄存器编号，以及从控制单元译出的全部控制信号；EX/MEM 保存 ALU 结果、写回目标编号、分支判断结果；MEM/WB 保存访存读出的数据和写回目标编号。每一级只关心自己需要的字段，其余字段原样透传。这种“控制信号随指令流动”的设计，是流水线能正确工作的基础，也是新手最容易漏掉的地方——只搬数据不搬控制，到了后面阶段就是一堆无头苍蝇。
3.2 数据冲突与前递：为什么刚算出来的结果下一拍就能用
数据冲突的典型场景是：一条指令要用的操作数，正好是前一条指令还没写回的结果。比如add $t2, $t0, $t1紧接着sub $t3, $t2, $t4，sub 在 EX 阶段需要 $t2，但 add 的结果要到 WB 阶段才写回寄存器堆。如果什么都不做，sub 读到的就是旧值。
解决办法有两种：停顿和前递。停顿是让流水线等一拍，简单但损失性能；前递是把 EX/MEM 或 MEM/WB 阶段的结果直接旁路到 ALU 的输入端，不等写回。前递的判断逻辑是：比较当前 EX 阶段指令的源寄存器编号，和 EX/MEM、MEM/WB 阶段指令的目标寄存器编号，如果相等且目标寄存器不是 $zero，就选通对应的旁路数据。下面这段逻辑展示了前递单元的核心判断：
// 前递单元：判断 EX 阶段的操作数是否需要从后续阶段旁路 always @(*) begin ForwardA = 2'b00; // 默认用寄存器堆读出的值 ForwardB = 2'b00; // EX 冒险：上一条指令在 EX/MEM 阶段，结果还没写回 if (EX_MEM_RegWrite && (EX_MEM_WriteReg != 0) && (EX_MEM_WriteReg == ID_EX_Rs)) ForwardA = 2'b10; // 选 EX/MEM 的 ALU 结果 // MEM 冒险：上上条指令在 MEM/WB 阶段 if (MEM_WB_RegWrite && (MEM_WB_WriteReg != 0) && (MEM_WB_WriteReg == ID_EX_Rs)) ForwardA = 2'b01; // 选 MEM/WB 的写回数据 // ForwardB 对 Rt 做同样判断，略 end这里的关键参数是 ForwardA 和 ForwardB 的编码：00 表示用寄存器堆的值，01 表示用 MEM/WB 阶段的数据，10 表示用 EX/MEM 阶段的数据。优先级上，EX/MEM 的旁路优先于 MEM/WB，因为它是更“新”的结果。注意!= 0的判断不能省，$zero 寄存器永远读 0，不能被前递覆盖，否则整个程序的零值语义就崩了。
3.3 控制冲突与分支：为什么一条 beq 会让流水线“打个嗝”
控制冲突来自分支指令：beq 要在 EX 阶段才能算出是否跳转，但此时 IF 阶段已经取进了后面两条指令。如果分支成立，这两条指令就得作废，流水线出现气泡。最简单的处理是停顿，等分支结果出来再取指，代价是每次分支损失两拍。更好的做法是分支预测，猜一个方向先取指，猜错了再冲刷。
常见的实现思路有两种：静态预测（比如总是预测不跳转）和动态预测（用历史记录表）。在教学级流水线里，静态预测加冲刷已经够用。冲刷的实现是：当 EX 阶段判定分支成立时，把 IF/ID 和 ID/EX 寄存器里的控制信号清零，让这两条指令变成空操作，同时把 PC 改成分支目标地址。这里有个容易翻车的细节：冲刷信号和正常写使能之间的优先级必须理清，否则会出现“该清的没清、该留的被清”的时序错乱。
3.4 结构冲突：存储器只有一个端口时，取指和访存会打架
结构冲突是硬件资源不够用导致的。最典型的是指令存储器和数据存储器如果共用同一个单端口存储器，IF 阶段取指和 MEM 阶段访存就会在同一拍争抢端口。解决办法是把指令和数据存储器分开（哈佛结构），或者用双端口存储器。在 Logisim 里搭流水线时，这个坑几乎人人都会踩：单周期时取指和访存不在同一拍，看不出问题；一上流水线，两条指令同时要访问存储器，仿真直接卡住。排查时先看存储器端口占用，往往比看波形更快定位。
4. 从 Logisim 到 Verilog：同一套逻辑，两种表达方式的取舍
Logisim 用图形化连线表达电路，Verilog 用代码描述硬件行为，两者描述的是同一套逻辑，但思维方式差别很大。Logisim 逼你直面每一根导线和每一个门延迟，适合建立“信号怎么流”的直觉；Verilog 让你用 always 块和赋值语句描述并发行为，适合规模化设计和仿真验证。把同一套 CPU 在两种工具里各实现一遍，是理解“硬件描述语言到底在描述什么”的最好方式。
4.1 Logisim 的连线思维：每个引脚都是一次显式的数据搬运
在 Logisim 里搭数据通路，你必须明确每个部件的输入输出引脚接到哪里，多路选择器的选择端由哪个控制信号驱动，寄存器的时钟和复位怎么接。这种“一根线一根线连”的过程很笨拙，但它强迫你想清楚每个信号的来源和去向。比如寄存器堆的写使能，你必须从控制单元拉一根线过来，中间不能有任何含糊。这种显式性，恰恰是理解数据通路的最好训练。
但 Logisim 的局限也很明显：电路一大，连线就变成一团乱麻，改一处逻辑要动好几根线，调试只能靠探针和波形。它适合小规模、教学级的验证，不适合复杂设计。常见的做法是：先用 Logisim 把单周期跑通，建立直觉，再迁移到 Verilog 做流水线和扩展指令。
4.2 Verilog 的并发语义：always 块不是顺序执行，而是硬件并行
Verilog 最容易让人翻车的地方，是把 always 块当成软件里的顺序代码来写。实际上，多个 always 块之间是并发的，块内的非阻塞赋值（<=）在时钟沿同时更新，阻塞赋值（=）则在块内顺序执行。组合逻辑用 always @(*) 加阻塞赋值，时序逻辑用 always @(posedge clk) 加非阻塞赋值，这是基本纪律。违反它，仿真结果和综合结果可能不一致，这种 bug 极难排查。
下面这段代码展示了一个带同步复位的寄存器堆写端口，注意非阻塞赋值和时钟沿的配合：
// 寄存器堆写端口：时钟上升沿写入，同步复位清零 always @(posedge clk) begin if (reset) begin // 复位时清空所有寄存器，注意 $zero 始终保持 0 for (i = 1; i < 32; i = i + 1) regs[i] <= 32'b0; end else if (RegWrite) begin // 写使能有效且目标不是 $zero 时才写入 if (WriteReg != 5'b0) regs[WriteReg] <= WriteData; end end参数说明：RegWrite 来自控制单元，WriteReg 是目标寄存器编号，WriteData 是写回数据。$zero寄存器（编号 0）被排除在写入之外，保证它永远读 0。这里用非阻塞赋值，是因为寄存器堆的写入是时序行为，必须在时钟沿统一更新，避免同一拍内读写互相干扰。如果用阻塞赋值，仿真时可能出现“刚写入就能读到”的假象，和真实硬件行为不符。
4.3 仿真与上板之间：那些只在真实时序里才暴露的问题
仿真通过不等于上板能跑。仿真器默认零延迟，信号瞬间传播；真实硬件有门延迟、布线延迟、建立保持时间。流水线里的前递和冲刷逻辑，在仿真里可能因为信号同时到达而“碰巧正确”，上板后由于延迟差异，旁路数据晚到一拍，结果就错了。常见的排查手段是加时序约束、看关键路径的建立时间余量，或者在仿真里人为加延迟来复现问题。这类问题没有捷径，只能靠波形和约束一点点抠。
5. 避坑与排查：那些让仿真卡死、上板翻车的具体记录
组成原理实践里的坑，大多不是“不会”，而是“以为对了其实错了”。下面几条是高频翻车点，每条都按现象、原因、解决来拆，方便对照排查。
5.1 现象：Mars 里跑通的汇编，搬进 CPU 后结果全错
原因通常是汇编里用了 CPU 未实现的指令，或者指令格式的字段解析和 Mars 的约定不一致。比如 Mars 默认的伪指令展开、寄存器编号约定，和你自己译码器里的假设对不上。解决方法是先用最基础的 R 型、I 型指令写测试用例，逐条对照 Mars 的单步执行结果和电路里的寄存器值，确认字段解析一致后再上复杂程序。
5.2 现象：流水线仿真时，某些指令的结果偶尔正确偶尔错误
原因多半是前递优先级写反了，或者漏掉了$zero的判断。EX/MEM 的旁路必须优先于 MEM/WB，否则会用旧结果覆盖新结果；$zero不参与前递，否则零值语义被破坏。解决方法是把前递条件写成独立的组合逻辑，用测试用例覆盖“连续三条指令依赖同一寄存器”的场景，观察每一拍 ALU 输入是否正确。
5.3 现象：分支指令后紧跟的指令被执行了，但本不该执行
原因是冲刷逻辑没生效，或者冲刷信号和流水寄存器的写使能优先级冲突。分支成立时，IF/ID 和 ID/EX 的控制信号必须清零，同时 PC 要改成目标地址。如果冲刷信号被正常的写使能覆盖，气泡就没插进去。解决方法是把冲刷信号放在写使能判断的最外层，确保它优先级最高，并用波形确认分支成立那一拍，后续两级流水寄存器的控制字段确实变成了空操作。
5.4 现象：Logisim 电路连线一多就出现红色错误，仿真无法继续
原因通常是多驱动冲突：同一根导线被两个输出引脚驱动，或者组合逻辑出现了环路。Logisim 对多驱动是零容忍的。解决方法是逐个检查报错导线的驱动源，确认每个网络只有一个驱动；对于组合环路，检查是不是把某个部件的输出又接回了自己的输入而没有经过寄存器。这类问题在单周期里少见，一上流水线、前递路径一多就容易冒出来。
5.5 现象：Verilog 仿真结果和综合后上板行为不一致
原因是阻塞赋值和非阻塞赋值混用，或者组合逻辑里用了非阻塞赋值。仿真器对这两种情况的处理有差异，综合工具又按另一套规则推断硬件。解决方法是严格遵守纪律：时序逻辑用非阻塞，组合逻辑用阻塞，always @(*) 里不写非阻塞赋值。改完后重新跑仿真，并检查综合报告里的锁存器推断警告，有意外锁存器往往就是组合逻辑没写全。
6. 设计取舍：为什么教学级 CPU 要在“正确”和“简单”之间反复横跳
把单周期、流水线、Verilog 实现都走一遍之后，最值得回味的不是某个模块怎么写，而是每一个设计决策背后的取舍。单周期用极低的频率换来了数据通路的直观；流水线用冲突处理的复杂度换来了吞吐率；前递用额外的旁路逻辑换来了少停顿；静态分支预测用可能的冲刷换来了取指不断流。这些取舍没有绝对的对错，只有“在当前约束下是否合理”。
一个具体的例子是前递和停顿的边界。理论上，所有数据冲突都能靠停顿解决，电路简单，但性能损失大；全用前递，电路复杂，且 load-use 冲突仍然躲不掉，必须停顿一拍。教学级实现通常选择“前递为主、load-use 停顿兜底”，这是在复杂度和性能之间找的平衡点。再比如存储器端口，哈佛结构避免了结构冲突，但增加了硬件面积；单端口加仲裁能省面积，但控制逻辑更绕。这些选择在真实处理器里会被反复权衡，教学级 CPU 只是把权衡过程压缩到了一个你能完整看完的规模里。
验证这些取舍是否合理，最直接的方法是构造针对性测试：连续依赖指令测前递，密集分支测预测和冲刷，load 后立即使用测停顿。把每种场景下的周期数和正确性都记录下来，你就能看到每个机制到底值不值。我一般会这么理解：组成原理的实践，最终练的不是“搭出一个 CPU”，而是“面对一个错误结果，能沿着数据通路和时序一层层定位到根因”的能力。从那以后我每次改完流水线控制逻辑，都会强制走一遍“单步对照 Mars + 波形看关键信号 + 构造边界用例”这三步，少一步就可能留下一个只在特定指令序列下才触发的坑。希望帮到你。
本文还有配套的精品资源，点击获取
