浅谈现代处理器实现超大L1 Cache的方式

浅谈现代处理器实现超大L1 Cache的方式 昨天观看WWDC时看到Apple M2处理器的L1 Cache大小已经达到了192K+128K,这不禁使我产生好奇,Apple如何做到这一点。(尽管事后发现M1处理器已经实现了,但那时的我还不懂电路上的困难。) 超大L1 Cache是一件复杂的事情,对于L1 Cache,我们都希望它的访问延迟尽可能低。而由于我们目前的处理器和操作系统采用的虚拟内存分页机制,在使用虚拟地址访问内存时,需要首先得到对应虚拟地址的物理地址,这就导致在一条访存指令算出访存的虚拟地址后,我们首先需要查询TLB,而若查询TLB再将地址送入缓存,无疑增加了访问延迟。而对于许多高性能设计的处理器而言,L1 Cache的访问往往是制约处理器频率的主要关键路径,因此涉及到L1 Cache的电路路径都需要非常慎重考虑具体设计的路径长度。 基于目前CPU中的Cache主要采用组相连的结构,在该结构上解决方法通常采用VIPT的方式,即Virtually Indexed Physically Tagged。如下图所示,通过虚拟地址的一部分作为访问Cache的索引,同时将虚拟地址送入TLB中,这样我们就实现了电路上访问Cache与访问TLB的并行,在访问结束后对比TLB输出的物理地址高位与Cache访问得到的物理地址Tag,就完成了缓存是否命中的判断。 VIPT Cache在具体实现时,我们需要考虑缓存重名的问题。例如CPU上运行着2个进程有一个共享内存,这块共享内存对应着一块物理地址,但在2个进程中的虚拟地址不同,而如果CPU只是简单地将两份虚拟地址的数据都直接保存在缓存中,就会导致缓存不一致的问题。 SOTA的大部分处理器并未解决该问题(例如我们常见的Intel和AMD),只是将VIPT简化为伪VIPT。因为在许多ISA的虚拟内存管理中,最小页面大小为4KB,因此,我只需要保证作为Index的部分在虚拟地址的低12位内(即4KB内)即可。不过,这种方法导致L1 Cache中单路的大小无法超过MMU规定的最小页面大小,而组相连的场景下,随着路数增加,电路上判断并选择带来的电路长度也随之增加,同样提高了电路的延迟,导致频率的降低或划分流水线阶段后IPC(Instructions…

调试sfence.vma,12天之差错过Linux Patch一个

起因 最近造了个RISC-V CPU模拟器——CEMU,并实现了软件模拟TLB来加速地址翻译。而TLB和页表并不自带一致性,在RISC-V上需使用sfence.vma这样的指令来刷掉TLB和Page Table Cache(如果存在)和硬件流水线上的指令来确保页表修改生效。并通过了RISC-V Test中的所有测试,然而在启动Linux进入Busybox却遇到如下问题: 尽管Busybox能跑起来并正常使用,但同样的内核在qemu和Rocket上都是完全正常的,因此我继续探索了一下可能的问题。后来objdump了一下busybox的这个地址,发现是一条ret(jalr)指令,而跳转的地址是从栈上ld的。 因此我就怀疑是页表出现了问题导致fork的时候这个进程的栈对别的进程的栈产生了破坏。 第一次尝试 我首先怀疑了TLB查找出现问题,因此我修改了sfence.vma指令的实现,将sfence.vma实现为不管asid和va,全刷TLB,结果用户进程正常载入了。 后续继续做了些尝试,发现只要在执行sfence.vma的时候忽略ASID,但保留va的判断,用户进程依然正常运行。 第二次尝试 这次在实验室里twd2和dram一起来看我调试了。我在每次TLB Hit的情况下都重新进行一遍Page Table Walk,并检查Walk出来的PTE结果和TLB的区别。 结果发现Linux Kernel在一个Hart启动的时候会出现一次页表的W位不同的问题,但那是一条sfence.vma指令的fetch,所以没有对运行结果产生影响。…

U-Boot RISC-V M Mode的灵车SMP启动

为了方便运行任意M Mode软件,同时不想自制Bootloader。我决定在我的RISC-V SoC上使用M Mode U-Boot。然后再上面跑OpenSBI再把Linux作为OpenSBI的Payload运行。但U-Boot的go命令只会修改当前Hart的PC,并不会让其他Hart进行跳转。这就导致后续OpenSBI启动Linux一发送IPI就不断进入Trap Handler。 最后我想了个简单解决方法是,一旦进入Trap Handler且发现是当前无法解决的Trap就跳转到DRAM_BASE(也就是OpenSBI的TEXT段开始地址),并将a0寄存器设置上hartid(符合OpenSBI要求)。这样当IPI产生时其他核就会进入OpenSBI。配合Rocket Chip开双核,经过多次测试,Linux SMP均正常工作。不过比较灵车,理论上正确做法应该修改U-Boot代码控制其他核的IPI跳转。 修改在此:https://github.com/cyyself/u-boot/commit/c637a978068c434691899f1139b8b3e6c45efc93 在这种方法下,只需要保证设备树科学,然后使用u-boot通过tftp/串口将OpenSBI编译的fw_payload.bin载入到DRAM_BASE,然后使用go 0x80000000即可完成SMP启动。不过这种灵车做法需要确保的是,启动过程发送IPI之前不会对U-Boot使用的内存地址进行任何破坏。

修网(AXI Ethernet)

故障现象 今日发现我之前搭建的基于Rocket Chip的SoC,在U-Boot中网卡工作,但Linux中网卡一直无法工作。并发现经常在Linux中使用ip link set eth0 up在看到dmesg输出3行网卡开启信息后系统就卡死,并在reset核心后U-boot(XIP)载入到开始访问DRAM的位置就停下。看起来像是AXI总线上(因为我没有进行Reset)有请求在我reset期间没有完成,这大概可以说明AXI总线上发了一些核的Slave无法处理的请求。 起初我怀疑问题有一部分和中断有关,因为U-Boot没有使用中断,但通过检查/proc/interrupts发现连接在PLIC上两个网卡的中断号都能在set eth0 up后出现多次中断。然后看了下Linux的Documentation中的设备树相关部分,发现我的网卡中断和DMA中断设置不对(要求把DMA中断也放在网卡中断中,但实测是等价的),修改后问题依旧,按照一个别人能工作的设备树写法修改后问题依旧。 而继续搜索相关资料发现,别人遇到的问题多数都是PHY相关。然而我使用的是SFP接口的1000BaseX,AXI Ethernet会自己实例化一个PHY,并不是外置的。 解决方法 后来我对比了我的SoC和别人的SoC,发现我拖出来的AXI DMA IP核的Memory Map Data…

用Linux resctrl玩x86 CPU上的L3 CAT

最近基于Verilator框架写了一个SoC仿真器,用C++实现了AXI接口以便软件定义MMIO。然而写完后运行发现,它的速度确实比FPGA要慢上非常多,FPGA上几秒钟完成的事情用Verilator仿真可能要跑几分钟才能跑出来。而RTL仿真是对于CPU的Cache压力很大的应用场景,因此就玩了下Linux的resctrl进行测试。方便后续选购CPU。 Linux resctrl已经支持Intel和AMD处理器中的许多技术。包括常见到的用来共享隔离Cache缓解侧信道的Intel CAT技术。然而我手里的Intel 12900K通过查看/proc/cpuinfo发现它只支持L2 CAT。而自己的AMD 5800X却可以支持L3 CAT,因此就用它进行了测试。而resctrl的配置主要参考了User Interface for Resource Control feature。 首先,对于Kernel v5.0以上,需要在config中打开CONFIG_X86_CPU_RESCTRL。Debian已经默认打开。 然后,挂载resctrl文件系统: sudo mount…

Xilinx Block Memory Generator踩坑小记

最近在用Verilator自研软件定义AXI Slave来实现SoC上设备的模拟,于是把Xilinx的Block Memory Generator当做了一个ground truth进行研究,于是就发现了一个会导致aw/w通道死锁的小坑。 复位后Master直接拉高awvalid和wvalid,则Slave不会拉高awready。但实际上Slave已经开始接收数据。 同时由于Block Memory Generator的AXI接口没有判断wlast是否符合要求,而Master一直到传输结束都不知道Slave已经接受了数据,导致一直没有拉高bready,就会导致aw/w通道死锁。 解决方法:Master在复位后的下个周期再进行操作。且AXI的Spec也要求Master在复位时应拉低ARVALID, AWVALID, WVALID。

Xilinx MIG的ECC内存踩坑小记

最近在某灵车7K325T FPGA上搭SoC,由于该灵车开发板有9个8bit DDR3组成72bit,因此就打算尝试一下ECC内存。 调试过程中遇到以下问题: 1. 开启ECC后init_calib_complete不拉高 init_calib_complete不拉高意味着内存train失败。最后发现是ddr3的dm信号在ECC开启时默认是关闭的,而我们需要将对应引脚手动拉低为0。修改后恢复。 2. AXI接口上的RRESP出现2’b10,即SLAVE ERROR。 在开启ECC后如果读取未曾写入的内存地址,会由于ECC bit没有更新导致出现ECC校验失败。在使用过程中确保该地址写入过即可。 神奇的是,我用Chipyard生成的BOOM核接到开启ECC的MIG上,如果跳转到一个没有写指令的地址时,Exception Code为2,即Illegal instruction,并非Instruction access fault。

新手的Vivado Block Design踩坑小记

最近在使用Vivado的Block Design搭建SoC,由于许多东西的User Guide不知道去哪找,因此在这里整理了一下自己作为新手使用Block Design踩过的坑。 1. 需要Create HDL Wrapper 在BD搭建完成后,点击右键选Create HDL Wrapper,然后就可以作为Top或是在别的模块中例化了。 2. 无法将System Verilog作为模块 遇到一个大问题就是自己写的System Verilog模块怎么都无法加入。后来查阅UG994发现直到Vivado 2021.2依然不支持将System Verilog作为Block…

使用nandsim模拟超过64G的大容量MTD设备

最近做毕设项目需要模拟mtd设备,并对yaffs进行相关测试。而由于要求模拟1TB容量的mtd设备,而若使用block2mtd,由于它的page size为1B大小,无法进行yaffs的挂载。 后来同学发现了Linux Kernel自带了nandsim模块,我们可以模拟一个块设备。且这个模块启动的时候可以通过overridesize参数设置整个mtd的大小为所选模拟设备的erase_size为2的整数幂。 但我们实测发现,如果overridesize设置过大,会报出以下错误: ➜ sudo modprobe nandsim first_id_byte=0x98 second_id_byte=0xd7 third_id_byte=0x94 fourth_id_byte=0x32 overridesize=20 insmod: ERROR: could not…