Hyacimond’s Blog

“一生一芯”项目学习记录（二）性能优化与流水线（v23.06）

Fri, 26 Jun 2026 00:00:00 GMT

B 阶段

性能优化

IPC

IPC 的统计最直接的做法是在 NPC 执行一次指令的循环中递增 cycles 和 insts，但实际跑的时候发现越大的程序 IPC 越低，很显然 拉低 IPC 的原因是 FSBL 和 SSBL ，尤其是 FSBL 大量从 Flash 中取指令和取数据。个人觉得更严谨的统计是只统计 main 函数开始到结束的 IPC。经过查询得知，处理器性能监控一般使用两个 CSR 来统计 IPC，mcycle 和 minstret，好处是可以自由选择要统计的范围，只需在开始和结束点读取这两个 CSR 即可计算。

但是如果采用这种方式，要求 AM 环境必须支持软浮点运算，更完善的 printf 打印。移植一些开源的嵌入式 printf.c 的实现仍然需要更多的软浮点相关符号链接。因此还是选择在仿真环境中统计 IPC。后期等待处理器设计完善后再考虑解决软浮点问题。

性能计数器

之前重构 NPC 时改成了基于分布消息控制的架构，但是目前 CPU 的多周期本质上是单周期 + 访存延迟等待，一方面，这种控制流导致模块间握手传输不清晰，ready 有时候充当了阻塞标志，但实际前级模块已经将消息发送给后级（不符合 valid & ready 握手协议）。因此，性能计数器要求的访存延迟几乎等效于访存类指令的执行时间，IFU 取指令阻塞的原因也非常单一，主要是取指请求发出后等待下游存储系统返回指令数据，之后则是等待指令彻底执行结束后才会开始取下一条指令。

⚠️

此处统计排除了 FSBL/SSBL 阶段，指令执行周期计数不统计取指延迟。

对于一个 microbench test 规模的 PMC 结果：

Amdahl 定律如下：

其中，表示当前总时间中可优化部分的占比，表示该部分被优化的倍数。

IFU 取指等待优化

取指相关等待周期为：

占总周期比例为：

若 IFU 取指等待优化 2 倍：

若 IFU 取指等待优化 4 倍：

若完全消除 IFU 取指等待：

LSU 总执行周期优化

LSU 总执行周期为：

占总周期比例为：

若 LSU 总执行周期优化 2 倍：

若 LSU 总执行周期优化 4 倍：

若完全消除 LSU 总执行周期：

根据 Amdahl 定律，当前 MicroBench 下最主要的性能瓶颈是 IFU 取指路径。取指相关等待约占总周期的 79.80%，完全消除后的理论加速上限约为 4.95 倍。相比之下，LSU 额外访存等待占总周期约 13.71%，即使完全消除，理论加速上限也只有约 1.16 倍。

校准访存延迟

F_CPU ~= 380.918 MHz r = F_CPU / 100 MHz ~= 3.80918

即外设每一个周期的时间等于 CPU 运行 3.80918 个周期，乘以 2 的 N 次方量化成定点数。其中需要注意的是 delay_counter 从 delay_max 获取延迟计数时需要四舍五入。

最高综合频率情况：

ALU / 加法器相关上限：约 822.698 MHz

regfile 读路径上限：约 1968.682 MHz

添加访存延迟后，主要的性能瓶颈依然是访存。

提升功能测试效率

通过配置项切换三种运行模式：Interpreter、NPC Standalone 和 NPC with SoC，配套修改覆盖了 AM、NEMU 和 NPC 三层。

程序的局部性

使用 codex 编写的脚本根据 mtrace 日志生成了三张图（测试环境：ysyxSoC，Microbench: test 规模）：

有明显分段的横线，同一地址附近被反复多次访问。

整个时间窗口内也有明显的局部热点。

按地址块分组统计，发现具有很强的时间局部性。

简易 Cache

LINE_NUM	Total Cycles	IPC	Misses	Hit Rate	相对 16 行加速
16	2,308,401,555	0.0845	51,164,876	73.78%	1.00x
32	1,550,991,219	0.1258	25,189,043	87.09%	1.49x
64	1,234,119,897	0.1581	14,365,021	92.64%	1.87x
128	1,004,123,641	0.1944	7,075,902	96.37%	2.30x

Cache lines	Area	Fmax	ALDFF_PP	ICG
16	26648.44	331.679 MHz	928	92
32	28597.80	333.644 MHz	1824	108
64	31890.32	337.019 MHz	3584	140
128	40909.40	306.537 MHz	7040	204

上述是运行 Microbench Train 规模的评估结果。

实现 cachesim 之后发现数据与 ysyxSoC 运行时评估不完全相同，后续发现原因是 interpreter 和 SoC 环境的动态运行指令本来就不一样，导致 pctrace 的日志输出不一样。

具体是 uart 代码轮询。interpreter 不模拟总线行为，每次读 LSR 寄存器都可以读到 1，而 SoC 就不一定了，可能存在等待的情况，这会增加轮询次数。因此，对于有串口输出的程序，cachesim 只要使用的是 interpreter 模式生成的 .bin 日志，必然评估结果不会精确一致。

在 iCache 侧支持 AXI 的突发传输

由于先前针对 core 内部模块的简单接口不支持突发，所以接口层次需要做修改：

axi4_master.sv 更名为 core_axi4_wrapper.sv ，针对每个模块需求的 AXI 协议部分做单独适配，不再追求一个文件实现全量 AXI 协议，这样对于面积优化可能也有帮助。

AXI 仲裁器需要支持突发事务的响应，突发事务完成标志：xlast && valid && ready

接入 AXI 接口的 SDRAM 之后，总线位宽部分需要修改以支持 32 位宽。

iCache 内部逻辑也需要修改：

iCache 顶层 master 接口直接输出 AXI

ifu 发起请求后，iCache 判断是否命中。命中则直接返回数据，不命中则发起一笔填充 Cache line 的突发请求，按照 WRAP 模式优先返回 ifu 需要的地址下的数据。

iCache 可以处理 secondary miss 的事件。例如，ifu 请求下一条地址时，上一次突发还未完成，则判断是否为 secondary miss（命中数据在传输途中），否则视为 MISS，同上

修改到 AXI 接口的 SDRAM 之后的 bug 解决：

但接入之后触发取指令异常错误在第一条主程序指令（0xa0000000）：

在 CPU 顶层总线上可以发现，R 通道提前握手成功了，传回非法值

一路追溯至：

其中resp_valid_w 信号指示响应队列非空，该信号断言时说明此时有一笔待读取的事务，是 rvalid 拉高的必要条件之一。再看 resp_is_read_w：

它拉高需要 req_out_valid_w && req_out_w[5] ，其中 req_out_valid_w 连接到了另一个 FIFO (请求)，指示请求队列非空。请求队列非空则获取 FIFO 输出的 MSB。

对于请求 FIFO 保存的数据格式可见：

最高位保存的是是否为读请求的标志位

sdram_axi_pmem.v

因此，rvalid 被拉高的条件就是：当前请求了一笔读事务，且读数据的 FIFO 非空。初步推断在于错误读取 FIFO 的数据。

进一步查看两个 FIFO 发现，响应 FIFO 有一笔数据后紧跟着被消费，但是请求 FIFO 的 count 长期在 3-4 摆动，也就是一直有三笔没被消费的请求

于是打算查看写入请求 FIFO 的来源：push_i → req_push_w → ram_accept_w → state == STATE_WRITE0

在波形图查看，STATE_WRITE0 持续了两个周期，同时导致 ack_q 拉高两次，进一步引发 FIFO 保存了两次一模一样的请求！

而自己之前为了完成 SDRAM 扩展做了如下改动：

这个开源控制器原本的实现是，STATE_WRITE0 会无条件向 STATE_WRITE1 转移，STATE_WRITE1 会判断当前是否连续写，最多呈现 0 → 1 → 0 → 1…… 的循环写入。因此这里可以强制让 STATE_WRITE0 只持续一周期，删除掉那一串判断（目前也暂时不用支持连续写入）

通过测试：

Cachesim 评估说明

该 icache 设计加入了 secondary miss，这部分属于总线行为，在 cachesim 侧不太好模拟，但是在总体命中率上仍然有参考价值。只是对于现在的情况，cachesim 不再是对于 icache 的精确差分模拟。

实际上 NPC 仿真得出的 HIT + SEC_MISS 也约等于 Cachesim 评估的命中率。因此使用 Cachesim 进行快速评估还是有一定参考价值的。

初步评测

使用 microbench test 初步对比 4 blocks x 16 bytes 和 16 blocks x 4bytes 两种布局：

Cache 最佳设计空间探索

前面的实验已经说明，单纯增加 Cache 行数虽然能够提高命中率，但面积会随着数据阵列、Tag 和 Valid 位快速增长。进一步的问题是：在面积预算下，Cache 行数和块大小应该怎样组合？

这次使用 NEMU 运行 MicroBench test 规模生成的 PC 游程编码元数据进行回放。CacheSim 模拟直接映射 ICache，一共扫描了 20 种 BLOCK_NUM × BLOCK_BYTES 组合；随后选取其中 7 个具有代表性的布局，分别使用 Nangate45 和 ICSprout55 进行 Yosys 综合与 iSTA 静态时序分析。

综合环境统一采用当前 RV32E 的 16 个 GPR 配置和 1000 MHz 目标约束。表中的 Fmax 取自 iSTA 报告中 core_clock/max 路径的 Freq(MHz)，用于比较不同布局的前端综合时序。

评估结果（Cachesim + Yosys）

Cache 布局	数据容量	突发拍数	命中率	Nangate45 面积（μm²）	Nangate45 Fmax	ICS55 面积（μm²）	ICS55 Fmax	满足 Nangate 23000
2 × 16B	32B	4	86.21%	16267.496	516.533 MHz	22251.880	452.192 MHz	是
4 × 16B	64B	4	90.80%	18845.568	519.441 MHz	25571.560	426.834 MHz	是
8 × 16B	128B	4	95.17%	23791.572	495.557 MHz	32276.720	448.303 MHz	否
2 × 32B	64B	8	93.47%	18617.606	506.641 MHz	25573.800	457.220 MHz	是
4 × 32B	128B	8	95.81%	23622.130	557.191 MHz	31780.840	423.490 MHz	否
8 × 8B	64B	2	84.62%	19152.000	530.904 MHz	26516.000	456.183 MHz	是
16 × 4B	64B	1	73.78%	19731.880	545.951 MHz	26874.120	449.357 MHz	是

所有 14 份综合结果的 synth_check.txt 均报告 Found and reported 0 problems。

🔎

2×32B 与 4×16B 的数据容量均为64B且综合面积接近：前者通过8拍突发充分利用空间局部性，命中率更高，但 refill 和 MSHR 占用时间更长，Secondary Miss 等待代价更大；后者命中率较低、Primary Miss更多，但4拍 refill 能更快释放总线和 MSHR，降低缺失代价。因此仅凭命中率无法确定最优布局，还需在完整SoC中比较AMAT、Secondary Miss、总周期和IPC。

完整 SoC 最终评估

布局	测试规模	总周期	动态指令数	IPC	Hit Rate	Primary Miss	Primary Rate	Secondary Miss	Secondary Rate	平均缺失延迟	AMAT	最终评价
2 × 16B	train	2,321,923,102	195,161,085	0.084051	79.15%	26,904,106	13.79%	13,794,245	7.07%	31.83 cycles	7.43	容量较小，缺失次数多，总周期最长
4 × 16B	train	1,820,098,664	195,160,354	0.107225	85.69%	17,947,819	9.20%	9,972,220	5.11%	31.38 cycles	5.35	总周期最少、IPC最高且AMAT最低，当前最优
2 × 32B	train	1,956,200,058	195,158,942	0.099764	89.64%	12,752,948	6.53%	7,469,722	3.83%	45.46 cycles	5.61	命中率最高，但长突发使平均缺失延迟明显增加
8 × 8B	train	1,953,808,091	195,164,756	0.099889	77.21%	30,013,416	15.38%	14,458,343	7.41%	24.67 cycles	6.39	平均缺失延迟较低，但缺失次数过多

流水线处理器

在 B 阶段开始时已经做过了 NPC 的重构：按照分布消息控制方式拆分成五级流水的模型，所以直接加入流水线寄存器以及处理三大冒险。

冒险处理也先采用比较简单的方案：数据冒险从 LSU、WBU 向 EXU 前递，离 EXU 更近的 LSU 优先；Load 的数据在 LSU 阶段还没有返回时就阻塞相关指令。结构冒险主要来自 IFU 和 LSU 共用总线，目前不加入 DCache，由仲裁和流水线反压解决。控制冒险使用静态不跳转预测，分支在 EXU 得出结果后重定向 PC，并冲刷 IF/ID、ID/EX 中的错误路径指令。WBU 作为唯一提交点，Difftest、指令计数和停机等信息都从同一条提交指令中取得，避免软件侧看到尚未退休的流水线状态。

前递数据不能只看当前周期

实现时遇到过一个比较隐蔽的问题。下面三条指令执行到分支时，a4 可以从 LSU 获取，a5 可以从 WBU 获取，所以两个源操作数能在同一周期凑齐：

但换成连续 Load 后情况不同：

第二条 Load 进入 LSU 后需要等待内存返回，分支也会因此停在 EXU。等待期间第一条 Load 已经在 WBU 退休，a5 的前递值只在当时的组合逻辑中出现过；下一周期 WBU 内容更新，这个值就丢失了，而分支保存在级间寄存器里的仍然是 IDU 之前读出的旧值。

因此，EXU 在被阻塞时需要分别记录两个源操作数是否已经就绪，并把已经前递到的值暂存下来。之后即使原来的前递来源离开流水线，也可以用暂存的 a5 配合刚返回的 a4 继续执行。这里不能只做一个整体的“操作数有效”标志，因为两个操作数到达的时间可能不同。

使用 Konata 流水线可视化工具

I：创建一条动态指令。

S：进入一个流水级。

L：设置指令显示文本。

R：这条动态指令结束，可能是正常退休，也可能被冲刷

C：仿真时间向前推进若干周期。

使用这个工具时候遇到一个 bug：在 NPC STANDALONE 模式下，一些测试用例会触发 disassemble 反汇编失败的断言。

调查发现是由于生成 konata.log 时候调用 NEMU 中的反汇编工具，IF 取到非法指令但来不及冲刷时调用了反汇编函数导致仿真触发断言中断程序。

“一生一芯”项目学习记录（一）SoC 计算机系统（v23.06）

Thu, 01 Jan 2026 00:00:00 GMT

❗

声明该文章作为一生一芯官方学习记录的补充，部分代码实现思路以及思考仅代表个人观点。本文不立足于撰写“详细教程”、“通关秘籍”等类型的文章，也不包含考核答辩面经，仅仅作为个人记录留存。 如果您正参加该项目，且尚未完成相应任务点，请自觉退出！该行为可能与“一生一芯”项目官方所推崇的独立解决能力培养理念相违背！

📖

本文内容包括但不限于：

部分代码设计实现思路

踩坑记录

部分必做题、思考题观点整理

……

📝 预学习阶段

NVBoard

sim目标通过定义FST宏可自由生成不同格式的波形文件

一生一芯官方推荐版本为Verilator 5.008 2023-03-04 rev v5.008，该版本下—trace-vcd和—trace-fst不可用新版本中已经弃用—trace参数，作者此处使用版本为Verilator 5.040 2025-08-30 rev v5.040-50-g0a9d9db5a 具体请参考官方手册：
verilator Arguments — Verilator Devel 5.043 documentation
The following arguments may be passed to the “verilator” executable.
https://veripool.org/guide/latest/exe_verilator.html#cmdoption-trace

键盘检测实验中作者觉得讲义中所写状态机不好理解，遂自行实现，依照 HDLBits 网站中的状态机描述风格：

NEMU（PA1）

主要内容是实现一个简易调试器

`sdb_mainloop()`解析

rl_gets()函数将整行命令读取到str中，strtok函数按空格分割出目标命令，在查找表中逐个对比，一旦匹配则进入相应的cmd_*逻辑中继续执行。

优雅的退出

主函数退出前会执行一个判断状态的函数：

故只需要在cmd_q中设置 NEMU 状态为退出即可：

表达式求值

隐式类型转换

完成表达式求值的核心任务就是不断处理各种非法表达式，确保计算结果格式与预期相符。

讲义中统一规定使用无符号格式进行计算，而C语言中执行字面量除法默认是有符号数除法，为了与测试脚本运行结果一致，将val1和val2强转为有符号类型

表达式生成器

讲义中建议为在主函数中加入测试，而作者在这里单独新增一个test指令，在 NEMU 中执行 test 命令将自动生成 500 条表达式（自动丢弃掉非法表达式，例如包含除以 0 的表达式）。

同时为了避免生成过长的表达式，对递归深度和生成表达式长度进行限制，否则有可能除法段错误：

测试结果：

断点Bug

完成监视点内容之后，作者使用w $pc==0x8000000c设置断点到最后一条 ebreak 指令，结果如下：

发现非法指令被执行。经过 gdb 调试发现，执行结束 ebreak 指令后，NEMU 状态会被设置为END后安全退出，而扫描监视点时，命中监视点会将 NEMU 状态设置为STOP，导致后续读取到非法指令触发错误，解决方案也很简单，加一层状态判断即可。

另外，此处是用监视点模拟断点，因此程序代码运行时产生了两次中断（旧值不等于新值）。

C阶段

理解一条指令在 NEMU 中的执行过程

exec_once(&s, cpu.pc); 包含指令的取指、译码、执行、pc 更新，cpu 结构体保存全局状态，Decode s;为运行时上下文结构体，保存静态 pc、动态 pc、指令等相关元素。

exec_once 前四行：

取指过程：

vaddr_ifetch函数到对应地址下读取32位长度的指令，然后将snpc+4，返回读取的指令。

译码与执行过程：

这一长串宏直接使用 VS Code 插件自带的智能感知（Intellisence）展开为：（下文只保留一个INSTPAT）

有关于do {} while(0)的用法参考
Why use apparently meaningless do-while and if-else statements in macros?
In many C/C++ macros I'm seeing the code of the macro wrapped in what seems like a meaningless do while loop. Here are examples. #define FOO(X) do { f(X); g(X); } while (0) #define FOO(X) if (1) {...
https://stackoverflow.com/questions/154136/why-use-apparently-meaningless-do-while-and-if-else-statements-in-macros

有关于符号标记用法参考。从功能上来说，这种方式给出了一种高效快捷的代码跳转方式，一旦匹配则提前结束该代码块。
Labels as Values (Using the GNU Compiler Collection (GCC))
https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

pattern_decode函数详解

这里i表示处理指令字符串的下标。空格被自动忽略，除0、1、?之外的字符会抛出异常，下面以“??????? ????? ????? ??? ????? 00101 11”为例子：

__key用于识别指令操作码，只对0和1感兴趣，最终值为0010111;

__mask用于生成掩码，?对应位置设置为0，其他对应设置为1，表示?区域不应参与匹配。

__shift对于一些不关心低位匹配的操作码，如110 ????，最终它的值为4，右移四位匹配。

micro64(0); 展开为macro32(0);macro32(32);，继续展开为macro16(0);macro16(16);macro16(32);macro16(48); ，最终变成macro(0);macro(1);macro(2);……;marcro(64); ，这种宏展开可以在编译阶段直接优化，减少for循环方式造成的运行时开销。

💡

这种思路的可实现性在于指令是提前就加载到代码中的，即编译阶段指令代码的内容就是确定的。而对于等待用户输入是程序运行时才能解决的问题。

接下来这行代码(((uint64_t)((s)->isa.inst) >> shift) & mask) == key 对指令进行匹配，匹配成功则提取操作码和操作数。

decode_operand函数详解

这里BITS宏进行位切片，提取出对应的寄存器。

src1R()宏展开之后长这样，很显然是对相应寄存器的赋值操作：

immI()宏展开之后长这样，提取I型指令的立即数，并做符号扩展：

之后便可以完成代码的执行，结束后返回0。

实现更多的指令

运行测试用例 mul-longlong.c 时出现 HIT BAD TRAP 的提示：

使用 gdb 调试，调用栈如下：

该语句导致halt_ret被置1：

这说明，执行 ebreak 时，$a0 寄存器的值为 1。打印当前s→pc的值为 0x80000140

接下来利用 sdb 在 NEMU 中设置对 $a0 的监视点：

查看反汇编，发现 check 函数执行导致 a0 被设置为 1

结合C代码和反汇编分析容易知道，check函数负责检查乘法计算结果和预期结果是否一致，说明我们乘法指令的实现存在问题

C11 标准（N1570）中指出： “When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged.” 当一个整数类型的值被转换为除 _Bool 以外的另一种整数类型时，如果该值能够被新类型表示，则该值保持不变。 32位无符号数任意取值都能够被 64 位有符号类型的整数所表示，所以转换时值不变，高位作零扩展。如果作符号扩展，它的数值就被改变了。
www.iso-9899.info
https://www.iso-9899.info/n1570.html#6.3.1

此处实现方法的确有问题，对于mulh这种指令，src1和src2如果是负数，类型转换后变成了正数，计算结果自然与实际不相符。于是对src1和src2先使用宏函数SEXT()进行符号扩展，最后进行运算。最终修改如下：

再次运行成功通过：

完整测试如下：

使用 DPI-C 机制验证 RV32I 单周期 CPU

DPI-C 机制允许在 System Verilog 中直接调用 C 函数，或者导出 function 和 task 供 C 语言调用。

npc_trap();的实现：

使用 verilator 进行仿真

while内至少top→eval();两次，第一次计算由时钟沿触发产生的时序逻辑更新（clk 0→1，eval()触发 pc_o 的更新），第二次计算触发寄存器更新导致的组合逻辑更新（由新的pc_o取出下一条指令）。

这样波形上才能和事件驱动型仿真器一致。

top→eval();是根据输入激励计算输出

tfp->dump(contextp->time());是按当前时间轴记录一次波形 contextp->timeInc(1);是当前记录时间加一，三者必须共同配合才能仿真出完整波形

测试结果：

对 AM 的 Makefile 默认启动批处理模式NEMU

通过RTFSC得知，要在运行NEMU时传入参数-b

作者此处直接使用 remake 工具单步调试，发现最终ARGS变量的来源：

对应 Makefile 源代码位置修改如下：

考虑到对测试代码使用 sdb 的需求，作如下调整：

添加递归 remake 支持

起因是由于使用 remake 单步调试时遇到子项目的 make 构建就会直接跳过，如果想要调试子目标的 Makefile 就要中途退出一次，然后使用 remake 调试 Makefile.xxx，不太方便。后来发现了 nemu.mk 文件使用了 $(MAKE) 这个内置变量，查询了该变量相关用法，于是做如下修改：

修改前单步调试：

修改后单步调试：

内部的 Make 也会开启 Trace 模式，子目录的详细构建过程也被打印出来了。

参考文档内容
GNU make
https://www.gnu.org/software/make/manual/make.html#Recursion

使用 C 语言解析 ELF 文件并实现 ftrace

主要完成：

使用 elf.h 解析 ELF 文件的符号表，建立针对 FUNC 类型的查找表

判断 call 指令和 ret 指令并打印跟踪日志

修改 Makefile 使得运行 tests 时可以自动传入elf参数

ftrace 效果如下：

这里发现两个个问题：

C 代码最开始是 f0 调用了 f3，但是 ftrace 显示是 f0 调用了 f2

讲义中提到的返回不对应问题

❓

这里反汇编是 jalr x0, 0(a5)，作为调用指令目的寄存器却不是 ra。

经过 STFW，该现象可能与尾调用有关。如果函数最后一步的操作是调用一个函数，无需把返回地址压入栈中，直接跳转到那个函数，由它直接返回。

尾调用优化 - 阮一峰的网络日志

上面代码中，情况一是调用函数g之后，还有别的操作，所以不属于尾调用，即使语义完全一样。情况二也属于调用后还有操作，即使写在一行内。

https://www.ruanyifeng.com/blog/2015/04/tail-call.html

尾调用

在计算机学裡，尾调用是指一个函数里的最后一个动作是返回一个函数的调用结果的情形，即最后一步新调用的返回值直接作為当前函数的返回结果。[1]此时，该尾部调用位置被称为尾位置。尾调用中有一种重要而特殊的情形叫做尾递归。经过适当处理，尾递归形式的函数的运行效率可以被极大地优化。[1]尾调用原则上都可以通过简化函数调用栈的结构而获得性能优化（称为“尾调用消除”），但是优化尾调用是否方便可行取决于运行环境对此类优化的支持程度如何。

https://zh.wikipedia.org/wiki/%E5%B0%BE%E8%B0%83%E7%94%A8

参考资料
Executable and Linkable Format
In computing, the Executable and Linkable Format is a common standard file format for executable files, object code, shared libraries, device drivers, and core dumps. First published in the specification for the application binary interface (ABI) of the Unix operating system version named System V Release 4 (SVR4), and later in the Tool Interface Standard, it was quickly accepted among different vendors of Unix systems. In 1999, it was chosen as the standard binary file format for Unix and Unix-like systems on x86 processors by the 86open project.
https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#File_layout
zhuanlan.zhihu.com
https://zhuanlan.zhihu.com/p/1927510429430703942
The RISC-V Instruction Set Manual Volume I | © RISC-V
2.5.1. Unconditional Jumps
另外，根据手册和查阅反汇编代码，函数调用指令一般情况目标寄存器为 ra 寄存器，ret 指令在 RV32I 和 RV64I 中扩展为 jalr x0, 0(x1)

Difftest 实现

RISCV32 寄存器成员顺序定义：先是 32 位通用寄存器，然后是 PC 寄存器。

对比每个寄存器值和下一条指令地址是否一致即可，不过多赘述。

验证效果：尝试修改 inst.c 中几条指令的实现，比如先后修改 add、sub、sw、jal、bne，执行

add：

sub：

sw：

jal：

bne：

构建 NPC-Infra

总体思路

总代码量（整个 C.4 任务）：

本文将介绍一种设计思路：将 NPC 编译为动态链接库 (.so)，然后嵌入到 NEMU 中运行。让 NPC 负责执行指令，而让 NEMU 负责提供内存和外设服务。

核心思想是将 NPC 视为 NEMU 中的一个“执行引擎”。NEMU 原本使用的是解释器引擎，现在我们扩展它，使其能加载 NPC 硬件模型。同时为了最大程度实现解耦合，NEMU 文件夹下仅新增src/engine/npc文件夹，相关修改只涉及 Kconfig、Makefile 中将包含 NPC 目录下的构建脚本，其他修改均位于 NPC 目录下。NEMU 中可以通过 menuconfig 便捷切换后端执行引擎，以达到共用同一套前端设施（SDB, Trace, Device）的目的。

将 NPC 编译成动态链接库

最开始徒手链接源文件瞎折腾了几个小时，后来才发现 verilator 原生支持编译成一个动态链接库（—lib-create）（没好好 RTFM 的后果……），几行命令就搞定：

Difftest 支持

我们可以在 Kconfig 选项中增加以 NEMU 作为 REF 的选项，阅读源码发现此处有 CONFIG_DIFFTEST_REF_NEMU 的宏定义包裹，~~我们只需要在别的地方定义这个宏然后重新定义加载 .so 的加载路径即可~~。（更好的方式直接在 Kconfig 定义路径即可）

组合逻辑调用 DPI-C 接口的问题

运行示例程序时始终会在 Load 类指令发生内存访问越界错误：

使用 gdb 调试发现地址异常出现总是在上升沿时钟调用 eval() 之后出现（期间会出现多次调用的情况）。猜测有可能是组合逻辑毛刺问题。

bit.c

recursion.c

另外由于代码是在 itrace 日志写入成功后加入环形缓冲区，此处出发错误的位置还在 isa_exec_once 函数内部，所以环形缓冲区指向的最后一条指令应该是问题现场指令的前一条。

最后拉起时钟后结算一次信号是为了实时更新指令结束后的寄存器状态，然而这也会导致 DPI-C 函数再次调用：

当前指令会将 a0 所指向的地址的值写入 a0，也就是说，eval() 执行之后 a0 这个寄存器的值会发生变化。

结果很显然，上升沿更新了寄存器状态，但是指令状态没有更新，这时继续调用 DPI-C 函数，从而出现内存异常访问（此处是将 NEMU 的 vaddr_read() 复用，这样就省去了后续再添加 mtrace 的任务）。解决这个问题需要想办法在上升沿之后停止对其继续调用。

那么第一次 eval() 时候也多次调用了该函数，它有无可能意外触发内存访问越界呢？多次试验貌似未发生这种情况，或许和 verilator 调用 C++ 的机制有关，具体原因暂时不得而知。

❓

对于其他指令，add sub 等在第二个eval() 的执行下确实会进行组合路径传播，但是在下一次进入该函数又立即被新指令冲刷掉，而 npc_pmem_write() 本身被时序逻辑调用，显然不会受到影响。

⚠️

后续补充：

在对 NPC 做键盘设备支持时出现了新问题，vaddr_read函数会产生副作用（键盘数据队列移动），这时 DPI-C 函数必须只能调用一次，否则键盘永远读取不到有效值。为了暂时向单周期架构的 NPC 妥协，将 DPI-C 读取函数放在下降沿时钟触发。

参考资料
juejin.cn
https://juejin.cn/post/7024079752801550350
verilator Arguments — Verilator Devel 5.045 documentation
The following arguments may be passed to the “verilator” executable.
https://veripool.org/guide/latest/exe_verilator.html

设备相关

设备的输入与输出

首先主循环中 execute() 函数负责 VGA 显示和键盘状态的更新：

对于其他设备，NEMU 在初始化时会为所有设备注册一个地址空间，设备相关信息（名称、地址范围、回调函数）会占有一个IOMap结构体：

后续凡是对设备地址空间的读写，都会对执行相应设备的回调函数以 “唤醒” 设备运行。以定时器为例子，若指令出现 Load 类，则会调用paddr_read函数，在判断地址属于设备空间后，依次进入mmio_read → map_read → invoke_callback。rtc_io_handler负责向设备私有寄存器写入当前时间值，实际写入和读取的地址则是通过IOMap中的space成员变量进行管理

以上是从模拟器层面理解，接下来从 AM 层面： io_read 完成了几件事：定义设备结构体 → 对应地址读取 → 更新该结构体的值。IO 地址访问产生了 “副作用” （NEMU 中体现为设备回调函数的执行）。

💡

这里是 gcc 的 Statement expression 扩展特性，允许在表达式中使用循环、switch、和局部变量。上述代码最后的结果就相当于__io_param.us

Statement Exprs (Using the GNU Compiler Collection (GCC))

https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

读取定时器寄存器

官方手册明确指定了读取定时器寄存器的顺序，先读高位 → 读低位 → 循环校验，防止读取过程中发生了进位。

如果先读低位（有可能是 0x00000000_FFFFFFFF），读高位就容易读到0x00000001 。

⚠️

勘误：这里的伪指令是 RISC-V 中实际用于读取一个周期计数 CSR 寄存器的，常用于统计 IPC，和这里的 timer.c 的读取语境上完全不同，只不过本质功能都是计数。

在 device/timer.c中，只有读取高位时才触发一次更新，这意味着如果先读取低位，再读取高位，结果是前一时刻的低位 + 当前时刻的高位。

猜测讲义所说的坑有可能就是上述内容。

而讲义中的设备是模拟出来的，只有读取寄存器高位才会触发一次更新，因此不必读二遍校验。

microbench 跑分结果：

异常处理机制

实现流程

NEMU 运行至ecall 指令时，进入isa_raise_intr 函数调用，传入的参数依据手册内容，同时需要对 mstatus 寄存器状态更新以通过 difftest。而后该函数将返回cte_init中传给 mtvec 寄存器的异常处理代码的地址，使得 NEMU 跳转到异常处理区域。

🤖

以下内容由 NotebookLM 根据特权级指令手册内容总结：

触发 ecall（环境调用）指令时，mcause 的值不从任何通用寄存器（GPR）中取得。

根据来源文档的详细解释：

硬件自动设置：当发生陷阱（Trap）进入机器模式时，mcause 寄存器是由处理器硬件自动写入一个代码，该代码用于标识导致陷阱的具体事件。

异常代码的来源：硬件根据 ecall 指令执行时处理器所处的特权模式，在 mcause 的 Exception Code 字段中填入由标准预设的固定数值：

◦ 如果 ecall 来自 U 模式（用户模式），mcause 被设置为 8。

◦ 如果 ecall 来自 S 模式（监督员模式），mcause 被设置为 9。

◦ 如果 ecall 来自 M 模式（机器模式），mcause 被设置为 11。

通用寄存器的角色：虽然硬件不从通用寄存器读取 mcause 的值，但在软件层面，执行环境接口（EEI）通常会规定使用通用寄存器（如 ABI 约定的 a0-a7）来传递具体的服务请求参数或系统调用号。这属于软件处理程序的逻辑，而非硬件填充 mcause 的机制。

总结：mcause 的值反映的是“发生了环境调用异常”这一事件类型，其数值由硬件根据当前的特权级状态直接生成。

异常处理代码对应 trap.S 中的 __am_asm_trap，它主要执行下面几件事：

入栈顺序：gpr, mcause, mstatus, mepc。

其中传入给__am_irq_handle 的参数是通过将栈指针送入 a0 寄存器实现的，栈指针指向整个上下文结构体的首地址。

在回调函数内部，根据 mcause 来确定事件类型（11 属于机器模式下的系统调用），进而根据 a7 寄存器来确定所属事件类型（NEMU 中根据 a7 == -1 确定属于 EVENT_YIELD）。接着事件结构体和上下文结构体被传入用户（AM层）设置的句柄中。

另外需要注意，mepc 位置如果是 ecall 需要由软件进行手动更新 mepc 的操作。

mret之后，如果是 ecall 引起的异常则运行后续指令。

注意到，恢复上下文时并没有加载 sp 寄存器，原因是 sp 寄存器已经通过mv sp, a0完成了上下文切换，它的值正是当前进程的私有栈指针。

让 Difftest 支持异常相应机制

首先需要在 difftest.cc 中对寄存器复制添加相应的支持，在cte_init中实现对 mstatus 的初始化，同时需要对 NEMU 中 dut.c 的寄存器比较函数做出额外的针对 CSR 寄存器的检查。

内核线程的切换（yield-os）

创建上下文给进程管理单元，需要指定 mepc, mstatus, a0 (ABI 规范) 寄存器。

内核进程执行前会从栈中弹出上下文，执行结束（触发自陷）后会将上下文压栈。

对于一个还未执行的进程，gpr 中的值不重要，不需要一开始初始化，进程不会尝试调用一个未经初始化的通用寄存器。内核进程自陷后会保存当前上下文。

切换的上下文是否和原来相同（也即是否要进行切换）由user_handle决定，他接受一个Event和一个Context*参数并返回一个Context* 。在 yield-os 中，user_handle始终将进程切换到另一个。

关于为什么kcontext()要求不能从入口函数返回：普通函数的返回依靠 ra 寄存器，而入口函数依靠 mret 跳转，mret 会根据创建上下文时给出的 mepc 找到入口的地址。如果此时调用 ret 会返回到一个非法的 ra 寄存器指向的地址。

支线

给 NEMU/NPC 添加串口输入支持

核心代码框架基本参考 native 的串口读取、键盘设备的队列，以下分为几个部分介绍：

NEMU 端

串口的输入/输出缓冲区寄存器已经实现，接下来只需要实现 LSR 寄存器的第一位，即该位指示队列中是否有数据。需要在回调函数添加对应的逻辑：

根据头尾指针是否相等设置 LSR 寄存器值。

实现类似 keyboard.c 中读取队列的逻辑。

在初始化串口设备的位置修改终端标准输入流的文件描述符，需要设置为O_NONBLOCK（非阻塞式读取，这部分参考的 native 实现），然后在device_update函数中调用fgetc()函数即可实现无阻塞地读取终端输入字符。

AM 端

根据 amdev.h 中定义的三个串口寄存器，大致需要实现以下逻辑：

新增__am_uart_rx和__am_uart_tx，并在 ioe.c 中补充声明与查找表内容。

修改对应的 Makefile 脚本添加源文件。

为了保持一致性，在 trm.c 中新增getch()函数。

RTT BSP 端

_uart_getc 函数直接依赖 AM 层的 io_read 即可，一行代码。

io_read会实例化一个串口接收寄存器结构体然后通过回调函数从 NEMU 中的串口缓冲区获取一个字符，并填充该结构体。

NPC 侧逻辑大致差不多，不过多赘述。

🛠️

NEMU/NPC 下运行 RT-Thread 输入命令回车后终端会回显一次该命令本身，该现象对于功能暂无影响，后期再进行进一步处理。

简单优化 NEMU 性能（使用 perf 工具）

perf 是一个系统级性能分析工具，可用于评估代码性能，执行下列命令记录红白机模拟器运行时性能数据，退出后会在当前目录生成 perf.data 文件：

在此之前需要运行以下命令临时开放内核权限：

然后会进入一个图形化交互界面，选择第二项 CPU 性能核（采样数最多）

第二个界面可以看到性能热点列表，排名第一的占用性能 31.07%。

第三个界面有一些常用选项：

Annotate ：如果你选中具体的函数按这个，perf 会尝试反汇编该函数，展示哪一条具体的汇编指令最耗时。

Zoom into ... thread：只看当前线程的性能开销，屏蔽其他线程的干扰。

Zoom into [vdso] DSO：放大看共享库。选择这个后，列表里就只剩下属于 [vdso] 的事件了。

反汇编可以发现耗时严重部分位于0000000000000869 <__vdso_gettimeofday@@LINUX_2.6-0x597> ，这部分正是 NEMU 中的获取系统时间的底层函数，位于device_update函数内部。

CPU 每执行一次指令都会调用一次 device_update 。

于是我们可以降低device_update 函数的调用频率，最简化的实现如下：

实际效果有较大提升，优化前操作跟手性差，声音输出较为杂乱。优化后更加流畅，声音更加连贯：（实际测试发现至少每隔 3 条指令执行一次get_time()可以使得该部分性能消耗排名降至第二）

优化前

间隔 4 条指令

NPC 性能优化（ Verilator ）

Kconfig 中配置波形生成开关，并在软件驱动侧使用宏包裹波形相关逻辑。关闭波形生成提速大约 3 倍左右。使用 —trace-threads 1开启独立线程波形追踪，速度提升大约 80%。

开启链接时优化 -flto。

关闭断言 —no-assert。

开启 -O3 优化，速度提升较明显。参考手册部分：

多线程：开启多线程速度反而下降。

🤖

Gemini-3.1-pro总结内容：

1. 如何开启

编译参数：在调用 Verilator 时添加 -threads （N 为期望的物理线程数，通常不超过 CPU 核心数）。

代码修改：零修改。Verilator 会自动在底层的 C++ 代码中插入多线程调度和同步锁，无需修改 Testbench（main.cpp）。

2. 底层原理

依赖图分析：Verilator 会在编译阶段分析 Verilog 代码的信号依赖。

任务拆分 (mtasks)：将互不依赖的逻辑块拆分给不同的线程并行计算。

同步屏障 (Barrier)：在每个时钟边沿，跑得快的线程必须停下来等待跑得慢的线程，全员算完再进入下一周期。

3. ✅ 适合开多线程的场景（正收益）

大规模设计：复杂的 SoC（包含 CPU、GPU、DDR 控制器等独立大模块）。

多核处理器：各个核心之间大部分时间独立运行，交互极少。

高度并行的算法：如多路独立运行的图像/信号处理流水线。

4. ❌ 绝对不要开多线程的场景（负收益/反向优化）

单核小规模 CPU（如一生一芯 NPC）：内部 ALU、译码、取指之间组合逻辑强耦合，无法拆分出独立的大块逻辑。

长依赖链：信号 A->B->C 串行依赖的纯组合逻辑。

重度使用 DPI-C：默认情况下，遇到 DPI-C 调用时多线程会退化为单线程排队执行，且跨语言同步开销极大。

后果：线程花在“互相唤醒和等待锁”上的时间，远超并行计算省下的时间，导致比单线程还慢。

B 阶段

评估单周期NPC的主频和程序性能

运行 microbench 的 train 规模测试，获得关键信息total guest instruction 为 195 142 896，对于单周期 CPU 来说这就是运行 microbench 的时钟周期。

在进一步评估之前，先使用 sv2v 工具把 sv 全部转化到一个大的 verilog 文件中，因为 yosys 对 sv 一些高级语法特性支持不太好。

yosys 综合后估算最大主频 2.36 GHz，如果固定这个主频下运行 microbench 大约只需要 80 ms，实际肯定不会是这么多，讲义中也提到了综合器优化等等相关的一系列问题。

重构 NPC

整体结构

按照经典五级单元重构基于分布式消息控制的处理器，并注入 SVA 语法，bind 分离可综合代码与验证代码，实现功能解耦。

问题记录

5.038 之后的版本断言是默认开启的，要禁用需要显式的参数 —no-assert

报错 %Error: unknown:0: Testbench C called 'dpi_get_pc' but scope wasn't set, perhaps due to dpi import call without 'context', or missing svSetScope. See IEEE 1800-2023 35.5.3. 查询 Verilator 手册得知需要在模块实例化之后，函数调用之前设置作用域：

指令译码在 default 分支使用的立即断言会在复位时误触发，于是添加断言门控并定义成宏函数，顶层引出 inst_valid 信号由 C++ 控制：

多周期 NPC

核心要点

从单周期迈向多周期处理器之后，C++ 侧的 npc_exec_once 的任务由翻转一次时钟变成了正确执行并提交一条指令，原本单周期做出的一些约定与妥协不能再使用。为最大程度解耦合，需要对于 NEMU 和 NPC 的交互做出一些约定：

NEMU 的 isa_exec_once 外部理应认为 NPC 的指令是顺序提交的，这一点也符合 gdb 视角看真实运行的 CPU。NEMU 需要拿到正确的 dnpc 以及执行完一条指令后的所有新的架构状态。

npc_exec_once 依然是提交一条指令，get_regs_from_npc 负责更新 NEMU 中架构状态（gpr 和 csr）。即退出该函数后，NEMU 需要看到 NPC 执行完成指令后所有的提交的新状态。

因此只要严格遵守运行完 isa_exec_once 之后，等效顺序执行一条指令并完成所有状态更新，即可适配 NEMU 的所有基础设施。

问题记录

波形记录：

在 ebreak 指令之前一刻记录的波形是 clk = 1，时刻是 4879 ps，但是实际打开波形图发现 4878 ps 低电平之后就没有记录了。查询得知原因不是仿真没执行到，而是最后一个采样点正好落在 trace文件结尾，例如最后一条记录在 4879 ps。波形查看器展示的是状态在一个时间区间内的持续情况，也就是 [当前采样时刻, 下一采样时刻)。如果 4879 ps 已经是最后一个采样点，那么这个最终状态虽然被记录了，但它后面没有“下一时刻”来形成可见宽度，所以在 Surfer 里通常看起来像“没有画出来”。

指令提交与 Difftest：

之前由于是手动送指令，可在指令周期结束后手动拉高一次时钟更新架构状态。多周期则将更多主动权交还给 NPC。最开始是在第一条红线处作为指令提交点（状态采样点均在右侧），该处对于非 load 类指令属于已经拿到指令译码，准备写回但还没写回成功；对于 load 类指令属于已经拿到了 load 数据，准备写回。因此如果在该处提交，对于 snpc 和 dnpc 的值是有效的，但是架构状态仍然没有更新，仍是上一条指令执行完毕的状态，不利于 SDB 还有 Difftest。故考虑将提交处放在第三根红线处，此时架构状态已经更新，但是 pc 也随之更新，因此在 clk=0 还有 clk =1 之间提交指令（第二根红线处）。

内存读写副作用

由于 load 类型指令需要一个额外周期，此期间如果继续保持读使能拉高，就会重复触发 DPI-C 函数，会触发一些对于设备访问的副作用（例如重复触发出队列缓冲区，这个问题此前已经提到过）。在数据已经读出后（state == LS_GET），需要拉低读使能。

AXI 总线接入

避免握手的活锁和死锁

相关内容主要在 Chapter A2 AXI transport 章节，重点关注 A2.3 Valid-Ready transport，包含传输规范以及不同通道的握手依赖规范。以下内容由 NotebookLM 根据手册内容总结：

单通道握手信号的基本约束

VALID 不得依赖 READY：发送端在产生 VALID 信号时，绝对不允许等待接收端的 READY 信号响应后再断定是否有效。如果双方都在等待对方的信号，就会发生死锁。

READY 可以依赖 VALID：接收端可以等待检测到 VALID 信号后再断定是否产生 READY 信号。

推荐 READY 默认置高：协议建议 READY 信号的默认状态为 HIGH，这样传输可以在单周期内完成，提高效率。

信号稳定性要求：一旦 VALID 信号被置为 HIGH，它必须保持稳定，直到握手成功（即 VALID 和 READY 同时为 HIGH 的时钟上升沿）。在此期间，地址、数据或控制信息也必须保持不变。

READY 信号的灵活性：即使 READY 已置高，如果在 VALID 变为高电平之前，接收方有理由取消准备就绪状态，则允许将 READY 拉低。

通道间依赖关系约束

1. 读事务依赖关系

必须遵守：从机必须等到 ARVALID 和 ARREADY 同时置高（即地址握手完成）后，才能置高 RVALID 开始返回数据。

严禁依赖：

主机不得等待 ARREADY 置高后再置高 ARVALID。
从机不得等待主机置高 RREADY 后再置高 RVALID。

2. 写事务依赖关系

主机端独立性：主机置高 AWVALID 或 WVALID 时，不得依赖于从机端的 AWREADY 或 WREADY。

从机端响应约束：

从机可以等待 AWVALID 或 WVALID（或两者）之后再置高 AWREADY 或 WREADY。
从机必须等到写地址和所有写数据都握手完成（且 WLAST 为高）后，才能置高 BVALID 发送写响应。这是为了确保写响应仅在事务彻底完成后给出。

严禁依赖：从机不得等待主机置高 BREADY 后再置高 BVALID。

Single-headed arrows point to signals that can be asserted before or after the signal at the start of the arrow.

Double-headed arrows point to signals that must be asserted only after assertion of the signal at the start of the arrow.

参考手册
IHI0022L_amba_axi_protocol_spec.pdf
2 MiB
IHI0022H_amba_axi_protocol_spec.pdf
2.2 MiB
值得注意的是，某一个手册版本之后移除了 AXI4-Lite 相关内容，只能去更旧版手册找。

单次阻塞式事务实现

这次主要做的事情，是把 IFU 和 LSU 都接到 AXI4-Lite 总线上，并分别连到指令侧和数据侧的 DPI 从机模型。设计选择了最简单的单次事务阻塞，目的是快速跑通整个流程，学习意义大于实用意义。

总体结构

接口解耦合 & 协议转换

起初是觉得将巨大的 AXI 状态机硬塞进 CPU 的模块中显得非常臃肿，遂想实现一个接口转换，面向内部实现一个精简化接口，并在外部实现一个 AXI 协议转换的模块，例如 Tilelink。

至于从机，当前就直接和 DPI 函数调用地点放在同一个位置。

它的限制也很明确：

每个桥只支持 one outstanding

IFU 是 blocking fetch

LSU 是 blocking LSU

没有 request queue / store buffer / ID / out-of-order completion

📝

自己写的随机延迟测试用模板

仲裁器实现

这里直接对 AXI4-Lite 主机接口进行仲裁，由于目前 IFU 和 LSU 目前不会同时请求访问，所以按照固定优先级模式分配总线，谁的请求来了就把总线仲裁给谁。

Yosys 评估时序

评估最大主频为 397.867MHz，之前做第一次评估到 GHz 多半有点问题，可能是 sv2v 没转换完全。。。

总线互联矩阵

总体架构

xbar 的实现逻辑比较简单，直接根据上游的请求信号地址决定路由到对应的从机。如果地址译码不匹配任何一个从机，将会路由到 xbar 内部一个虚拟从机，直接返回 DECERR 的错误信号。目前 AXI 主机的实现是接受到错误信号直接触发立即断言终止仿真进程。

UART 和 CLINT 作为独立从设备挂在 xbar 下

其他暂时没有单独建模的 MMIO 地址，先路由到 dpi_sim_sram，由内部的 DPI 函数处理其他设备的访问

对于 MTIME，讲义提到需要根据仿真速率修改 AM 侧的代码，使得 io_read 读出的 us 数更接近真实的时间流逝。实际运行发现 mtime 读秒没有远远大于物理时间流逝，且随着各种调试开关仿真速率会时刻变化，故不对 AM 端侧代码进行更改。

Difftest bug

在开启 difftest 的情况，由于之前访问设备的时候通过 dpi 接口 paddr_write，而内部如果是设备访问会设置 is_skip_ref，从而跳过指令对比。但是现在 sim_uart.sv 将 npc 的串口访问路由到 rtl 内部，副作用由$write()完成，因此 difftest 会对设备访问指令进行检查，又由于参考模型 ref 不支持设备，导致 out_of_bound 触发物理地址越界。解决方案通过 dpi 接口设置一个跳过标志位即可。

ysyxSoC

输出自动刷新

UART 设备通过 $write() 系统任务输出单个字符，这时需要启用 --autoflush 选项，但官方手册仍然建议在 C++ 主循环中偶尔调用 fflush(stdout)，启用该参数可能降低运行性能。

添加 AM 运行时环境

重新梳理 abstract-machine 文件夹下的 script 调用

终端输入 make ARCH=riscv32e-npc run 之后：

生成一个 Makefile.xxx，$(ALL)用于选择参与编译的源文件对象

核心入口是 abstract-machine/Makefile

ARCH 必须等于 abstract-machine/scripts/ 下某个 .mk 文件的文件名，否则会引发报错。之后内部会对 ARCH 的名称进行拆解，例如：

ARCH=riscv32e-npc -> ISA=riscv32e, PLATFORM=npc

ARCH=riscv32-nemu -> ISA=riscv32, PLATFORM=nemu

依据解析出的 ARCH，包含对应的 .mk 脚本：

ARCH=riscv32e-npc 时，自动包含 scripts/riscv32e-npc.mk

ARCH=riscv32-nemu 时，自动包含 scripts/riscv32-nemu.mk

而这些 script/$(ARCH).mk 包含了 $(ISA).mk 和 $(PLATFORM).mk 以及私有的源码和编译参数。

文件结构组织

有了上面的分析，如何添加 AM 环境相关的文件就比较清晰了，这里先按照最小化可以运行的配置添加，后续再逐步新增设备/功能的支持。

在 am/src/platform/ 和 am/src/riscv/ 下添加两个 ysyxsoc 的文件夹：

新增 am/scripts/platform/ysyxsoc.mk 和 am/scripts/riscv32e-ysyxsoc.mk 两个 Makefile 脚本，内容大致参考 NPC 和 NEMU 的，只修改源文件列表和链接脚本路径。

链接脚本和启动代码详解

启动代码：

第一行定义 section name 为 entry，”ax” = alloc + executable 运行时需要分配/加载到内存 + 可执行。

定义 _start 为全局符号，这样链接脚本中的 ENTRY(_start) 还有 LDFLAGS 中的 -e _start 才能找到该符号。

第三行，指定 _start 的类型是 FUNC

_start：主要就是分配栈空间，然后进入 trm_init 函数，执行 main 后根据 ret 触发 trap。

链接脚本

定义入口为 _start

MEMORY 字段划分物理内存空间，后面 > mrom 代表将该 section 划分到对应的物理空间

相比于原本的 linker.ld 主要修改了栈指针和堆地址，_stack_top 从 sram 基地址开始连续划分 4 KB 的空间，剩余的空间作为 heap

内存布局如下：

值得注意的是，因为此时 .data 和 .bss 段被分配到 mrom，所以 全局变量不支持写入。

Program header 定义了程序可加载段，loader 解析 elf 文件的时候会用到（操作系统执行 elf 可执行文件、OpenOCD 烧录程序），对于当前阶段来说也并不是必须的，详见：

ELF文件解析（一）：Segment和Section - JollyWing - 博客园

ELF 是Executable and Linking Format的缩写，即可执行和可链接的格式，是Unix/Linux系统ABI (Application Binary Interface)规范的一部分。 Unix/Linux下的可执行二进制文件、目标代码文件、共享库文件和core dump文件

https://www.cnblogs.com/jiqingwu/p/elf_format_research_01.html

支持全局变量的写入操作

fib 测试中使用并写入了 全局变量，而在上一个 linker.ld 中，.data 被分配到了 mrom，因此触发断言 mrom 拒绝写入。为了支持全局变量的写入，很显然应该将 .data 放入 sram，但是修改完之后又遇到了一个问题：

.bin 镜像达到了 200 多 MB，最终应该导致加载时 pmem 溢出了。

关于这个问题，下面的网页都有提到：

关于STM32CubeIDE链接脚本的小问题 | MCU加油站

越来越多的客户在使用STM32CubeIDE作为集成开发工具。STM32CubeIDE在编译代码的时候，用到了链接脚本。通常情况下，STM32CubeIDE会自动生成默认的链接脚本。但是有些情况下，例如，用户程序需要定义一些特别的段来放置代码或者数据的时候，我们就需要修改链接脚本文件。

https://mcu.eetrend.com/blog/2021/100555717.html

Raw binary file generated by objcopy is too big

Already read this but cannot solve my problem. huge binary files with objcopy For some testing need. I have to add following link script when link. .section_test 0x11323000: { *(.section_test) ...

https://stackoverflow.com/questions/19019199/raw-binary-file-generated-by-objcopy-is-too-big

大概意思就是，.text 段被分配在 mrom 中，.data 被分配在了 sram 中，表面上看没有什么问题，实际上：

“GNU Objcopy 工具生成 BIN 文件的过程，实际上就是把 ELF 文件中各个定义了 LOAD 属性的 SECTION 按照 LMA 的先后顺序提取出来，写入 BIN 文件中。SECTION 的地址如果不是连续的，间隔部分则会填充 DUMMY 或指定的数据。所以 BIN 文件的大小为最大 LMA 加上对应的 SECTION 的 Size。”

查看 elf 文件的 section 地址，由于 .rodata 和 .data 之间的间隔都被 DUMMY 数据填充了，所以会生成巨大的 BIN 文件。BIN 文件不自带地址属性，这样才能保证实际的数据加载到对应的物理地址中去。

调整内存布局如下：

.data 段的初始化数据保存至 mrom 区域（LMA），运行时进入主函数前需要由 bootloader 加载进 sram 区域（VMA）。.bss 段不需要加载进入 .bin 文件中，直接由 bootloader 在其对应的 VMA 位置清零即可。堆和栈的大致布局还是和之前一样。这样 .text 段和 .data 的数据存放是连续的，不会造成 .bin 大小异常的问题。

bootloader 的实现很简单，在 trm.c 创建一个 C 函数分别调用 klib 的 memcpy 和 memset 加载 .data 和 .bss 段即可，在 _start 中添加 call __boot_loader 即可。

大部分 cpu-test 测试都通过了，但是有极个别出现报错（wanshu and string）。打开 difftest 发现，报错指令均为 lbu 。后来意外发现一个现象，每次触发 difftest 断言的时候，日志中的 Expect 值是随机值：

NEMU 上电时会随机初始化物理内存区域的数据，由此可以推断，这一块内存区域自运行后一直没有被写入过。简单测试中不涉及内存的分配与释放，所以不可能存在访问非法内存的问题，大概率是 bootloader 没有正确从 LMA 加载到 VMA。

查看两个报错 elf 的节头表：

断言指令 lbu 访存地址恰好分别是 0x0f000000 和 0x0f000018 ，访问 section 为 .sdata.*，而 linker.ld 中 .sdata.* 并未作为 Input Section，因此最终加载内存时没有将这部分数据内容正确搬运，最终的 Output Section 中不包含该数据段。

.sdata section 核心目的：把较小的全局/静态对象集中放在可由一个专用基址寄存器加短位移访问的区域，从而减少取地址指令数量，缩短代码，有时也提高访问速度。

在 ysyxsoc.mk 中 LDFLAGS 追加 --print-map 参数查看链接器的链接过程：

主要关注舍弃的输入节，在 ysyxsoc.mk 中有以下参数：

两个编译参数为每个全局/静态数据对象/函数分配独立的 section，这样才能配合后面的链接参数精准做 section 级别的垃圾回收，剔除未使用的函数/变量代码。

symbol lookup error 问题解决记录

在一次关闭设备选项运行 NPC 时，遇到报错：

使用 LD_DEBUG=symbols 来查看 compressBound 的查找过程：

可知，关闭 Device 选项导致 libz.so.1 库依赖缺失，更具体的，相关符号声明位于一个叫 zlib.h 的头文件中。

后面查询得知，verilator 在执行 --lib-create 参数时不会自动添加 $(LDLIBS) 的链接参数，其中包含 -lz 以及多线程和原子操作的支持库（也就是说多线程在此前可能也没有真正起作用？）。只有在添加 --exe 参数生成最终可执行文件的时候，verilator 才会链接所有可用的第三方库。

临时的解决方案是在 V{top_module_name}.mk文件构建 .so 目标中末尾追加 $(LDLIBS)：

使用 nm 命令查看 libnpc.so 中的符号表：

U compressBound@ZLIB_1.2.0 U 表示这个库调用了该函数/变量，但是 在这个库自己的代码里没有它的实现。它期望在运行时，由加载它的主程序或者其他的动态库提供。

Flash XIP

状态机设计：is_xip 标志拉高表明 CPU 通过 APB 总线访问 Flash 的地址区域，状态机启动，在 SETUP ↔ ACCESS 状态之间流转依次向 5 个 SPI 内部寄存器发出写入请求。等待 SPI 中断信号拉高之后发起对 SPI Master RX0 寄存器的读请求，取得应答信号后拉高 APB 的 pready 信号，此时 APB 总线上的读数据有效。

📝

这里其实明显还可以优化一下，第一次 state == SETUP && reg_cnt == 5 之后设置一个 cfg_done 的标志位，reg_cnt 复位值将被设置为 3，后续有 flash 请求时直接写两个寄存器 TX1 和 CTRL.GO 即可。

附上非 XIP 的软件流程：

在完成 XIP 内容的时候有两点容易忽视：

flash.v 中会将读出数据的字节序翻转一次，符合小端内存按照地址递增读出字节的效果。例如仿真环境中内存一个字的数据是 0x11223344 ，SPI Master 的 RX0 中最后将会是 0x44332211。XIP 还需要做一次字节序调整。

当 SPI Master 的 ASS 控制位为 1 时，控制器会在传输期间自动驱动已选中的 SS 信号：传输开始后拉低对应片选，传输结束后释放片选。但 ASS 只负责自动控制片选时序，并不负责选择哪个从设备。因此软件仍需要先写 SS 寄存器，指定本次传输要选中的 SPI 设备。

PSRAM

状态机设计如下：

状态转移主要来源于一个全局 sck 周期计数器 cyc_cnt

从 Flash 加载程序到 RAM

按照加载数据段的方法，对 linker.ld 作如下修改：

很显然这有一个致命的问题，一开始从 Flash 取指令加载代码段到 SRAM，然后跳到 SRAM 取指令，又来一次 bootloader …… 循环往复。期望的效果应该是，bootloader 之前的程序仍然存放在 Flash，用户代码将会被 bootloader 搬运到 SRAM 中执行，因此需要新增一个数据段，更正 linker.ld 和 start.S 启动代码。

入口放在 .boot 段，分配临时启动栈，调用 _boot_loader 将用户代码段和数据都放入 SRAM 中，然后直接跳转到 _main（原来的 _start），后丢弃初始栈。

在 linker.ld 的 Output Section 添加 .boot 段：

运行发现取到了非法指令：

查看反汇编发现 _boot_loader 还有memcpy 和 memset 这类 klib 函数也是被分配到了 .text 段，于是使用 __attribute__ 显式声明，并为 boot 程序准备专用的两个内存操作函数。

但事实上仍然有部分程序运行不成功。查看反汇编文件发现一些程序的入口函数 _start 并没有被排在最前面，SDB 调试也可以发现第一条指令是从 boot_memcpy 开始执行的：

搜索相关资料后发现，入口函数虽然已经明确了为 _start ，分别在两处（linker.ld: ENTRY(_start) 以及链接参数 -e），但并不保证生成的二进制文件一定被排在前面，只是指定了 elf header 的一个值。

objcopy can be used to generate a raw binary file by using an output target of ‘binary’ (e.g., use -O binary). When objcopy generates a raw binary file, it will essentially produce a memory dump of the contents of the input object file. All symbols and relocation information will be discarded. The memory dump will start at the load address of the lowest section copied into the output file. objcopy 可通过使用输出目标“ binary ”来生成原始二进制文件（例如，使用 -O binary ）。当 objcopy 生成原始二进制文件时，它本质上会生成输入对象文件内容的内存转储。所有符号和重定位信息都会被丢弃。该内存转储将从复制到输出文件中的最低段的加载地址开始。 —— 源于 objcopy 官方手册

在一些嵌入式设备中，硬件复位时会读取中断向量表，正确找到程序的入口地址，因此入口地址不必是指令存储器的最开头。这里要注意区分 “硬件复位地址” 与 “程序入口地址”。

Effect of ENTRY directive in Linker Script on Cortex-M4 binary

My initial understanding of ARM Cortex-M4 bootstraping sequence was that when MCU was started, it loaded pointer from Reset_Handler IVT and then jumped to that address to start configuring the processor.Later on when I started doing some stuff on Linker Script, I noted something called ENTRY keyword which by GNU Linker documentation specified that it defined starting point of binary. So which one is it, IVR or ENTRY? That’s what we are going to tackle in this post.

https://unix.com.hr/2022/06/05/effect-of-entry-directive-in-linker-script-on-cortex-m4-binary/

而对于目前的裸机程序就要求硬件复位地址等于程序入口地址。

具体的解决方法是：给 .boot 段的入口单独分配一个 section，然后在 linker.ld 的 .boot output section 里把 .boot.entry 明确排在其他 .boot 段之前。

二级加载思路比较简单，在 _start 调用 _fsbl 把 _ssbl 相关的逻辑全部搬运到 SRAM，再直接跳转到 _ssbl_entry ，最后跳转到 _main。每次跳转都可以丢弃当前栈，因为加载阶段完成后不再需要返回了。

linker.ld 将 fsbl 和 ssbl 单独划分 section：

运行 RTT 加载时间很长，查看符号表：

假设按照每秒 10000 条指令估算，大概需要 20 分钟。于是想到之前在 RTT 中通过命令运行了一些 AM 程序，这部分程序很可能占用了较大空间。

🚨

此外，上面表明 .srodata.* 没有被放入统一的 output section 中，这会导致 bootloader 不加载这些数据。

SDRAM

SDRAM 的逻辑相较于之前其他的存储器要复杂一些，所以单开一小节对控制器代码和仿真模型实现做一些记录。

控制器部分

模式寄存器值

A12 ~ A10：保留段，设置为 0

A9：可编程突发长度模式，只决定写入是否突发，读出仍然为突发

A8 ~ A7：Standard Operation

A6 ~ A4：列选通延迟，注册一个 READ 命令到输出数据可用之间的时钟周期延迟为 2。

A3：顺序突发模式

A2 ~ A0：一次突发两个 16 bits，即 4 bytes

APB 地址解码

上面三行等效为：

列地址取总线上地址的九位，寻址范围 512

行地址取总线上 [24:12]，寻址范围 8192

块地址取总线上 [11:10]，寻址范围 4

⚠️

此处需要明确 CPU 总线地址到 SDRAM 内部地址的转换。通常内存按照字节寻址，这款型号的 SDRAM 内部则是按照半字寻址。

如果把地址进行线性映射（DPI-C 访问数组），则是 {row, bank, col} ，索引走完一行之后跳到下一个 bank，走完所有 bank 后回到第一个 bank 的下一行，周而复始。

对于位扩展，控制器的地址切分要改成这样：

因为位扩展后 SDRAM 相当于按字寻址，所以总线地址清零低两位后再除以4。相应的，DPI 函数也要乘以 4 映射至按字节寻址的地址。NEMU 中仍然把扩展后 32MB * 2 的空间线性映射成数组，便于 SDB 访问。

字扩展就更容易了，直接取总线地址上的第 26 位作为片选信号。此外还需要修改控制器行缓存的数量。但是考虑到做字扩展直接修改 verilog 代码比较复杂，必然还会在 Makefile 中添加大量的 sed 命令，所以还是直接选择修改 chisel 里面的端口定义。之前有点被讲义误导了，其实就算只写 verilog 也是可以修改端口定义部分的。

仿真模型

跨行访问测试中出现错误，波形中发现问题。

首先对 bank3 row0 写入一个数据：

然后对 bank0 row1 写入一个数据：

由于是跨行访问，两次均发送 ACTIVE 命令。

然后紧接着读取第一个地址，控制器并未发送 ACTIVE 命令，而是直接发送了 READ。而仿真模型中 addr_q 仍然是前一个行地址，读出无效数据。

RTFSC 控制器，想查看一下发出 ACTIVE 命令的条件：

从代码可以看到，当前行地址如果已经在 active_row_q 被记录视为行命中，不会再次发送 ACTIVE 命令。控制器 每个 bank 都有独立的 row buffer，而自己的仿真模型仅仅实现了一个 row buffer。

bug 原因找到。

接入 NVBoard

首先需要添加 NVBoard 的构建规则，主要参考 nvboard/example 项目。

基本构建流程是将 NVBoard 源文件编译成静态库 nvboard.a ，作为 verilator 编译的依赖之一。由于我这里是需要将 NPC 编译成动态链接库，所以需要在 nvboard 的 CXXFLAGS 加一条 -fPIC 。最后在 npc_api.cpp 中添加 nvboard 初始化、引脚绑定、状态更新、退出。

python 脚本会读取约束文件，生成一个封装了所有引脚绑定的 cpp 文件，这个文件也需要添加到 verilator 的依赖项。

测试过程中遇到的一些符号/文件未找到、未定义等问题基本都是源文件或者编译参数、链接参数不全导致的。

Uart 手册中提到：

The value set should be equal to (system clock speed) / (16 x desired baud rate)

实际波特率等于时钟频率除以 16 再除以用户设置的 divisor，而 nvboard 中实际波特率就是时钟频率除以 divisor。因此 divisor (nv) = 16 * divisor (rtl)。此外还需要注意，nvboard_update() 应该时钟每翻转一次就调用，而不是提交一条指令才调用。

串口输入大部分内容其实已经在 C 阶段最后的支线任务完成了，当时是通过 NEMU 底层设置终端文件描述符，非阻塞从终端获取字符输入的。这里则是通过 nvboard SDL 监测键盘输入事件，获取到字符按照 uart 标准协议发送到 ysyxSoC 顶层的 uart_rx 中。软件再读取 uart 的寄存器来获取到键盘输入到内存中。

最后终于完成 SoC 计算机系统：~~完结撒花！~~

性能：大约 48000 insts/s，microbecn test 规模

使用 remake 工具分析复杂 Makefile

Fri, 09 Jan 2026 00:00:00 GMT

使用 Remake

ysyx-workbench 里面的 Makefile 通常都十分巨大，直接 RTFSC 十分痛苦。后来通过 AI 搜索到一个叫 Remake 的工具，可以单步运行 Makefile 文件，跟踪 Makefile 的内部层层调用。

Remake - GNU Make with comprehensible tracing and a debugger

remake is an enahanced version of GNU Make that adds improved error reporting, better tracing, profiling and a debugger.

https://bashdb.sourceforge.net/remake/

以一个简单的 Makefile 为例子：

终端执行remake -x或者remake --trace 可展示 Makefile 的详细执行流程：

如果执行指令时报错，会打印出更详细的错误信息：

如果需要更加精简的日志输出，执行：

这将会使用 make 基础调试模式，并静默 make 时执行的 shell 命令。

单步调试

remake 可以像 gdb 工具调试 C 语言程序一样对 Makefile 执行单步调试，输入：

即可进入单步调试状态，支持打印变量、查看调用栈、设置断点等，大部分指令和 gdb 是一样的，不过多赘述，可查看常用指令帮助。以下有几个除了step和next的常用指令：

expand (x) ——原地展开变量

target [ Target-NAME ] [ info1 [ info2 … ] ]——查询目标，可以查看自动变量等信息

where, backtrace, bt, T ——查看当前调用栈

可视化

首先清理旧的构建，然后执行上述命令打开报告，可以看见树状图展现了清晰的构建依赖关系：

顺带，Kcachegrind 也可以查看 Valgrind 平台的性能分析工具 Callgrind 生成的报告：

记录程序运行时的函数调用层次关系

执行指令的个数、指令与源码行的对应关系

时间占用的性能分析，执行哪个函数任务花费的相对时间最多

……

以 ysyx-workbench 的 NEMU 运行分析为例子：

参考资料

性能优化之vallgrind之callgrind分析瓶颈 - 懒人李冰

Callgrind 概述主要功能基本使用方法高级使用方法生成多个 profile 文件限制收集事件的范围 Callgrind 命令行选项 dump 生成选项 activity 选项 data collection 选项 cost entity separations 选项 …

https://lazybing.github.io/blog/2019/04/15/profiler/

KCachegrind

Callgrind uses runtime instrumentation via the Valgrind framework for its cache simulation and call-graph generation. This way, even shared libraries and dynamically opened plugins can be profiled. The data files generated by Callgrind can be loaded into KCachegrind for browsing the performance results. But there is also a command line tool in the package to get ASCII reports from data files without the need to use KCachegrind.

https://kcachegrind.github.io/html/Home.html

Remake - GNU Make with comprehensible tracing and a debugger

remake is an enahanced version of GNU Make that adds improved error reporting, better tracing, profiling and a debugger.

https://bashdb.sourceforge.net/remake/

仿真过程中的竞态条件

Fri, 10 Oct 2025 00:00:00 GMT

🤔

本文将讨论一个很容易困惑 Verilog 新手的问题：在行为级仿真中，如果 testbench 恰好在时钟边沿所在的同一仿真时刻修改输入，时序逻辑究竟会采到修改前的值，还是修改后的值？

📝 问题导入

以下面模块为例。该模块实现奇偶校验功能：每当时钟上升沿采样到 in 为高电平时，odd 翻转一次：

testbench 关键逻辑如下：

使用 Icarus Verilog 仿真后，可以得到如下波形：

从波形上看，in 和 odd 似乎在同一个时刻发生变化：in 被置为高电平后，odd 也在该时钟沿完成了翻转。

但这里需要注意，时序逻辑并不是固定采样“前一个周期的值”，而是在当前有效时钟沿采样该时刻所能观察到的输入值。现在的问题是：testbench 对 in 的阻塞赋值与 DUT 的 always @(posedge clk) 在同一仿真时刻被触发，二者究竟谁先执行？

⚠️

在不添加显式延迟或回标时序信息的 RTL 行为级仿真中，通常不会体现门传播延迟、布线延迟以及触发器的 clock-to-Q 延迟。因此，不同信号可能在波形中显示为同一个仿真时刻发生变化。

但这种“同一时刻”并不代表它们在仿真器内部同时完成更新：同一个仿真时刻还会被划分为不同的事件调度区域。delta cycle 只是仿真器用于组织零时间事件的调度概念，不对应任何真实的物理时间，也不能用于表示建立时间或保持时间。

在真实同步电路中，输入数据应在时钟有效沿前后分别满足建立时间和保持时间要求，而不是在时钟沿附近任意跳变。

🤗 阻塞/非阻塞赋值

A blocking procedural assignment statement shall be executed before the execution of the statements that follow it in a sequential block (see 9.8.1). A blocking procedural assignment statement shall not prevent the execution of statements that follow it in a parallel block (see 9.8.2)
The nonblocking procedural assignment allows assignment scheduling without blocking the procedural flow. The nonblocking procedural assignment statement can be used whenever several variable assignments within the same time step can be made without regard to order or dependence upon each other.
—— IEEE Std 1364-2005，procedural assignment 相关章节

总结一下：

= 是阻塞赋值。在同一个顺序过程块中，当前赋值完成后，才会继续执行该语句之后的过程语句；因此，后续语句读取到的是已经更新的左值。

需要注意，“阻塞”描述的是仿真过程中的程序执行语义，并不表示综合后的实际硬件会像软件一样逐条等待执行。综合工具最终生成什么电路，取决于赋值所在的过程块、敏感条件以及整个 RTL 结构。

例如，级联加法器形成的进位链需要经过一定的物理传播时间才能稳定，但这是组合逻辑传播延迟造成的，而不是阻塞赋值语义本身造成的。在 fork...join 创建的多个并行进程之间，一个进程中的阻塞赋值不会阻塞其他并行进程。

<= 是非阻塞赋值。语句执行时会先计算右值，然后将左值的更新安排到非阻塞赋值更新区域（NBA region）。如果没有显式延迟，这次更新仍发生在当前仿真时刻，只是晚于当前 Active 区域中的事件，而不是进入下一个时钟周期，也不一定进入下一个仿真时间点。

非阻塞赋值被广泛用于时钟驱动的时序逻辑中，可以让同一个时钟沿触发的多个寄存器先读取旧值，再统一完成状态更新，从而降低代码执行顺序带来的影响。

⏱️ 事件调度模型

🍀 time slot 和 delta cycle

仿真时间单位与精度： timescale 用于规定延迟数值的时间单位和舍入精度。

time slot：指某一个确定仿真时间点上需要处理的全部事件。例如仿真时间为 10 ns 时，该时刻触发和派生的事件都属于 10 ns 这个 time slot。众所周知，硬件电路是全并行的，而仿真器作为软件只能通过串行执行指令模拟硬件行为，由此诞生了仿真器的事件调度模型。每一个时间片内有一系列按照一定顺序执行的关键区域（Region），在每一个时间片的出口将完成所有事件的更新。

delta cycle（零时间调度过程）：它不是一个比仿真精度更小的物理时间单位，而是仿真时间不推进时，对零延迟事件进行排序和处理的调度过程，通常无法在仿真波形中直接显示。在同一个 time-slot 内可以有无穷个 delta-cycle，delta-cycle 会跟随事件迭代而增加。例如在时间节点 100 ns，有 ABC 三个信号需要驱动，它们所处的有序关键区域的执行顺序为为 A → B → C，并且 ABC 各自的更新将不会再触发其他任何敏感事件，则 ABC 完成更新的时间节点为 100ns + 0，100ns + 1，100 ns + 2。

更详细的关于事件调度可参考：

详解SystemVerilog中time slot的调度

🔍 仿真分析

为便于理解，可以认为普通过程中的阻塞赋值事件通常在 Active 区域执行，而非阻塞赋值对左值的更新被安排到 NBA 区域，NBA 更新在同一 time slot 中晚于 Active 区域事件。如果 NBA 更新又触发了新的组合逻辑事件，仿真器仍可能在当前 time slot 内继续处理后续事件。对于先前的 testbench：

我们可以推测，以clk信号时间节点为基准，in首先完成更新，然后对odd进行更新，此时条件满足，odd完成一次翻转。由于波形查看器通常不会展开同一 time slot 内的各个调度区域，在波形上表现出in和odd同步变化的现象。这与 iverilog 的仿真波形相符。

因此，改为in <= seq[i]; 则会把 in 的左值更新安排到当前 time slot 的 NBA 区域，因此 DUT 在 Active 区域读取到的通常是 in 更新前的旧值，此时条件不满足，odd要直到下一个时钟上升沿才会更新。

💡

这样的调度非常符合真实硬件电路。对于组合逻辑，理想情况下是立即响应电路的变化，以至于上述的行为看起来像是在时钟沿到来前一刻就已经完成了更新。而时序逻辑通常考虑到寄存器 D 到 Q 有比组合逻辑更大的延迟，因此上述行为看起来像是在时钟沿到来之后才更新。对于一个同步信号，后者更符合现实情况。

🔍 行为级仿真验证

Modelsim仿真结果：

时间轴置于时钟上升沿，点击上方工具栏 Expanded Time Deltas Mode → Expand Time At Active Cursor。这样可以清晰查看 delta-cycle 的情况，实际开发中无需刻意关心仿真器复杂的底层事件调度。

“=” 赋值。

“ <=” 赋值。

💡

对代码进行如下修正也可以产生 delta-cycle：

💡 综合后仿真

综合后仿真分为功能性和时序性仿真，前者只是将综合后生成的网表信号添加至仿真中，后者继续引入了软件时序评估，更贴近真实情况。同时，我们可以看到，在引入物理延迟后，两种写法在波形上实际没有差别。

❗

注意，综合后仿真引入会默认添加 glbl.v 文件，内含一个持续 100 ns 的全局复位信号 GSR，建议将有效输入信号延迟相应时间输入。参考 AMD 官方手册：

AMD Technical Information Portal

https://docs.amd.com/r/zh-CN/ug900-vivado-logic-simulation/%E4%BD%BF%E7%94%A8%E5%85%A8%E5%B1%80%E4%B8%89%E6%80%81%E5%8F%8A%E5%85%A8%E5%B1%80%E7%BD%AE%E4%BD%8D%E5%92%8C%E5%A4%8D%E4%BD%8D%E4%BF%A1%E5%8F%B7

“=” 赋值。

“<=” 赋值。

🔗 参考文章

Vivado使用技巧（18）——仿真功能概述

https://zhuanlan.zhihu.com/p/482158995

🛠️ 如何避免 testbench 竞态

仅仅将 testbench 中的所有赋值都替换为 <=，并不是解决竞态问题的通用方法。更直接的原则是：testbench 不要在 DUT 的采样边沿所在的同一个调度区域中修改输入。

对于这个简单例子，可以让 testbench 在时钟下降沿修改输入，使输入在下一个上升沿到来前已经稳定：

这里仍然可以使用阻塞赋值，因为 testbench 在下降沿驱动输入，而 DUT 在上升沿采样输入，二者在时间上已经分离。

同样需要注意，复位信号也不应恰好在 DUT 的有效采样边沿使用阻塞赋值撤销。对于更复杂的 SystemVerilog 验证环境，还可以使用 clocking block 明确 testbench 的采样时刻和驱动时刻，从语言层面减少 testbench 与 DUT 之间的竞态。

📌

本文结论

同一个仿真时间点不代表事件真正“同时”完成，time slot 内部仍存在事件调度顺序。

无显式延迟的非阻塞赋值通常在当前 time slot 的 NBA 区域更新，不等于延迟一个时钟周期。

testbench 与 DUT 在同一个采样边沿修改、读取同一信号时，可能形成竞态，结果不应依赖仿真器的进程执行顺序。

简单 testbench 可以在非采样边沿驱动输入；复杂 SystemVerilog 验证环境可以使用 clocking block。

delta cycle 是仿真器的零时间调度概念，不能与真实电路的传播延迟、建立时间和保持时间混为一谈。

Linux 环境下 Vivado 与 Modelsim 联合仿真无法自动弹出界面解决方案

Fri, 10 Oct 2025 00:00:00 GMT

💡

本机环境：

Ubuntu 22.04 LTS

Vivado 2023.1

Modelsim 2020.4

配置路径

进入 Settings → 3rd Party Simulators，填写 Modelsim 安装路径。

Tools → Compile Simulation Libraries…

选择需要的器件（否则编译时间会很长）

设置三条路径

勾选 Compile Xilinx IP

编译完成后设置编译库路径，并在 Simulation 选项设置 Modelsim 为仿真器。

问题分析与解决

启动仿真后 GUI 界面迟迟未弹出，TCL 命令界面如下：

Vivado 日志显示仿真流程已正常启动，所有设计文件编译无错误，但 ModelSim 程序（vsim）迟迟未弹出界面或进入仿真。在终端输入：

发现进程标识符 141630 的 vsim 进程实际上已经启动，但是无法启动 GUI 界面查看波形。

排查过程中修改 vivado.desktop 文件，改为terminal=true后启动，再次运行仿真后，终端打印出一条错误信息：

显示缺少许可证的环境变量，于是尝试将 .bashrc 中的 Modelsim 相关的环境变量添加至 Vivado 的启动脚本中：

将下面三个环境变量添加到启动脚本：（修改为自己的路径）

运行仿真后成功启动 Modelsim GUI 界面。

其他解决方案

Vivado 启动 ModelSim 进程时，实际上执行了一个 TCL 脚本，解决方法有两种，但核心都是使其完整继承系统终端的环境。

方法一：手动执行 simulate.sh

运行仿真后在 {PRJ_NAME}/{PRJ_NAME}.sim/sim_1/behav/ 目录下会生成 modelsim 文件夹，终端中运行以下命令即可启动 GUI 界面，届时会在该目录下生成 vsim.wlf 文件。

方法二：终端界面启动 Vivado

再次正常运行仿真即可启动 Modelsim 的 GUI 界面。

Vitis 2023.1 常见问题记录

Sat, 08 Mar 2025 00:00:00 GMT

运行到某处进入 DataAbort 向量

查看程序中是否定义了占用空间较大的变量，这通常会导致堆栈溢出，发生内存访问错误。

为该类变量在 DDR 独自划分一块合适大小的区间（注意不要和其他地址空间重叠）

Debug 启动超时报错，但仍能成功调试

Baremetal Vitis project: ERROR xrt_server.exe: error: illegal option '-' (amd.com)

参考以上的 AMD Community 回答：

这通常是启用系统级调试出现的问题：

解决方案是选择层次结构中想要调试的项目，使用 Single application debug

找不到 BSP 文件

Vitis 2018 版本会在 Application project 创建时自动生成一个 bsp 文件（Board Support Package）

BSP（Board Support Package）是一个软件包，它包含了特定硬件平台所需的基本驱动程序、库文件和工具。它的主要功能包括：

为特定的硬件平台提供基础软件支持

包含底层驱动程序（如 CPU、内存、外设等）

提供硬件初始化代码

集成开发所需的库文件和API

提供调试和开发工具支持

在 Xilinx Vitis 开发环境中，BSP 是连接硬件平台和应用程序的重要桥梁，它使开发者能够更容易地访问和控制硬件资源。

来自 www.hellofpga.com

Vitis 2023.1 创建 Application 项目后文件树如下，操作流程为：

找到 platform.spr 文件（系统项目文件）并双击

右侧窗口单击 Board Support Package

Driver Libraries 中可以找到相关驱动文档和例程

此时可以选择导入例程，文件树中会增加一个对应资源文件夹

导入自制 IP 问题

现象分析

使用 Vivado 时加入自定义 IP 核，使用编译生成的 xsa 文件构建 application 项目会有makefile报错

系自定义IP核目录下 .\ip_repo\_1_0\drivers\_v1_0\src 下Makefile 文件导致编译报错问题，原因可能为官方希望希望用户为 IP 开发一套完整驱动后在编译入工程。直接在 Vitis 工程中修改 Makefile 有时并不能解决问题，笔者经尝试给出以下可行的解决方案

解决方案一

使用自定义AXI4LITE外设IP，vitis的patform build时报错 (amd.com)

需要找到 BSP 文件修改 driver 的设置，进入 Modify BSP Settings

将当前的 conponent 驱动设置为 none

重新编译整个项目。

使用 IP 创建向导创建的带 AXI4 通信接口的 IP 通常会自带一些 driver demo（包含与通信相关的宏函数，本质上是调用 Xil_In32() 和 Xil_Out32() 以及基地址和偏移量的宏定义），用户根据需要进行修改

解决方案二

https://adaptivesupport.amd.com/s/question/0D52E00006jpcvVSAQ/fatal-error-xparametersh-no-such-file-or-directoryxilinx-platform-definition-filexpfm-is-removed-after-building-the-project?language=en_US

参考 xilinx 官方论坛的解决方案

直接修改 .\ip_repo\_1_0\drivers\_v1_0\src 下的 Makefile 文件

修改 Makefile 文件

进入 Vivado 工程 Refresh IP Catalog，更新 IP 目录

重新输出并编译整个项目

完成后导出 xsa 文件并更新 Platform 项目

解决方案三

若任何已有方法均不凑效，极有可能是文件夹名称或者工程名称过长！！！请修改名称后重新尝试以上解决方案！

Hyacimond’s Blog

“一生一芯”项目学习记录（二）性能优化与流水线（v23.06）

B 阶段

性能优化

IPC

性能计数器

校准访存延迟

提升功能测试效率

程序的局部性

简易 Cache

在 iCache 侧支持 AXI 的突发传输

修改到 AXI 接口的 SDRAM 之后的 bug 解决：

Cachesim 评估说明

初步评测

Cache 最佳设计空间探索

评估结果（Cachesim + Yosys）

完整 SoC 最终评估

流水线处理器

前递数据不能只看当前周期

使用 Konata 流水线可视化工具

“一生一芯”项目学习记录（一）SoC 计算机系统（v23.06）

📝 预学习阶段

NVBoard

NEMU（PA1）

sdb_mainloop()解析

优雅的退出

表达式求值

断点Bug

C阶段

理解一条指令在 NEMU 中的执行过程

实现更多的指令

使用 DPI-C 机制验证 RV32I 单周期 CPU

对 AM 的 Makefile 默认启动批处理模式NEMU

添加递归 remake 支持

使用 C 语言解析 ELF 文件并实现 ftrace

Difftest 实现

构建 NPC-Infra

总体思路

将 NPC 编译成动态链接库

Difftest 支持

组合逻辑调用 DPI-C 接口的问题

设备相关

设备的输入与输出

读取定时器寄存器

异常处理机制

实现流程

让 Difftest 支持异常相应机制

内核线程的切换（yield-os）

支线

给 NEMU/NPC 添加串口输入支持

简单优化 NEMU 性能（使用 perf 工具）

NPC 性能优化（ Verilator ）

B 阶段

评估单周期NPC的主频和程序性能

重构 NPC

整体结构

问题记录

多周期 NPC

核心要点

问题记录

AXI 总线接入

避免握手的活锁和死锁

单通道握手信号的基本约束

通道间依赖关系约束

单次阻塞式事务实现

仲裁器实现

Yosys 评估时序

总线互联矩阵

ysyxSoC

输出自动刷新

添加 AM 运行时环境

重新梳理 abstract-machine 文件夹下的 script 调用

文件结构组织

链接脚本和启动代码详解

支持全局变量的写入操作

symbol lookup error 问题解决记录

Flash XIP

PSRAM

从 Flash 加载程序到 RAM

SDRAM

`sdb_mainloop()`解析