anon-233 / ifu Goto Github PK

Scala 94.89% Makefile 0.06% Verilog 0.69% TeX 4.37%

ifu's Introduction

iFu

你说得对，但是《 iFu 》是由 ??? 自主编写的一款全新超标量乱序CPU。CPU运行在一个被称作「 FPGA 」的物理世界，在这里被 SBT 选中的 Chisel Codes 将被授予「 编译运行 」，引导 仿真与综合 之力。你将扮演一位名为「 /*TODO*/ 」的神秘角色，在自由的 LoongArch32 中邂逅性格各异、能力独特的 Instructions ，和它们一起击败 Func/Perf/Sys Test ，找回性能的同时，逐步发掘「 B+ = 3.3 」的真相。

项目结构

./
├── iFu
│   ├── build.sbt
│   ├── doc
│   ├── Makefile
│   ├── mem.conf
│   ├── README.md
│   └── src
│       ├── main
│       │   ├── scala
│       │   └── verilog
│       └── test
│           └── scala
└── README.md

环境配置

参考https://www.chisel-lang.org/docs/installation安装Javac以及SBT。

编译运行

修改iFu/Makfile中的gen_dir为system verilog代码生成目录
运行make命令，即可在gen_dir目录下生成iFuCore.sv文件
将repo/iFu/src/main/verilog/mycpu_top.v复制到gen_dir目录下
此时，整个项目对外暴露出一个core_top模块，其接口使用AXI3协议，另外还需传入intrpt信号，用于中断处理

仿真环境

本项目仿真依赖于chiplab
将gen_dir设置为chiplab/IP/myCPU
将repo/iFu/src/main/verilog/mycpu_top.v复制到chiplab/IP/myCPU目录下
完成上述步骤后，即可使用chiplab提供的仿真环境进行仿真

ifu's People

Contributors

Stargazers

Watchers

Forkers

fudanppi zeroknighting

ifu's Issues

功能测试上版通过

把频率先设置成50MHz.跑出一个能运行的比特流文件
原本要先进行vivado的仿真,但要求接好soc_top的trace信息

而这个显然是单发的框架,目前还没有接,也没有做多发转单发的转换,因此暂无法vivado上面用所给框架进行仿真
于是直接尝试上板

允许了uncachable的字节读和半字读这种粒度读写

加上地址模式之后,发现原来的所有1-58的测试点就应该都是uncacheable的(从ref cpu的地址访存模式就可看出)

此时REF CPU直接地址映射,并且crmd对应位为0,是非缓存.
因此,如果跑原来的st.b和st.h测试点,就会出现mmio按字读写的情况,这显然会报错,测试点不通过

解决方案是给mmio加上了粒度读写的机制,两个测试重新通过

syncReadMem转化成bram元件的条件

以tage这里为例，前后有两种写法

1. 存的类型是一个自定义的bundle

val table  = SyncReadMem(nRows, Vec(bankWidth, new TageEntry()))

会生成

module table_32x44(	// src/main/scala/frontend/bpu/Tage.scala:102:29
  input  [4:0]  R0_addr,
  input         R0_en,
  input         R0_clk,
  output [43:0] R0_data,
  input  [4:0]  W0_addr,
  input         W0_en,
  input         W0_clk,
  input  [43:0] W0_data,
  input  [43:0]  W0_mask
);

看W0_mask
这里table存储的类型是bankWidth的Vec，但是mask却变成了44位，没有正确识别成一个ram部件，进了vivado会用掉很多FDRE触发器，而不是BRAM

2. 将存储类型变成EntrySz的UInt

val table  = SyncReadMem(nRows, Vec(bankWidth, UInt(tageEntrySz.W)))

会生成

module table_32x44(	// src/main/scala/frontend/bpu/Tage.scala:102:29
  input  [4:0]  R0_addr,
  input         R0_en,
  input         R0_clk,
  output [43:0] R0_data,
  input  [4:0]  W0_addr,
  input         W0_en,
  input         W0_clk,
  input  [43:0] W0_data,
  input  [3:0]  W0_mask
);

这这样才能成功将W0_mask变成4位，整个部件可以正确地在vivado被识别为bram

经过修改，综合完成后的BRAM总资源从原来的84.5变成了100，LUT又少了几千个

性能测试通过

无论是功能测试还是性能测试，尽量在发布包里面搭建vivado的func和perf框架，否则框架不完善可能会导致无反应
接下来是性能测试流程
1.烧好板子
2.拨动最右边的四个开关，以二进制数1-10设置十个test
3.按最左边的复位信号，开始测试对应点
4.通过之后会显示

通过标志：左边两个“大led灯”全部是绿色的，数码管会显示十六进制数字
5.这个时候可以调最左边的开关
往下拨，显示的是自己cpu设置频率下的计数器的十六进制表示
往上拨，显示的是系统时钟(固定100MHz)下，计数器的值
6.如果所有十个测试点都可以正常通过，那么统计数字，即可在对应的excel表格中填写并记录性能得分

关于mmio对于外设的访问问题

如果要load一个byte，用原来的普通请求的想法是，永远去Load一个字(毕竟cache是以word为粒度读的，等出去到lsu再裁剪)

这个想法对于普通请求没问题，但是对于外设，例如测试"RTThread"来说，读取命令行输入始终是向uart地址读一个byte
那么两种行为会导致不同的结果：

如果还是老办法，先读一个字，那么实际上是对uart口读了超过其粒度的东西，会导致从输入缓冲区拿走超过一个字符大小的数据，而最后只用一个字符，这会导致输入的信息实际上部分会被忽略掉，导致不可预测的行为
正确的办法是，要读一个byte，就设置cbus向axi读一个byte，这样才可以保证命令行缓冲区正确的被load进来

由此使得测试RTthread正确启动了