RISCV__BlueSpec Piccolo MCU 结构解析

zhwei199

Piccolo 是使用Bluespec 进行描述，相对verilog更简洁，参考：【新提醒】HCL语言 bluespec资料： Bluespec systemverilog，介绍的PPT资料 - 数字IC设计讨论(IC前端|FPGA|ASIC) - EETOP 创芯网论坛 (原名：电子顶级开发网) -



==========================================================================================
分割线：：部分图片无法正常显示，参考附件PDF即可
==========================================================================================

RISCV::    Bluespec  Piccolo MCU 结构解析Table of Contents

• 1. CPU 往事
• 2. 为什么写个系列的总结
• 3. 第一回: 初窥门径 , Piccolo 的手脚
  
  • 3.1. Piccolo 的 RTL 结构层次
  • 3.2. Piccolo 的 SOC 微架构
    
    • 3.2.1. Piccolo 更详细的模块功能说明
    • 3.2.2. 总结：
      
• 4. 第二回：渐入佳境, Core 层功能模块
• 5. 第三回：略有小成 :: 外功 , CPU Wrapper 模块 : 芯片控制中心 ,
  
  • 5.1. CPU Core 内整体结构
  • 5.2. 关键交互接口
  • 5.3. CPU 顶层状态控制
    
    • 5.3.1. 流水执行
    • 5.3.2. 中断处理
    • 5.3.3. 特殊指令处理
    • 5.3.4. debug_mode 中断处理
      
  • 5.4. 总结：
    
• 6. 第四回：略有小成 :: 内功 (1) , CPU 计算模块 : 芯片计算中心
  
  • 6.1. CPU_Stage1::
  • 6.2. CPU_Stage2::
  • 6.3. CPU_Stage3::
    
• 7. 第 END 回： 返璞归真 (Just Start)
  

1. CPU 往事计算从几千年前就融入人类的生活，可以说有了计算才有了商业。但是自动并快速高效的计算仍然是人类追求的目标。

• 1642 年世纪法国数学家布莱士·帕斯卡于1642年发明通过齿轮转动实现的加法机。
• 1946 年美国的莫奇利与爱克特发明了第一代电子计算机—ENIAC，其通过真空管实现，电力消耗和体积都十分庞大。
• 1958 年基尔比发明了地球上第一颗集成电路，其工作频率约 1.2Mhz。从而开启了集成电路和 CPU 的波澜壮阔的征程。
• 1960s–2020s, 在 CPU 领域群豪并起 :
  
  • Intel 从 8086 出发到现在的 Nova Lake 大小核众核架构。
  • AMD 也不遑多让，提出了 X64 架构，在经历过低谷后，带着 Zen 架构卷土重来，通过 chiplet、3D 堆叠的 Vcache 技术等夺得桌面处理器的王冠。
  • 昔日王者 IBM Power 处理器，SUN 公司的 SPARC 处理器，DEC 的 Alpha 处理器,MIPS 处理器等都在各自的领域创造过辉煌，但是后来都慢慢消失或者市场份额越来越小。其中 Alpha 处理器中使用的技术大大的影响了后续的处理器设计。
  • 移动领域处理器王者 ARM，也是 RISC 指令集的代表，在低功耗领域大杀四方，尤其是其独创的授权模式将 ARM 生态推向极致。
  • 开源指令集 RISC-V the next king? 私以为 RISC-V 要崛起首先要解决生态问题，尤其是当前各种软件的适配。另一个领域则是定制化，得益于其开源指令集，在定制化领域的天然优势，但是又会造成生态碎片。所以，拭目以待吧。
    

CPU(中央处理器) 在 21 世纪既普通，又神秘。普通是因为这个小小的硅基物件已经完完全全融入大家的生活，无处不在。从普通生活中的的洗衣机、冰箱、手机，到昂贵超级计算机。但是神秘的是在其底层实现方式、微架构又十分神秘。


2. 为什么写个系列的总结

• 本文是一篇学习的总结，希望能窥得神秘的 CPU 微架构的冰山一角。本文不涉及 CPU 之上的 SOC 部分的详细总结，也不涉及 CPU 具体的 ISA 介绍。本总结以 RISCV Piccolo 为例, 因为 Poccolo 足够简单，但是又有 CPU 设计的基本结构，是了解微架构这座大冰山很好的起点。
• 为什么选择 Piccolo: 因为 BSV 语言逻辑更加明确（注：目前已经开源，但是工业界使用仍然较少 , chisel 也是现在 HDL 的一个尝试，但是 code 代码虽然简洁，但是不太容易理解，需要有 scala 基础），较 Verilog 更加简洁，更容易理解。
  

3. 第一回: 初窥门径 , Piccolo 的手脚为什么说 Piccolo 有手脚呢，因为 CPU 要发挥预期的功能，总是要和现实世界交互的。按照经典的冯·诺依曼架构，CPU 由输入、输出、存储、控制器和计算器组成，输入、输出就是现实世界交互的通道。 下面就看看 Piccolo 的 SOC 结构，看看 Piccolo 的 SOC 示例：

3.1. Piccolo 的 RTL 结构层次

• RTL BSV code 参考路径：https://github.com/bluespec/Piccolo
• 文件功能说明：
  
  • `src_Core/`, for the CPU core, with sub-directories:
    
    • `ISA/`: generic types/constants/functions for the RISC-V ISA (not CPU-implementation-specific)
    • `RegFiles/`: generic register files for the GPRs (General-Purpose Registers) and CSRs (Control and Status Registers)
    • `Core/`: the CPU Core
    • `Near_Mem_VM/`: for the MMU and first-level cache. In the CPU, this is instantiated twice to provide completely separate channels (MMU and Cache) for instructions and data.
    • `BSV_Additional_Libs/`: generic utilities (not CPU-specific)
    • `Debug_Module/`: RISC-V Debug Module to debug the CPU from GDB or other debuggers
      
  • `src_Testbench/`, for the surrounding testbench, with sub-directories:
    
    • `Top/`: The system top-level (`Top_HW_Side.bsv`), a memory model that loads from a memory hex file, and some imported C functions for polled reads from the console tty (not currently available for Icarus Verilog).
    • `SoC/`: An interconnect, a boot ROM, a memory controller, a timer and software-interrupt device, and a UART for console tty I/O.
    • `Fabrics/`: Generic AXI4 code for the SoC fabric.
      

3.2. Piccolo 的 SOC 微架构

file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250906225609.png

• 从 SOC 微架构看，CPU 作为 SOC 的控制核心，通过 AXI4 Fabric 与外部 MEM 和系统 IO 进行交互。
• 同时也注意，架构中没有大家常见的电脑中的 GPU、显示器、USB ，甚至 DDR 存储器等，因为这一类都是需要大量的数据搬移，而图上的 SOC 只是一个示例，更多的是显示作为控制核心。而如果需要大量的数据搬移在现在处理器中一般通过专门的数据搬运模块 DMA 进行。
  

3.2.1. Piccolo 更详细的模块功能说明

file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250906230706.png

• Fabric: 基于 AXI4 协议的 crossbar 结构，通过 SOC_MAP 为各个 slave 分配地址，并完成数据传输，并且支持错误地址检测。
  
  • 注意：在现代大型 SOC 中，一般不会直接使用 AXI crossbar 结构进行数据交换，而是通过 NOC 完成多个 master、slave 之间的互联。
    
• AXI4_Deburster: 完成对 AXI burst 的解析，并将 AXI burst 转换为单 beats 的读 / 写，方便后级 MEM、ROM 的数据读写。
  
  • 数据流：
    
    file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250906231142.png
  • key func:
    
    file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250906231213.png
    
    
• 其他模块大家可以自行查看，对 Core CPU 功能无明确影响。
  

3.2.2. 总结：

• Piccolo 的 SOC 使用示例十分简单，通过 AXI4 协议完成各个模块的互联 , 架起了 CPU 使用的整个通路，排除了其他功能模块的干扰。SOC 系统本身是一个解决方案，选用什么 CPU，什么外部硬化功能，都是根据需求而定的。本总结重点不是 SOC 系统，所以也不再赘述，以免误导。
  

4. 第二回：渐入佳境, Core 层功能模块

file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250914095827.png

• 这一层主要功能是为 CPU 服务的本文主要内容不在这里；但是需要注意的两个模块：plic 和 near_mem_io，
  
  file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250914100939.png
  
  
  • PLIC 模块用于管理外部中断，通过 meip/seip 设置 csr regfile 中的特定 bit，用于向 CPU 传递外部中断。
  • nearmem: 在 Piccolo 中，传递了 timer/software 等 local/ 核间中断，通过向 CLINT 传递中断 REQ。
  • eg. 举例 , refer: https://blog.csdn.net/weixin_43083491/article/details/147817964
    
    file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250914102713.png
    
    
• [ ] 其他部分主要是与 Jtag debug 接口对接的 debug 功能和数据 trace 功能相关，后续有时间再补充。
  

5. 第三回：略有小成 :: 外功 , CPU Wrapper 模块 : 芯片控制中心 ,
5.1. CPU Core 内整体结构

file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250914103023.png

• 如上图，Piccolo 整体实现结构较为简单，
  
  • 控制部分主要由 Stage1 完成，完成指令取值、译码 和指令数据 prepare；
  • 指令状态判断，决定什么时候可以将指令送到后一级用于指令执行；
    1. [Q] Poccolo 通过检测后级指令执行的状态，用于顺序发射指令，是否会造成   性能损失？PipeLine 气泡能否消除？   + [A] 指令依赖检测，以及乱序执行；
    
• 其他控制部分则主要在 CPU 顶层完成，只要是 CPU 中断状态处理等；
  

5.2. 关键交互接口

• imem/dmem 通过 Fabric 读写外部 MEM 的 master 接口；
• dmem 作为 slave，被外部 master 通过 Fabric 读写的接口；
• 中断接口：
  
  • mip(machine mode interrupt) 外部中断 req, 设置 mstatus mip 位；
  • sip(SuperVisor Interrupt, 内核中断) 外部中断 req, 设置 mstatus sip 位 ;
  • timer 中断；
    1. 为什么需要 timer 中断 ?   + 一般程序的是多线程程序，进入 timer 中断后，内核进行线程调度；   + 其他？
  • 软件中断：一般用于核见通信；
  • nmi(Non Maskable Interrupt) 中断：一般用于异常处理；
    
• GDB debug 接口：
  
  • GDB stop 程序执行接口；
  • 其他 debug 状态回读接口；
    

5.3. CPU 顶层状态控制
5.3.1. 流水执行

• 指令 PIPE 状态 rule: rl_pipe   正常功能
  
  • 条件： a) 当所有 stage 不都为空闲，b) 当所有 stage 不存在异常，c) stage1 未被halt 时，则处于质量流水 pipe 状态。
    1. question: stage1 halt 的条件是？ ---> 中断 /Debug 断点。1. Debug 断点如何设置？ --> 通过 CSR 寄存器进行设置，用于单步执行。
  • 对执行指令进行计数，并更新 csr_minstret；
  • 检查当前是否有 debug 中断。
    
  
  

5.3.2. 中断处理

• 指令 PIPE 状态 rule: rl_stage2_nonpipe   异常中断
  
  • 当 stage2 处于 nonpipe 且 stage3 指令提交后，stage2 进入 exception 中断状态，并记录中断信息。CPU 也进入 CPU_TRAP 状态。后续在 stage2 中再关注 stage2 什么条件下会进入 NONPIPE 移除；reference :mkCPU_Stage2
    
• 指令 PIPE 状态 rule: rl_stage1_trap   Debug 异常中断
  
  file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250914105611.png
  
  
  • 当前 stage 无中断处理，并且未 halting。
  • state2、stage3 指令处理已经排空，BREAK 指令，进入中断 (EBREAK)。则可进入 CPU_TRAP;
  • 注意 ： 当处于 debug mode 时，会屏蔽 stage1 的中断。
    
• 指令 PIPE 状态 rule: rl_state1_interrupt   外部中断
  
  • 记录 excption 原因，以及中断指令、PC，并且进入 CPU_TRAP 中断处理状态 ;
    
• 指令 PIPE 状态 rule: rl_trap   中断处理
  
  • 当处于中断状态，并且 Stage-1 无其他正常指令处理时，进入中断处理状态。
  • 根据当前 CSR regfile 中的配置，和中断状态，得到中断入口的 PC 地址。
    
    • nmi:non-maskable-interrupt?
    • 普通中断处理：根据 priv_mode，更新 mstatus 寄存器；
    • 根据中断类型和 exec_code（中断号），获取中断入口地址；
    • 设置新的 priv-mode；
      
  • 进入中断处理状态 –> CPU_START_TRAP_HANDLER
    
    • 清空 stage1/stage2 的状态；
    • 检查当前中断是否由单步调试引起 , 并设置 rg_step_check 状态；
      
• 中断处理：CPU_START_TRAP_HANDLER
  
  • 进入中断处理状态之后，根据 mstatus.MXR(Make eXecutable Readable), msatus.SUM(permit Supervisor User Memory access) 状态，以及当前 priv_mode 特权等级，以及中断入口的地址获取指令，并且开始中断程序的执行。
    
  
  

5.3.3. 特殊指令处理

• Stage-1 NONPIPE 特殊处理： CSR 指令 :Stall Stage1
  
  file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250914164126.png
  
  
  • rl_stage1_CSRR_W 处理 : automatic read and write CSR reg
    
    • 当 stage2/stage3 指令排空后，并且 stage1 处于 NONPIPE 状态；
    • ctrl 信息为 CONTROL_CSRR_W;
    • 信息记录：
      
      • 记录当前指令 PC；
      • 记录下一条指令 PC；
      • 记录输出的 value 值；
      • xxx
        
  • rl_stage1_CSRR_W_2 处理
    
    • 获取当前指令信息：func3;
    • 检测当前 priv_mode 是否有权限操作 csr_regfile；
      
      • 如果无权限，则进入中断状态
        
    • 原子交换 CSR 中的值和 grp_regfile 中的值。
    • 完成后重启 CPU 执行 –> rg_stage=CPU_CSRRX_RESTART；
      
  • rl_stage1_CSRR_S_OR_C 处理 : read set/clear CSR reg
    
    • 当 stage2/stage3 指令排空后，并且 stage1 处于 NONPIPE 状态；
    • ctrl 信息为 CONTROL_CSRR_S_or_C;
    • 信息记录
      
      • 记录当前指令 PC；
      • 记录下一条指令 PC；
      • 记录输出的 value 值；
      • xxx
        
  • rl_stage1_CSRR_S_OR_C_2 处理 :
    
    • 获取当前指令信息：func3;
    • 检测当前 priv_mode 是否有权限操作 csr_regfile；
      
      • 如果无权限，则进入中断状态
        
    • 读 csr regfile, 并根据 RS1 set/clear 对应 bit 后写回
    • 将 csr regfile 值，写入到 grp_regfile RD 中；
    • 完成后重启 CPU 执行 –> rg_stage=CPU_CSRRX_RESTART;
      
  • Stage1 re-pipe : rl_stage1_restart_after_csrrx
    
    • 从 stage-1 当前指令恢复，并 set stage1 状态；
      
      file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250914170018.png
      
      
  • FAQ
    

    
    

    • [Q] 是否有其他方式，保证 CSR regfile 操作的原子性
      
      • [A] automatic 指令对 : 通过指令对，保证两次指令之间无其他指令即可；
        

    
    
• Stage-1 NONPIPE 特殊处理： RET 指令 :Stall Stage1
  
  • Stage_xRET: 处理 RET 指令
    
    • 当 Stage1 指令为 RET 指令时，设置 mstatus。
    • 获取处理 exception 的指令入口，并根据 Priv_mode 跳转到对应的指令入口。
    • 处理完成后，跳转到 CPU_START_TRAP_HANDLER 获取指令，并设置 stage1 的状态。
      
    
    
• Stage-1 NONPIPE 特殊处理： FENCE.I 指令 :Stall Stage1
  
  • 记录下一条指令的 PC 值；
  • fence 之前的指令执行完成后，向 near_mem 发起 fence request；
  • 进入 FENCE_I 状态，等待执行完成；( 将 ICache /DCache 数据 Flush 掉，重置 Cache 内容)
    Q: 如果是乱序执行，如何执行 Fence 指令？A: 方式一：当出现 fence 指令时，当ROB 指令 commit 完成，并排空后，保证 fence之前的指令正确执行， 再执行 fence 后的指令；A: 其他方式？Q: 如果 Cache 实现是 Write-Back 策略，Cache 中的数据内容又该如何处理 ?
    
  
  
  • Stage-1 NONPIPE 特殊处理： Finish FENCE.I 指令 :
    
    • MMU_Cache:: 中的处理：由于 Cache 使用了简单的顺序写，以及 write_around 策略（a) write_hit:update cache，并写入 外部 MEM 中，write_miss：只写入 外部 MEM 中。）
    • 基于 1：FENCE.I 指令在 MMU_Cache 中，将所有 Cache Line Reset 完成后，返回 fence.I 完成指示。
      Q: 如果 Cache 实现是 Write-Back 策略，Cache 中的数据内容又该如何处理 ?A: 此时需要根据 Cache Line 状态MESI/MOESI决定，如果此时为占有 M/O，   状态则需要先将数据写回 MEM 中。Q: Fence 指令是否有必要 Reset Cache Line?A: 似乎没有必要，只要能够保证 Fence 之前的指令执行完成之后，   Fence 指令之后的指令再执行即可。
    • 等到 fence.I 完成指示后，重新从 next_pc 开始取值执行。
      
    
    
• Stage-1 NONPIPE 特殊处理： FENCE 指令 :Stall Stage1
  
  • 基本同 FENCE.I，只是只 flush DCache 中的内容。
    
• Stage-1 NONPIPE 特殊处理： SFENCE.VMA 指令 :
  
  • 基本同 FENCE.I, 只是 flush TLB 中的内容。
    
• Stage-1 NONPIPE 特殊处理： WFI(Wait For Interrupt) 指令
  
  • 当 Stage1 解析到 WFI 指令时 , 暂停当前程序处理，并且等到中断唤醒。
  • Piccolo 的 CPU 状态进入进入 WFI_PAUSED 状态，并暂停指令执行。
  • 记录当前 WFI 指令的下一条指令地址，用于 WFI 指令恢复。
    
  
  
  • Stage-1 rl_WFI_resume： WFI 指令恢复
    
    • 当监听到中断后，从 WFI pause 状态恢复 ;
      
      file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250921155125.png
      
      
  • Stage-1 rl_WFI_resume： WFI 指令恢复 2, 复位
    
    • 当监听到 CPU 复位 req 后，CPU 进入复位状态 (CPU_RESET1)；
      
    
    

5.3.4. debug_mode 中断处理

• 进入 debug mode:rl_trap_BREAK_to_Debug_Mode
  
  • 当前 CSR 寄存去中的 dcsr(Debug Control and Status Register) 寄存器中，根据当前 priv_mode，是否有 debug Break Enable 状态使能。如果有，则进入 debug mode.
  • 状态保存：
    
    • 记录当前状态到 dcsr 寄存器中，用于后续 Break 恢复。
    • 记录当前指令的下一条指令到 dpc 寄存器中，用于恢复。
    • fence 指令 req: 等待 Break 之前的指令全部执行完成，发起 fence 操作，等到包括 load/store 指令执行完成。
      
  • 进入 CPU_GDB_PAUSING 状态。
    
• debug_mode::rl_stage1_stop 状态，进入 debug/ 单步调试
  
  • 记录 break 时的 PC 和 instr；
  • 状态保存：
    
    • 将 Stop debug 原因写入到 dscr 寄存器中以及当前指令的 next_pc 写入 csr.dpc 寄存器中；
    • 清除 CPU stop/ 和单独调试 rg_step_count 状态。
    • fence 指令 req: 等待 Break 之前的指令全部执行完成，发起 fence 操作，等到包括 load/store 指令执行完成。
      
  • 进入 CPU_GDB_PAUSING 状态 ;
    
• debug_mode::CPU_GDB_PAUSING 状态
  
  • 获取 fence.i 结果，
  • 回复 halt_rsps，
  • 进入 CPU_DEBUG_MODE
    
• debug_mode::CPU_DEBUG_MODE 状态
  
  • GDB 控制台发起 REQ，并控制 CPU 恢复程序执行状态；
  • 从 CSR.dpc 获取 debug.dpc 地址，并从 dpc 开始取值，并设置 State1\2\3 的状态；
  • resp GDB 控制台的 REQ，CPU 已经恢复程序执行；
  • 注意 : rl_debug_run_redundant : 如果此时 CPU 经恢复程序执行，则忽略 GDB 回复程序执行 REQ；
    
• debug_mode::GDB 发起 halt 操作
  
  • rl_debug_halt: 当 CPU 正在执行指令时， GDB 发起 halt 程序 debug 操作，记录 stop_req，
    
    • 如果此时没有其他中断，则进入 rl_stage1_stop;
      
  • rl_debug_halt_redundant: 当 CPU 已经处于 debug_pause/debug_mode 状态时，则忽略 GDB halt 操作 req。
    
  
  

5.4. 总结：

• Piccolo 的 CPU 核心 Wrapper 的基本功能和交互接口如上描述，从功能结构上看，CPU Wrapper 的功能基本都是与 CSR 交互相关的功能，通过 CSR 模块与外部进行同步交互。
• 中断的实现通过 CSR 和 CPU 核的配合，通过 CSR 寄存器中的 mstatus、mvect 等 CSR 控制寄存器找到中断程序入口，并进行中断处理。
  
  • 从接口上看，中断分为了三大类：a) 外部中断，一般从 PLIC 输入，b) software intr, 一般用于核间通信，c) timer intr, d) nmi(non-maskable-intr) 中断；
    Q: timer intr 的作用一般是什么？A: 提示 : 操作系统多线程之前切换，每个线程执行的时间有 OS 进行设置，   当达到设置时间后，通知 CPU 和 OS 进行线程切换，从而实现分时复用。Q: nmi 的作用呢？A: 提示：如果 CPU hang 住了，或者程序跑飞了如何处理？
    

6. 第四回：略有小成 :: 内功 (1) , CPU 计算模块 : 芯片计算中心
6.1. CPU_Stage1::

file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250930161048.png

• CPU Stage 包含取指令、译码、部分单周期指令的执行功能；
  
  • 从指令 MEM 中取值，并完成指令译码；
  • 根据指令中的 rs1/rs2 判断指令中的源数据是否已经准备好，如果未准备好（busy）, 则等待。
    
• 核心功能：fv_ALU: 指令执行，根据不同的 op_code 完成指令的执行。
  
  • CATION:: 指令执行之前会判断指令类型，通过 mstatus 判断是否支持 FP 浮点类型指令。
  • CATION:: 指令执行过程中，如果指令编码为非法指令时，认为是异常指令，则进入异常中断处理状态。
    
    • 特殊指令：fv_SYSTEM（EX_ALU_functon.bsv）中对特殊指令进行译码，并且设置当前 Stage-1 的输出 Status, 从而控制 CPU 的状态；
    • AutoMatic 原子指令：该类指令要求指令执行中，不能插入其他操作，所以 Piccolo 实现时，部分原子操作保护实在 DMEM 中实现的顺序控制。
      
      file:///D:/_images_20250830---RTL-RISCV-BSV_Piccolo.org/20250930161009.png
      
      
• 状态控制
  
  • OSTATUS_BUSY: 执行等待
    
    • IMEM 指令取值 stall 时，
    • 等待 rs1/rs2/rs3 数据时
      Tips:: 因为 Piccolo 按照顺序执行指令的方式实现，       此时可能会阻塞后续数据已经准备好的指令。
      
  • OSTATUS_NONPIPE: 中断执行
    
    • 当取值异常时，
    • 当遇到 SYSTEM 指令时，eg. FENCE 指令
    • 当遇到非法指令时，此时进入异常中断执行
      
• 输入 / 输出接口：
  
  • Action enq: 用于 CPU 状态以及异常处理中，对 imem 恢复 PC/ 重定向 PC 进行取值。
    Q: imem 重定向时，有一个参数是 satp, 这个参数的作用是？ANS: 可以参考 TLB 实现，(操作系统中的地址管理方式 page table），     OS 会为每一个进程分配一个虚拟地址，每个线程通过 SATP 地址作为入口，     进行 page table walk , 查询虚拟地址对应的物理地址。从而完成地址空间访问；More: 为什么需要虚拟地址管理？TIPS: 系统安全、虚拟化、更方便的每个进程进行地址空间管理、……
  • set_full: 用于控制 CPU_STAGE1 的状态 , 非 full 时为 OSTATUS_EMPTY。
    

6.2. CPU_Stage2::

• CPU Stage2 包含浮点运算、乘除法、Load/Store 等多周期执行的复杂指令。这个 stage 里面几乎不涉及复杂的控制，（直接参考 CPU_Stage2.bsv）即可。
  
  • 注意原子指令：AMO 原子指令在 Piccolo 实现中，大部分操作在 D-Cache 中实现。
    

6.3. CPU_Stage3::

• 写回Stage: 将数据写回到 GRP/FPG regfile 中。
  

7. 第 END 回： 返璞归真 (Just Start)

• CPU 作为人们目前能设计和广泛使用的“电子产业心脏”，其复杂度、广度都极难在短时间内学习并掌握。Piccolo 的学习（如上其实也是把基本数据流记录了一下，更多细节仍然需要学习和将多个知识点串联起来）,
  
  • 实际上，按照武侠小说中的武学划分， 目前应该刚扎完马步，学上了太祖长拳。
  • 对于其后的学习每个细分领域就像少林寺的七 十二绝技，需要稳打稳扎的下笨功夫去学习、实践。
    
• CPU 作为现代计算机信息产业的基石，实现和应用场景上已经是多种多样，几乎只要有电的地方就会有 CPU 的存在，但是如何衡量 CPU 的性能或者说是是否适合对应的场景可能是一个无穷无尽的话题。
  
  • 标准的工具有 benchmark，但是 benchmark 也未必适合所有 CPU 的 应用场景作为衡量基准。比如，a) 极端低功耗场景对性能要求不高，但是对功耗要求严苛。b) 实时处理场景对 CPU 绝对处理性能要求不高，但是要求有可预测的处理延时，等等
    
• 尽管应用场景丰富，衡量标准无非基于应用场景的需求对 PPA 进行衡量。
  
  • CPI:
  • 程序执行时间
  • 功耗
  • xxx
    

Created: 2025-09-30 周二 18:00

Validate