在 2023 年初，达坦科技发动成立硬件设计学习社区，邀请所有有志于从事数字芯片设计的同学退出咱们的学习互助自学小组，以了解数字芯片设计的精华，强化理论知识的同时晋升实操技能，继而整体晋升设计能力。6.175 和 6.375 的课程和 Lab 学习都有肯定的难度，要求采纳 Bluespec 语言实现 RISC- V 处理器，并反对多级流水、分支预测、缓存、异样解决、缓存一致性等性能。此外，Lab 环节还波及软硬件联合开发，要求基于所实现的 RISC- V 处理器运行实在的 RISC- V 程序，并给出性能评估。
继 MIT6.175 和 MIT6.375 学习笔记之后，咱们又整顿了到目前为止，硬件设计学习社区里大家碰到的一些独特问题，心愿咱们的回复以及学习贴士对于想啃下这两门高难度课程，并想从事数字芯片设计的工程师或同学有所帮忙。
01. MIT Training Q & A
Q1: 如何取得这两门课程的 Lab 的初始代码以及对应的评测程序;
A: MIT 6.175 课程的官网没有提供 Lab 的初始代码，但能够在 GitHub 上找到 Lab 的代码实现和评测程序：
如 https://github.com/dmendelsohn/6.175
https://github.com/kazutoiris/MIT6.175
https://github.com/GTwhy/MIT_6.175
MIT 6.375 课程的大部分初始代码和评测程序可在课程官网下载到, 少部分缺失的代码能够在一下仓库找到:https://github.com/adamgallas/MIT_Bluespec_RISCV_Tutorial
Q2: 如何搭建这两门课 Lab 所需的软件开发环境？
A: 这两门课的 Lab 都须要在 Linux 环境下进行，具体依赖的软件包含:BSV 语言的编译和仿真器 BSC(bluespec complier):
下载链接为 https://github.com/B-Lang-org/bsc/releases;
具体的装置步骤见解压后文件夹里的 README 文档 riscv 工具链: 手动编译 riscv 工具链过程繁琐耗时且有些高版本的工具链可能并不适配 Lab 中的代码。举荐应用开源的预编译好的工具链, 如:https://github.com/stnolting/riscv-gcc-prebuiltconnectal
软硬件协同开发环境: connectal 我的项目链接如下 https://github.com/cambridgehackers/connectal。试验中不倡议手动编译源码构建开发环境(可能会引入很多 bug)，能够应用一些曾经配置好的 docker 镜像，如：
– https://hub.docker.com/r/pwang7/connectal
- https://hub.docker.com/r/kazutoiris/connectal
除了上述必须的软件工具外，开发过程中可能还会用到一些硬件综合工具，包含 vivado 和 yosys。因为这两个工具的配置步骤相对来说比较复杂, 倡议能够跳过 Lab 中波及这两个工具的内容。
Q3: 对于这两门课的有没有举荐的学习程序？
A: 这两门课的侧重点各有不同，6.175 更偏重体系结构相干的内容，而 6.375 对 BSV 语法的解说更加详尽，因而在浏览这两门课的 slides 和 textbook 时能够相互穿插，先次要学习 BSV 语法，而后再看体系结构相干的内容。
这两门课的 Lab 也都能够分成两局部，第一局部是 BSV 根底语法，另外一部分是 riscv CPU 相干的内容。倡议的实现程序如下：先学习 BSV 根底语法局部，包含 6.175 的 Lab0 – Lab4 以及 6.375 的 Lab1-Lab4; 而后实现和 riscv 相干的内容, 包含 6.175 的 Lab5-Lab8 和 project，以及 MIT6.375 的 Lab5。
Q4: lab6 sixstage benchmarks median case fetch 失去 PC 全为 0
A: 起因是 doExe stage 在指令执行胜利但没有 mispredict 的状况下才将传给下一阶段的 eInst 设置为 Valid。然而其实即便 mispredict 该条指令也应该是能够失常执行的，因而须要在执行后无论 predict 状况如何都设置为 Valid。
Q5: CPU 跑通，但发现 ipc 只有 0.5，什么导致 IPC 升高？
A: 在 doExecute stage mispredict 之后 sb.remove 导致 IPC 升高。TA 中提到了起因：Both Exec and WB try to call sb.remove(). This will cause Exec to conflict with WB. Also, the scoreboard implementation doesn’t allow out-of-order removal.
Q6: 做完 lab6 后开始测各个设计的 benchmark。发现很多不合乎预期，该有的优化没有体现进去。
A: 问题次要出在串联各个 stage 的 bypassfifo 实际上是用一个微小的组合逻辑把所有 rule 串了起来。每一拍同时触发，数据从第一个 stage 到最初一个顺次流过。因而只有预测谬误，通过 exe stage 重置 pc 则下一拍就能纠正，但看 IPC 就曾经很高了，退出其余优化并不能使性能更高。在对 fifo,sb,rfile 进行更换后，换成 cffifo 后体现出了肯定的性能差异。
Q7: 六级流水 CPU 加上 BHT 后存在抵触。
A: 察看 BHT 的形成和应用都只是是一般的寄存器读写，没有找到抵触源。BHT 改为 Bypass BHT 抵触依然存在。猜想问题是 Decode 预测用 BHT，Exe 阶段更新应用 BHT，导致了抵触。将 BHT.update 放到 Canonicalize 后 BHT 没问题了。但为什么 Bonus 采纳 Bypass FIFO 的时候没有这些问题？因为 Bypass FIFO 相当于把所有 Stage 连接成了一个组合逻辑电路，从 Fetch 到 WB 由组合逻辑确定执行关系。BHT 在其中尽管进行了屡次读但只进行了一次写，且程序与 Bypass FIFO 统一。
可能的起因是存在优先级程序的抵触。即 FIFO，SB，RFile 等部件蕴含了一个并发时 Rule 的执行程序，新退出的 BTB、BHT 等如果搁置在谬误的 Stage，其操作寄存器的程序，对 EHR 的读写、覆写的程序可能与 FIFO 等定义的程序不符。这样一来就会引发抵触。因而比拟好的做法是，以 FIFO 为抓手，思考每个 Stage 的优先级程序，确定之后开始抉择合乎优先级程序的 SB，RFile，BTB 等部件。之所以 Canonicalize 能够防止抵触，次要是因为其能够在所有 Stage 之后运行，因而防止了正向数据流和反馈回路联合导致的简单优先级关系。
这样一来反馈回路就有了一个简略牢靠的设计模式。即所有 Stage 将须要反馈的内容写入到 XXXRedirect[0]中，在 Canonicalize Rule 中对 Redirect 进行辨认并实现反馈。这样一来只须要思考反馈作用的部件所在 Stage 与 Canonicalize 之间的优先级关系，而不是每个 Stage 与其要反馈的 Stage 之间的优先级关系，升高了问题的复杂性。
Q8: jalr 和 ras 这两个 case 报错，return code！=0，但其余 case 失常。
A: 因为在没有进行 stall 判断的状况下就进行了 redirect。更实质地说是没有 deq 就扭转了电路状态，或者该原子性实现的多个操作被离开了。在 stall 的状况下这一条指令会在下一拍从新执行所有该 stage 的流程。
如果 redirect pc 但因为 stall 而没有 deq，则以后这条 ppc 不正确的指令会在下一拍被 kill 掉，漏掉了一条指令，而下一次 exe 的指令将会是这一次 reg 阶段预测进去的 ppc，相当于跳过了很多条指令。由此失去的教训是：当 rule 中存在多个分支（判断）时，要认真思考哪些操作应该是一个原子事务。尤其关注一个 rule 中可能对其余 rule 产生影响的局部，如上例中的 regDirect 以及对 fifo 的 enq 和 deq 操作。
Q9: 在 Windows 上跑 docker 奇慢无比，实现一次 connectal 的编译可能要花 10 分钟以上。
A: 检查一下 CPU 的型号，在最新的 Intel CPU 中引入了大小核，后台任务会被调度至小核上，尤其是虚拟机一类的性能体现会相当差。倡议搜寻无关大小核调度的文档，禁用小核来获得比拟好的性能。
Q10: 编译时候总是呈现 schedule 的 error。
A: 不举荐应用 attribute 去指定 rule 的优先级，个别仅用于 assert 断言。能够尝试输入 rule 的 dot 文件来查看所有 rule 的依赖关系，从而断定前后程序。因为 rule 前后级依赖相当多，很容易会写出一些前后抵触或者组合逻辑环。为此，可能须要学习一下 Pipeline FIFO / Bypass FIFO / Conflict-Free FIFO 的依赖关系。
Q11：我在做 6.175 的 lab5 的时候，这个 lab 须要先编译那些汇编测试用例，包含在 Lab/programs/assembly/src/ 目录下的.S 文件，和 Lab/programs/benchmarks/ 目录下的文件，学生成.riscv 的 elf 文件，再通过 elf2hex 生成.riscv.vmh 的文件，我感觉如同是本人配置的 elf2hex 工具有问题，最初生成的.riscv.vmh 文件格式不对，放到 connectal 模仿进去的处理器上，跑不进去。
A：elf2hex 如同在 binutils 里被 depricated 了，不倡议用。能够不必 elf2hex，间接用 Connetal 给 CPU 加载 binary。
Q12：BSV 中对于一个 Rule 外部，不同代码之间先后顺序的差别，官网文档在哪里有形容么？举一个例子，比方我定义一个非寄存器类型的变量，之前我始终了解的是这个变量因为不存储状态，就能够把它当做一根链接两个逻辑门的导线，这样的话，在一个 rule 或 method 外部，代码书写的程序应该是没有关系的。然而，以上面的代码为例，对变量 a 的赋值操作，给 a 变量赋值的程序不同，会导致仿真 后果不一样。所以之前我把它了解成导线是错的吗？或者说，这里的“赋值”其实会产生变量的笼罩？我在官网手册里找到这么一句话：Multiple assignments to the same variable are just a shorthand for a cascaded computation
** 如果这么了解的话，就是 Bool a = ?; 这一行也相当于是一次赋值，而不仅仅当做一个占位符应用，要是这么了解就能说得通了。
rule test;
Bool a = ?;
// Write a = True here？
a = True;
if (a) begin
$display(“aaaa”);
end else begin
$display(“bbbb”);
end
// Or write here
// a = True;
endrule**
A：这个问题很好，对于深刻了解 RTL 电路建模很有帮忙。Rule 外部的非 Reg 变量都会生成连线，Rule 之间能够用 Wire 连线。Rule 外部的时序逻辑如果在同一个作用域能够前后替换程序，Rule 外部的组合逻辑个别不能随便替换程序。这个对应理论数字电路工作的场景，组合逻辑个别是有先后顺序的，时序逻辑个别是并行工作，并行工作的时序逻辑没有先后顺序。这个问题其实对应于 Verilog 的时序逻辑 always 块和组合逻辑 always 块。在时序逻辑 always 块里的非阻塞赋值，如果在同一个作用域，能够替换程序。在组合逻辑 always 块里的阻塞赋值有先后顺序关系，个别不能替换程序。
Q13：话说我用 docker 搭的环境下用 makefile 跑 bluespec 仿真 总是 make：killed 这个问题大家有遇到过吗？A：我目前是用 docker 做的试验，6175 的 lab1- 6 和 6375 的 lab1- 4 目前没有遇到这个问题。不过目前 github 上能找到的试验我的项目可能跨了很多年，调试环境的确须要花些精力。
02. MIT Training 小贴士
Tips1：在做 6.175 的 lab5 试验时，发现 run_asm.sh 和 run_bmarks.sh 这两个脚本存在潜在谬误的危险。我对照了群里几位同学之前的脚本，发现都存在这个问题：这个 shell 脚本中有如下两行：
make run.bluesim > ${log_dir}/${test_name}.log & # run bsim, redirect outputs to logsleep ${wait_time} # wait for bsim to setup
留神第一行前面的 & 符号，会把仿真工作放到后盾运行。第二行的 wait_time 默认是 3 秒，如果编译机器的速度比较慢，在 3 秒内无奈实现编译，则会导致同时启动多个仿真，而这些仿真会共享 bluesim/mem.vmh 文件，从而导致抵触。
Tips2: 给大家同步一个坑~ 目前 6.175 的 Lab5，github 上能找到的一些试验源码，6.175/lab5/main.cpp 外面的(1>>16) – 1 应该是(1<<16) – 1，这个谬误会导致在运行 benchmark 的时候，输入的 cycle 和 inst 数量有谬误，大家做试验的时候须要小心（特地是在答复试验的 question 时候，计算 IPC 的时候须要用到这个输入后果）下图是批改后的正确书写形式。
这个是我批改后的仓库，曾经推到 GitHub：https://github.com/myrfy001/learn_mit_bluespec.git
03. Related Resources
计算机体系结构|MIT6.175 和 MIT6.375 学习笔记
达坦科技硬件设计学习社区继续凋谢，若想询问退出细节，请增加下方小助手微信号 (DatenLord_Tech) 或邮件 info@datenlord.com
达坦科技（DatenLord）专一下一代云计算——“天空计算”的基础设施技术，致力于拓宽云计算的边界。达坦科技打造的新一代开源跨云存储平台 DatenLord，通过软硬件深度交融的形式买通云云壁垒，实现无限度跨云存储、跨云联通，建设海量异地、异构数据的对立存储拜访机制，为云上利用提供高性能平安存储反对。以满足不同行业客户对海量数据跨云、跨数据中心高性能拜访的需要。
公众号：达坦科技 DatenLordDatenLord
官网：http://www.datenlord.io
知乎账号：https://www.zhihu.com/org/da-tan-ke-ji
B 站：https://space.bilibili.com/2017027518