在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