基于picoRV32的RISC-V SoC软硬协同实战：从Vivado到PYNQ-Z2

简介：这份《硬件结构设计》综合实验报告面向计算机组成原理、嵌入式系统与FPGA开发方向的学习者，围绕开源RISC-V核picoRV32展开，讲解如何在PYNQ-Z2开发板上搭建完整SoC并完成软硬件协同编程。报告完整覆盖嵌入式系统设计流程、硬件方案与软件方案，涉及IP核包装、AXI总线互联、比特流生成、oDisk解压与RISC-V功能验证等关键环节，并附有运行结果分析与实验心得。资源包为1个docx文档，共29页，压缩包约3.01MB，目录结构清晰，按实验说明、设计方案、结果分析、心得四部分组织，便于按模块查阅。目前已有1582人学习下载。读者可借此掌握RISC-V架构特性、SoC设计基本流程与FPGA开发方法，理解硬件设计与软件编程的协作关系，适合作为课程实验参考与工程实践入门材料。

1. 从一块板子到一颗核：我为什么死磕 picoRV32 搭 SoC

第一次把 picoRV32 的 bitstream 烧进 PYNQ-Z2，串口吐出一行 “Hello RISC-V” 的时候，我盯着 Jupyter Notebook 里那个绿框愣了好几秒。不是因为激动，是因为前一周我还在怀疑这条路走不通——网上关于 RISC-V-On-PYNQ 的资料散得像碎玻璃，实验报告模板又全是“实验目的、实验原理、实验步骤”的八股，真正卡人的地方一句不提。后来我带着两个同学把《硬件结构设计》这份 29 页的综合实验从头到尾复现了一遍，从 Vivado 里包 IP 核，到 oDisk 解压覆盖文件，再到云平台上跑通第一个 C 程序，中间翻的车足够写一本小册子。这篇就把我们踩过的坑、验证过的流程、以及“为什么这么设计”的判断依据摊开讲。如果你也在做 RISC-V 相关的硬件结构设计实验，或者想找一个能跑通软硬协同的最小 SoC 案例，下面这些内容应该能帮你省下至少三个通宵。

2. 选型先看核：picoRV32 凭什么适合教学级 SoC

2.1 三种配置摆在一起，面积和功能怎么权衡

picoRV32 最讨喜的地方是它把“可配置”做得很直白。同一个核，通过参数就能在 RV32E、RV32I、RV32IC、RV32IM、RV32IMC 之间切换，还能决定要不要中断控制器、要不要桶形移位器、要不要压缩指令。实验报告里列了三个典型配置，我把它整理成一张对比表，方便你直接对着选：

这张表里的数字不是让你去精确复现，而是给你一个量级感。我们当时在 PYNQ-Z2 上跑的是 regular 配置，因为要验证 C 程序里的乘法和除法，但又不想让综合时间爆炸。如果你只是做取指通路的波形观察，small 配置就够，综合能快一倍。

2.2 内存接口和 PCPI：软硬协同的两个关键口子

picoRV32 的原生内存接口非常“裸”，信号就那几个：mem_valid、mem_instr、mem_ready、mem_addr、mem_wdata、mem_wstrb、mem_rdata。读传输时mem_wstrb为 0，mem_wdata不用；写传输时mem_wstrb有效，mem_ready拉高即确认。它不强制等待周期，你可以把mem_ready绑成常数 1 做异步读，也可以自己加状态机做同步。这种“不替你决定”的风格，在教学实验里反而是好事——你能亲眼看到总线握手到底在干什么。

另一个口子是 PCPI（Pico 协处理器接口）。当核遇到不支持的指令且 PCPI 使能时，pcpi_valid拉高，指令字和 rs1/rs2 的值直接吐出来，外部协处理器可以自己解码执行，完成后拉pcpi_ready，需要多周期就先拉pcpi_wait。16 个时钟周期内没响应就触发非法指令异常。这个机制给了你一个“外挂”自定义指令的入口，做硬件结构设计实验时，如果想加个简单的加速器，从 PCPI 下手比改核内部要干净得多。

2.3 和 Zynq-7000 的 PS 怎么分工

PYNQ-Z2 上的 Zynq-7000 把 PS（双核 ARM Cortex-A9）和 PL（FPGA）集成在一颗芯片里。我们的 SoC 实验里，picoRV32 是放在 PL 里的软核，PS 跑 Linux 和 Jupyter Notebook，负责编译、加载 bitstream、通过 AXI 和 PL 通信。这种分工的好处是：你不需要给 picoRV32 配一套完整的操作系统，编译好的 RISC-V 二进制通过 PS 侧的文件系统喂进去就行。PS 侧有 512KB L2 Cache、256KB OCM、DDR 控制器，PL 侧只负责算。实验报告里把 PS 的 APU、Memory interfaces、IOP、Interconnect 四块拆得很细，但落到操作上，你只需要关心两件事：Overlay 怎么加载，以及二进制文件怎么放。

3. 从 Vivado 到 Jupyter：一条能跑通的完整链路

3.1 模块设置与 IP 核包装的实操细节

在 Vivado 里把 picoRV32 包装成 IP 核，最容易翻车的地方是时钟和复位。picoRV32 本身对时钟频率不挑，但 AXI 互联和 PYNQ 的 Overlay 框架对时钟有要求。我们当时的做法是：给 picoRV32 单独一个时钟域，通过 Clocking Wizard 生成，频率先设 50MHz，综合通过后再往上试。复位用 Processor System Reset 模块，把 PS 侧的复位信号同步过来。

IP 核包装时，接口类型选 AXI4-Lite 还是原生内存接口，取决于你要不要挂到 PS 的 AXI 总线上。如果只是做独立 SoC 验证，原生接口更简单；如果要和 PS 交互，就得用picorv32_axi变体，它自带 AXI-4 Lite Master 接口。我们两种都试过，原生接口的波形干净，AXI 接口的调试信息多但容易在握手阶段卡住。

3.2 连接 IP 与生成文件：别在最后一步省时间

把 picoRV32 的 IP 和其他组件（BRAM、GPIO、UART）连起来之后，生成 bitstream 之前一定要跑一遍综合后的时序报告。我们第一次跑的时候没看，结果mem_ready路径上组合逻辑太长，时序违例，烧进去之后程序跑飞。后来在mem_ready前插了一级寄存器，问题解决。

生成文件时，Vivado 会输出.bit和.hwh两个文件。.bit是 bitstream，.hwh是硬件描述文件，PYNQ 的 Overlay 类靠它来解析 IP 地址映射。这两个文件必须一起放到 PYNQ-Z2 的文件系统里，缺一个都会在Overlay("xxx.bit")那一步报错。

3.3 oDisk 解压与文件放置：路径不对，全盘白费

实验报告里提到的 oDisk 解压，本质上是把生成的 Overlay 文件包解压到 PYNQ 的指定目录。PYNQ 的 Jupyter Notebook 默认工作目录是/home/xilinx/jupyter_notebooks，但 Overlay 文件通常放在/home/xilinx/pynq/overlays下。我们当时的做法是：在 Jupyter 里新建一个 notebook，用!unzip命令解压 oDisk 包，然后把.bit和.hwh复制到 overlays 目录，再在 Python 里用绝对路径加载。

这里有个坑：PYNQ 的 Overlay 加载对文件名大小写敏感。我们有一次把picoRV32.bit写成了picorv32.bit，结果报 “File not found”，查了半小时才发现是大小写问题。

3.4 在 PYNQ-Z2 上验证 RISC-V 是否可用

验证环节我们分了三步走。第一步，用 RISC-V 工具链编译一个最简单的汇编程序，只做寄存器加法和跳转，把二进制通过dd命令写入 BRAM 的地址空间，然后在 Jupyter 里读回 BRAM 内容，确认写入成功。第二步，编译一个 C 程序，调用printf通过 UART 输出，确认指令流和数据流都通。第三步，跑一个带循环和乘法的程序，确认 MUL 指令在 regular 配置下正常工作。

每一步的验证结果都记录在实验报告里，但报告里没写的是：第二步我们卡了最久，因为 UART 的波特率在 PL 侧和 PS 侧没对齐，输出全是乱码。后来把两边的波特率都设成 115200，问题消失。

4. 避坑记录：五个让我们重跑实验的瞬间

4.1 现象：Overlay 加载成功但 IP 无响应

原因：.hwh文件里的地址映射和实际 IP 核的 AXI 地址不一致。Vivado 在生成 IP 核时会自动分配地址，但如果你手动改过 Address Editor，.hwh可能没更新。

解决：在 Vivado 里重新跑一遍 “Validate Design”，确认 Address Editor 没有冲突，然后重新生成.hwh文件。加载 Overlay 后，用overlay_design.ip_dict打印所有 IP 的地址，和 Vivado 里的地址对照。

4.2 现象：程序烧进去后 PC 指针乱跳

原因：复位信号没有正确同步到 picoRV32 的时钟域。picoRV32 的复位是异步复位、同步释放，如果复位释放时刚好在时钟边沿附近，可能进入亚稳态。

解决：在复位路径上加两级同步器，或者直接用 Xilinx 的 Processor System Reset 模块，它内部已经做了同步处理。

4.3 现象：MUL 指令执行结果不对

原因：ENABLE_MUL参数没有在 IP 核包装时使能。picoRV32 默认不包含乘法器，需要在实例化时把ENABLE_MUL设为 1。

解决：在 Vivado 的 IP 核配置界面里找到ENABLE_MUL选项，勾选后重新综合。如果用的是直接例化 Verilog 的方式，在picorv32模块的参数列表里加ENABLE_MUL(1)。

4.4 现象：Jupyter Notebook 里编译 RISC-V 程序报 “command not found”

原因：RISC-V 工具链没有加到 PATH 环境变量里。PYNQ 的 Linux 系统里可能预装了工具链，但路径不在默认 PATH 中。

解决：在 Notebook 里用!export PATH=$PATH:/path/to/riscv/bin临时添加，或者直接写全路径调用riscv32-unknown-elf-gcc。更稳妥的做法是在~/.bashrc里加一行 export，然后重启 Jupyter 内核。

4.5 现象：BRAM 写入数据后读回全是 0

原因：BRAM 的写使能信号没有正确连接，或者写地址和读地址用了不同的时钟域但没有做跨时钟域处理。

解决：检查 BRAM 的wea信号是否在写周期内拉高，检查addra和douta是否在同一个时钟域。如果跨时钟域，加一个异步 FIFO 或者双口 BRAM 做隔离。

5. 回过头看：这份实验报告真正值钱的地方

这份 29 页的实验报告，如果只看目录，你会觉得它和别的课程设计没什么区别——实验说明、硬件方案、软件方案、运行结果、实验心得。但真正动手跑一遍之后，我发现它值钱的地方在于把“软硬协同”这个抽象概念拆成了可操作的步骤。从 Vivado 里包 IP 核，到 PYNQ 上加载 Overlay，再到 Jupyter 里编译运行 RISC-V 程序，每一步都有明确的输入和输出。你不需要懂 Linux 内核，也不需要懂 FPGA 布局布线，只要照着流程走，就能看到一个完整的 SoC 从无到有跑起来。

我后来带学弟做类似实验时，会强制他们先跑通最小系统——一个 picoRV32 核、一块 BRAM、一个 UART，不挂任何多余外设。等这个最小系统能打印出字符了，再往上加中断、加 PCPI、加自定义指令。这个顺序看起来慢，但实际上省时间，因为每一步的变量都少，出了问题容易定位。

如果你手里正好有这份报告，建议别只当文档看。把 Vivado 工程建起来，把 bitstream 烧进去，把第一个 C 程序跑通。等你看到串口输出那行字的时候，这份报告里的每一页都会变得不一样。需要完整实验报告和配套工程文件的，可以按文末方式获取，里面包含了我们验证过的 Vivado 工程、RISC-V 测试程序源码，以及一份比原报告更细的避坑清单。希望帮到你。

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