BRAM理想的效果是，IFU 在当前周期上升沿给 inst_sram 发射地址后，在当前周期内就可以拿到 inst_data，但是这是理性情况下。 异步 RAM 很方便，但是实际情况是，CPU 的频率非常快，比 RAM 快得多，因此如果为了保持异步访存，就得将 CPU 的频率降低，这很明显会损失性能（暂不考虑 inst cache）。 这里就引入了 BRAM，它在当前周期给 BRAM 发射地址，下

阻塞技术解决相关引发的冲突概述阻塞技术，以 5 级流水线为例，就是将这个 5 个模块设计成单独的模块。比如对于 IDU，IFU 就是它的上游，EXU 就是它的下游。IDU 的数据来自上游，同时它要给下游 EXU 提供数据。 阻塞技术会使得每一个模块都会相互解耦，成了一个单独的模块。 模块之间如何握手呢？ 设想一下，对于 IDU 而言，假设它遇到了点事情，需要阻塞，那么就会通知 IFU 不要发数据了

移动特性C++11 会通过移动语义来消除内存拷贝成本，而 rust 将这种特性发挥到极致，推出了所有权机制。 看一段代码： 12let s1 = String::from("hello");let s2 = s1; 当 s2 绑定 s1 的资源的时候，就会将 s1 的资源转移到 s2 中，这是因为一份资源只能有一个拥有者。 换句话说，s1 资源转移到 s2 中，不仅仅发生了浅

使用 verilator 进行测试生成测试案例编译测试文件，之后会生成 coe 文件、mif 文件。而且，mif 文件也可以由 vivado 生成，更具体地： mif 文件是根据 coe 文件生成的。 coe 文件只会在生成 rom 模块时起作用，其作用就是根据文件内容生成相应的 mif 文件，而 rom 真正使用的是 mif 文件。 直接编辑 .mif 文件的方式不可取，因为在重新生成其他模块

difftest之前做 ysyx 中的处理器设计的时候，使用了 基于 nemu 的 difftest。那个 difftest 的原理是： nemu 被编译成一个库，暴露出了一些接口供 CPU 调用； 仿真程序将 img 装到各自的内存； 当 CPU 执行一步的时候，REF CPU 也执行一步； 接着对比两者的所有的 寄存器包括 PC； 如果寄存器不同，那么就发出报告信息，程序员可以进行 debu

环境参考 chiplab 配置好环境之后，基于 loongsonEdu 的开源项目 cdp_ede_local，进行前期的增量开发，同时也参考 CPU 设计实战。后期可以顺利移植到 chiplab 中进行验证。 minicpu_env这个实验要求阅读代码，熟悉流程，并补充代码且进行 debug（代码有的地方有问题）。初次在 vivado 上仿真之后，感觉难以调试（时间漫长），于是我在本地搭建了基于

总结这十三篇博客是学习 循序渐进，学习开发一个RISC-V上的操作系统 - 汪辰 - 2021春 的笔记，今日终于完结了。 学完之后，收获很大，如果要是做过 riscv CPU 设计那效果更佳。 如果不考虑性能（需要精巧的数据结构和算法），OS 的核心就是模式转换。soc 提供了各种设备，启动的时候，得初始化这些设备，之后就能利用这些设备了，比如 CLINT、PLIC、UART 等。 ISA 也提

前言我们希望，用户程序仅仅运行在 U 模式，而 OS 代码统统运行在高权限模式下。这样，比如 tasks 的行为将会受到限制，比如它不能随意的修改 csr 寄存器，甚至修改 PLIC、CLINT、UART 寄存器以危害整个系统。 因此，某些可能会威胁到 OS 稳定运行的操作应该运行在高权限模式下，比如 S、M 模式。而 tasks 想要执行某些高权限操作，只能通过系统调用的方式来进行。 系统模式：

软件定时器软件定时器和系统实现 _tick 基本没有什么差别。 硬件定时器：芯片本身提供的定时器，一般由外部晶振提供，提供寄存器设置超时时间，并采用外部中断方式通知 CPU，参考 第 12 章介绍。优点是精度高，但定时器个数受硬件芯片的设计限制。 软件定时器：操作系统中基于硬件定时器提供的功能，采用软件方式实现。扩展了硬件定时器的限制，可以提供数目更多（几乎不受限制）的定时器；缺点是精度较低，必须

前言在前面，我们已经实现了抢占式任务，但是依然有很多的问题。 如果，两个任务不相关，也就是说没有数据上面的交互，那么是没有问题的。但是一旦涉及到访问共享资源，比如终端，就会出现问题： 1234567891011121314151617Task 0: Running...Task 0timer interruption!tick: 288Task 1: Running...Task 1: Runni