仿真系统中的测试因为之前的 UART 仿真测试思路是捕获 soc_top 中的信号： 1234567// APB UART simulation interface (directly from AXI slave mux to APB bridge)output wire apb_uart_awvalid, // 写地址有效output wire [`

前言SoC 搭建好了后，就可以测试 ddr3 了。我觉得这种测试思路很值得借鉴，尤其是在早期 SoC 的开发过程中。 首先我的设计目标是： 上电并且 reset 释放后，CPU 的 PC 直接访问 Boot ROM； Boot ROM 中放着一个bootloader，它的作用是从 sd 卡中搬运程序数据到 ddr3 中； 搬运完后，CPU 跳转到 ddr3 中执行目标程序。 以上要确保： 硬

GCC 自带头文件GCC 编译器自带了一些基础头文件，例如： <stdint.h> - 定义了标准整数类型（如 uint8_t、int32_t 等） <stddef.h> - 定义了 size_t、NULL 等基础类型和宏 <stdarg.h> - 提供了可变参数列表支持（va_list、va_start、va_end 等） 这些库提供了编译器内置的宏定义和

uart给系统接一个 uart 串口屏，也可以运行一些简单的程序，比如简单的命令行程序。但是肯定没有 HDMI 显示方便，上节已经实现了 uart 输出一个简单的 xOS 终端，uart 的上限也就如此了。 HDMI当需要在 HDMI 显示器上显示字符时： 软件渲染：CPU/软件（如 xOS 的 hdmi_putc）根据字符 ASCII 码从字库中查找点阵数据，计算目标位置，并将对应的

xOS上节仿真系统顺利从 uart 截获数据并顺利打印出字符，这节依赖于此，我要设计 xOS。 目前的 xOS 只支持栈区，也就是说它不支持堆区内存的分配。 启动代码启动函数做 4 件事情： 设置栈指针 清零 BSS 段 跳到 main 从 main 返回（实际上没必要返回，因为 main 返回之前可以设置一个死循环） 因此，启动代码大致如下： 123456789101112131415161

基础工作type.h利用编译器内置的宏，可以精确的生成有无符号的 8、16、32等数据类型，这样就不用包含别人的库了： 123456789101112131415161718192021222324#ifndef __TYPES_H__#define __TYPES_H__typedef __INT8_TYPE__ int8_t;typedef __INT16_TYPE__ int16_t;typ

地址空间由于计算机软件系统是一个裸机系统，因此没有虚拟内存系统，都是直接访存，也就是说 tlb 其实是相当于不工作的。 只要在start.S 中直接修改 csr 标记 CSR.CRMD.DA = 1 (直接地址模式)、CSR.CRMD.PG = 0 (关闭分页)。 地址段划分如下： 1234567891011121314151617181920212223242526272829303132333

前言前置知识：“CSRWR 指令将通用寄存器 rd 中的旧值写入到指定 CSR 中，同时将指定CSR的旧值更新到通用寄存器 rd 中。“ LoongArch 的调用规则： 寄存器 别名 用途 $r4 a0 第 1 个参数 $r5 a1 第 2 个参数 $r6 a2 第 3 个参数 … … … 我在初始化 csr_eentry 的时候，打算将 trap_entry 这个函

前言在做课程设计的时候，有这样的一个代码片段： 123456789101112131415#ifndef MEMORY_HPP#define MEMORY_HPP#define MEM_SIZE (64 * 1024 * 1024) // 64MB memory#define MEM_BASE 0x00000000 // CPU reset PC: 0xffffff

前言biriscv 的 issue 单元一旦接受到错误的指令，将会把错误的信号，包括目标 pc 发射到前端，提示前端取这个 pc 对应的指令。 前端需要把这个 pc 发射给 icache 单元，返回数据后，将这个 pc 的预测信息 next_taken 和 pc、inst 对齐，一块儿发给 decode 单元，实际上这就是 fetch 单元在做的事情。 但是一旦 npc 做成了两个周期，为了适配