分支预测器的性能指标上一篇文章研究了一个供学习研究的分支预测器 biriscv_npc，顺便量化了这个分支预测器的性能（唯一指标就是分支准确率，已经包含各个分支指令执行次数的权重，想想为什么）。 这篇文章来研究各个参数对于分支预测器的影响，以及为什么影响。 BTB 容量处理器的 BTB 大小是有限的（比如 512 个条目）。当需要存入第 513 个分支指令的预测信息时，必须覆盖掉某一个旧条目。选择

分支预测器性能统计基本信息当 branch_request_i 拉高： RAS 学习如果 BTB 命中或者不命中： btb_pc_q 更新：btb_pc_q[btb_wr_entry_r] <= branch_source_i btb_is_call_q 更新：btb_is_call_q[btb_wr_entry_r]<= branch_is_call_i btb_is_re

biriscv bp这是 bp 的 IO 信息： 1234567891011121314151617181920212223242526272829303132333435363738394041module biriscv_npc//-----------------------------------------------------------------// Params//------

基于 2 bit 饱和计数器原理就是利用 PC 中 k 位来查找 PHT，若查到了一个表项，那么就可以由 PHT 中的一个表项的 2bit 饱和计数器给出跳转建议。这个 2bit 饱和计数器其实就是一个跳转意愿强度：00、01、11、10（格雷码）。而从指令提交阶段的跳转指令的反馈信息（比如是否发生了跳转）可以更新这个饱和计数器。 PHT（Pattern History Table）PHT 存放

项目文档描述：基于 LoongArch32R 的轻量级 SoC 及嵌入式系统实现1. 题目简述本项目设计并实现了一个完整的、基于国产 LoongArch32R 精简指令集架构的嵌入式片上系统。核心内容包括： 定制化 LoongArch32R CPU 核心： 包含双缓存（Cache）结构（指令缓存 I-Cache 和数据缓存 D-Cache）以及动态分支预测器，提升执行效率。 完整 SoC 集成：

前言昨天面试，有一个问题问到了链接脚本以及 elf 文件结构。感觉回答得不怎么样，很多概念的细节都想不起来了，面试官也没深问。于是我立即决定做一个实验好好回顾一下这一块儿的知识： 写一个比较复杂的测试程序，最好能包含各个段； 写一个简单的启动代码； 写一个简单的链接脚本； 写一个简单的库，包含类似于 printf、memcopy； 然后编译、链接，放在裸机上执行。 项目结构1234567891

总线驱动模型这种架构将设备（硬件描述）和驱动（操作逻辑）分离，实现了解耦和灵活性。内核中的平台总线（platform bus）负责将它们连接起来。 这种分离将驱动与驱动对硬件操作分成了两部分：驱动和设备。这就引来了一些问题，比如： 驱动怎么匹配设备 设备怎么匹配驱动 匹配上了后，probe 要做什么 删除设备后，remove 要做什么 一个驱动带多个设备 等等 以下通过例子来阐述这种分离，以及

前言为了更深层次了解计算机的工作原理，我要开始学习 Linux 驱动开发了，主要面向嵌入式 Linux。 驱动驱动要保证内核安全，防止崩溃、数据泄露等，防御性编程是安全的基本思维。 驱动作为 Linux 内核的关建代码，要和设备直接沟通：在高权限模式下直接访问寄存器或者内存（地址重定向），因此必须保证安全，使用内核提供的库函数。这样，可以防止用户态程序提供的指针非法或者借用内核来执行一些危险操作。

ysyx 更新ysyx讲义 今年 8 月份左右更新了，内容更加丰富，难度上升更加平滑。当然，这不是我 relearn 的主要原因。 主要问题我之前的 CPU 是用 Chisel 写的，由于 Chisel 掌握的不熟练，稍微学了下就开始上手，导致代码质量不高。作为有代码洁癖的人，不优化到让我满意我是绝不停下来的。 那时候由于第一次写处理器，没有一个很好的框架意识，基本都是乱乱写的，虽然功能没问题，但

思考与反思昨晚 8 点进行了一场线上面试，我的感觉是回答得不够好。 我并没有准备这个项目，我对 OS、软硬协同方面做了几个小时的准备，比如 OS 进入核心态时的模式、模式转换、trap_handler、syacall、context 转换等。 面试官问了我的一个 处理器项目，我对那个项目很自信，因为那是我从 0 开始写的，所以就完全没有准备。但是时间有点久了（8月15 完结到现在快两个月），有点忘