基于原始微代码的CPU重建：z386项目的工程方法论

引言：从硅片到 RTL 的硬件考古

2026 年初，一个名为 z386 的开源项目引起了复古计算与硬件设计社区的关注。该项目并非简单的指令级模拟器，而是基于从真实 Intel 80386 硅片中提取的原始微代码 ROM，在 FPGA 上重建了一个可运行 DOS 和 Doom 的完整 CPU 实现。这一工作代表了硬件逆向工程领域的重要进展 —— 它证明了通过微代码层面的考古，可以复现经典处理器的内部架构，而无需依赖行为级建模。

z386 的核心创新在于方法论：传统的 CPU 实现通常采用 "指令→RTL" 的直接映射，开发者根据 ISA 手册手写每个指令的硬件行为。而 z386 选择了另一条路径 —— 先恢复原始微代码，再重建微代码所期望的硬件环境。这种 "微代码驱动" 的方法不仅保留了历史架构的原始语义，也为理解复杂处理器的设计决策提供了独特视角。

微代码逆向：从位流到控制程序

80386 的微代码提取工作由 reenigne 等人完成，他们通过高分辨率芯片显微照片，从硅片物理层恢复了 37 位宽、共 2560 条目的控制 ROM。这一过程涉及位流提取、PLA 结构分析和指令映射重建。与 8086 微代码的 "类 C 程序" 风格不同，386 微代码更接近手工优化的汇编 —— 短小、微妙，且充满对隐藏硬件的隐式假设。

微代码在 z386 中充当主控制程序。每条微指令定义了内部数据通路的选择、ALU 操作、内存周期触发、序列器跳转逻辑等。RTL 层不再直接实现ADD或IRET等行为，而是实现微代码期望操控的底层硬件。这种分层架构使得复杂的 x86 指令集可以通过相对紧凑的微代码 ROM 来驱动，而非庞大的硬连线状态机。

八单元架构与微代码序列器

z386 遵循 80386 的原始八单元组织：预取单元维护 16 字节代码队列；解码器处理变长指令结构，生成 111 位解码指令字；微代码序列器从 ROM 获取扩展微操作并处理跳转和延迟槽；ALU 与移位器执行算术逻辑运算；分段单元计算线性地址；保护单元实现特权检查；分页单元管理 TLB 和页表遍历；BIU/cache 负责内存访问。

微代码序列器的设计体现了 386 架构的复杂性。每条微指令执行需要至少两个周期 —— 第一个周期选择源寄存器并通过 ALU 传递，第二个周期将结果写入目标寄存器。跳转和分支也存在延迟槽机制：分支指令后的微操作总会执行。保护 PLA 的测试结果需要三个周期才能反馈到序列器，这意味着在特权检查生效前可能已执行若干微操作。这些时序特性并非缺陷，而是原始设计者为性能与面积做出的权衡。

缓存与内存子系统的工程权衡

原始 80386 片内无 L1 缓存，依赖外部缓存控制器。z386 为提升 FPGA 上的实用性，添加了 16KB 4 路组相联统一缓存，采用 VIPT（虚拟索引物理标记）查找策略。这种设计允许在地址翻译完成前启动缓存预读，将命中延迟降至接近零等待状态。

缓存参数的选择反映了 FPGA 实现的约束：16KB 容量由 VIPT 索引必须在 4KB 页偏移内的要求决定；写直通策略配合双条目写缓冲平衡了复杂性与性能；16 字节行大小与 SDRAM 突发传输对齐。实测表明，该缓存有效降低了指令预取与数据访问之间的总线竞争，使 z386 在 85MHz 时钟下达到相当于 70MHz 原始 386 的性能水平。

验证策略：从单步测试到 Doom

z386 的验证采用分层策略。底层使用 SingleStepTests/80386 进行单指令模糊测试，对比寄存器、标志位、内存和异常行为。保护模式测试则借助 86Box 作为参考，覆盖IRET、LAR、调用门、页故障等场景。手工编写的测试程序验证跨特权调用、中断门、VM86 转换等复杂交互。

集成测试阶段，SeaBIOS 提供可调试的启动路径，FreeDOS 和 MS-DOS 6/7 验证实模式兼容性，DOS/4GW 和 DOS/32A 扩展器测试保护模式环境，最终 Doom 和 3DBench 成为完整的系统级压力测试。值得注意的是，DOS 扩展器的调试耗时最长 ——DOS/4GW 的保护模式初始化代码花了约两周的追踪和反汇编才通过，这揭示了 BIOS、内存管理器和应用程序之间隐式的硬件契约依赖。

技术启示与可复现路径

z386 项目展示了微代码作为 "架构契约" 的独特价值。微代码虽非门级电路图，但它精确记录了硬件被设计来完成的功能。内部寄存器命名、可复用子程序结构、隐式的硬件假设 —— 这些在微代码中都有体现。当某个简洁的微操作名称映射到具体行为时，正确实现它就像是解开原始架构的另一层谜题。

对于希望复现类似工作的工程师，可落地的技术路径包括：首先获取目标处理器的微代码 ROM（通过芯片逆向或社区资源）；分析微指令格式，重建控制字段语义；设计数据通路以支持微代码期望的操作；实现解码逻辑将 x86 指令映射到微代码入口；构建分层测试框架从单指令验证到完整系统启动；最后通过真实软件负载进行压力测试。

局限与展望

当前 z386 仍存在未覆盖的领域：Windows 尚未能启动，部分保护模式特性实现不完整，某些 PLA 控制线仍未完全理解。此外，由于 CPI（每指令周期数）高于原始 386，z386 需要依赖更高的时钟频率来补偿性能。这些局限也指明了后续工作的方向 —— 继续完善微代码语义分析，优化关键路径时序，扩展保护模式测试覆盖。

z386 的意义超越了复古计算本身。它证明了在现代 FPGA 平台上，通过严谨的逆向工程和 RTL 重建，可以复活经典架构的完整语义。对于计算机体系结构教育、硬件安全研究和数字遗产保护，这种 "微代码驱动" 的方法论都提供了可复用的工程范式。

资料来源

• z386 项目主页: https://nand2mario.github.io/posts/2026/z386/
• reenigne 的 8086 微代码反汇编: https://www.reenigne.org/blog/8086-microcode-disassembled/

systems