B1 总线
你已经设计了单周期处理器NPC, 也了解了设备如何工作. 不过我们之前是让仿真环境来提供设备的功能, 现在是时候从硬件上实现NPC与其他设备通信的功能了.
计算机中每个模块并非独立工作, 不同的模块之间需要进行数据交换: CPU和内存控制器之间, 内存控制器和内存颗粒之间, 取指单元和译码单元之间等等,都需要通过一套约定的协议进行通信. 软件同样如此, 在我们使用的DiffTest中, NEMU需要与Spike通信, NPC也需要与NEMU通信才能实现相应的功能.
从广义上来说, 总线其实就是一个通信系统, 用来在不同的模块之间进行数据传输. 我们接下来将聚焦于硬件, 介绍狭义的总线, 即硬件模块间的通信协议.
总线 - 硬件模块间的通信协议
我们先从处理器内部的模块通信开始, 理解总线协议的一般构成.
最简单的总线
NPC中包含取指单元IFU和译码单元IDU, 两个单元间需要进行通信, 将指令由IFU传递给IDU.
+-----+ +-----+
| IFU | inst ---> | IDU |
+-----+ +-----+
在这个简单的场景其实就隐含了总线协议: 一般称主动发起通信的模块为master(主设备), 称响应通信的模块为slave(从设备). 在上述的简单交互场景中, 作为master的IFU向作为slave的IDU发送信息, 发送的信息为当前的指令. 作为单周期处理器, 显然, 二者的通信实际上隐含了如下约定:
- 每个周期master都向slave发送有效信息
- master一旦发送有效信息, slave能够立刻收到
异步总线
但如果IFU不能保证每个周期都能取到指令, 此时IDU需要等待IFU完成取指. 这种情况下, 就需要在通信内容中增加一个有效信号valid, 来指示IFU何时向IDU发送有效的指令. 通信协议也需要更新如下:
- 只有在
valid信号有效时才认为信息有效 - master一旦发送有效信息, slave能够立刻收到
+-----+ inst ---> +-----+
| IFU | valid ---> | IDU |
+-----+ +-----+
那么, 如何避免让IDU执行无效指令呢? 回想一下处理器的状态机模型, 我们只要在指令无效时让处理器的状态保持不变即可. 在电路层次, 状态就是时序逻辑元件, 因此, 只需在指令无效时将时序逻辑元件的写使能置为无效即可.
再进一步, 假设有些指令的译码操作过于复杂, IDU需要多个周期才能译码一条指令. 在这种假设下, 当IFU成功取到一条指令时, IDU可能还未完成上条指令的译码, 这时IFU应该先等待IDU完成当前的译码工作, 再向IDU发送下一条指令. 为了实现让IFU等待的功能, 就需要在通信内容中增加一个就绪信号ready, 来指示IDU何时能接收下一条指令. 通信协议也需要更新如下:
- 只有在
valid信号有效时才认为信息有效 - master发送的信息, 只有在
ready信号有效时才认为slave收到
+-----+ inst ---> +-----+
| IFU | valid ---> | IDU |
+-----+ <--- ready +-----+
这实际上就是异步总线, 两个模块之间何时发生通信是无法提前预知的, 只有在valid和ready均有效时才发生. valid和ready均有效, 也称为"握手", 表示master和slave对信息的成功传递达成共识. 显然, 这种通信协议更加灵活, master和slave将根据自身的工作情况决定何时发送或接收消息. 在valid信号有效, 而ready信号无效时, IFU需要等待IDU就绪, 此时IFU应暂存将要发送的信息, 以防止信息丢失.
异步总线的RTL实现
异步总线通过握手协议确定何时通信, 在RTL层次, 它主要由接口信号和通信逻辑这两部分组成.
接口信号即需要在模块间传递的信号, 如上述例子中的inst, valid和ready信号. Chisel提供了Decoupled模板, 自带valid和ready, 通过元编程可以轻松实现异步总线接口:
class Message extends Bundle {
val inst = Output(UInt(32.W))
}
class IFU extends Module {
val io = IO(new Bundle { val out = Decoupled(new Message) })
// ...
}
class IDU extends Module {
val io = IO(new Bundle { val in = Flipped(Decoupled(new Message)) })
// ...
}
需要传递更多信息时, 也能很方便地增加信号, 这就是抽象带来的好处!
class Message extends Bundle {
val inst = Output(UInt(32.W))
+ val pc = Output(UInt(32.W))
}
接下来是通信逻辑, 也即如何用电路实现上述总线协议. 协议是master和slave双方之间的约定, 而在电路上真正需要实现的, 是双方在遵守这一约定之下的行为. 也即, 双方根据握手信号的不同情况, 进入不同的状态, 从而采取不同的操作. 这就是状态机! 对于master而言, 我们可以很容易画出它的状态转移图.
+-+ valid = 0
| v valid = 1
1. idle ----------------> 2. wait_ready <-+
^ | | | ready = 0
+--------------------------+ +----+
ready = 1
具体地:
- 一开始处于空闲状态
idle, 将valid置为无效- 如果不需要发送消息, 则一直处于
idle状态 - 如果需要发送消息, 则将
valid置为有效, 并进入wait_ready状态, 等待slave就绪
- 如果不需要发送消息, 则一直处于
- 在
wait_ready状态中, 同时检测slave的ready信号- 如果
ready信号有效, 则握手成功, 返回idle状态 - 如果
ready信号无效, 则继续处于wait_ready状态等待
- 如果
根据状态转移图, 我们就可以很容易写出相应的RTL代码了. 这里也给出了一段简单的Chisel代码供大家参考:
class IFU extends Module {
val io = IO(new Bundle { val out = Decoupled(new Message) })
val s_idle :: s_wait_ready :: Nil = Enum(2)
val state = RegInit(s_idle)
state := MuxLookup(state, s_idle)(List(
s_idle -> Mux(io.out.valid, s_wait_ready, s_idle),
s_wait_ready -> Mux(io.out.ready, s_idle, s_wait_ready)
))
io.out.valid := 有指令需要发送
// ...
}
用RTL实现IDU的通信
理解IFU通信的实现过程之后, 尝试分析并画出IDU的状态转移图, 并写出IDU通信的RTL代码. 这只是一个总线的练习, 目前你不必修改NPC中IDU的代码.
当我们完整实现IFU和IDU的通信逻辑后, 上述总线协议也就实现好了.
总线视角下的处理器设计
我们可以从总线角度来重新审视处理器设计本身. 假设处理器包含4个模块, 各模块之间需要进行通信: IFU向IDU发送指令, IDU将译码结果发送给EXU, EXU将计算结果发送给WBU.
+-----+ inst ---> +-----+ ... ---> +-----+ ... ---> +-----+
| IFU | valid ---> | IDU | valid ---> | EXU | valid ---> | WBU |
+-----+ <--- ready +-----+ <--- ready +-----+ <--- ready +-----+
在这个视角下, 不同微结构的处理器实际上只是模块间的通信协议不同:
- 对于单周期处理器, 相当于每个周期上游发送的消息都有效, 同时下游处于就绪状态来接收新消息
- 对于多周期处理器, 上游模块空闲时消息无效, 下游模块忙碌时不接收新消息; IFU收到WBU的完成信号后再取下一条指令
- 和传统课本不同, 这是一个基于消息控制的分布式多周期处理器, 其中的"分布式"体现在: 两个模块能否互相通信只取决于二者的状态, 和其他模块无关
课本上的多周期处理器
在多周期处理器中, 一条指令被划分为不同的阶段, 并在不同的周期中执行, 因此每条指令都需要花费多个时钟周期:
- 在第1个周期, IFU取指令并将指令传递到IDU
- 在第2个周期, IDU将译码结果传递给EXU
- 在第3个周期, EXU将计算结果传递给WBU
- 在第4个周期, WBU将结果写回寄存器堆
- 在下一个周期, IFU再取出下一条指令...
- 对于流水线处理器, 则可以让IFU一直取指, 同时每个模块只要有消息处理完成, 就在每个周期都尝试向下游发送消息
- 对于乱序执行处理器, 则可以看成在流水线的基础上进行很小的扩展: 每一个下游模块中都有一个队列, 上游模块只需把消息发送到队列中, 就可以不用关心下游队列的状态继续工作
通常, 集中式控制需要有一个全局的控制器, 负责收集所有模块的状态, 再根据这些状态来控制各个模块的下一步工作. 传统课本中介绍的多周期处理器, 通常是一个基于大状态机的集中式多周期处理器. 它通过全局的大状态机来收集每个模块的状态, 从而控制每个模块之间的通信, 并确定下一个状态应该是什么. 例如在当前周期IFU取指完成, 那下一个周期就应该进入译码状态, 并控制IDU进行译码.
+--------------+
+-------------> | Controller | <--------------+
| +--------------+ |
| ^ ^ |
v v v v
+-----+ inst +-----+ ... +-----+ ... +-----+
| IFU | ------> | IDU | ------> | EXU | ------> | WBU |
+-----+ +-----+ +-----+ +-----+
课本上通常只通过少数几条指令来介绍多周期状态机的基本原理, 这时问题并不大. 但集中式控制的可扩展性比较低, 随着模块的数量还有复杂度的提升, 控制器的设计会越来越复杂:
- 随着指令数量增加, 指令的类别也会增加, 这个集中式状态机需要考虑每一类指令执行的所有阶段
- 如果想在这个处理器中插入一个新阶段, 就需要重新设计控制器
- 在真实的处理器中, 每个模块的工作时间可能各不相同
- IFU取指可能存在延迟
- 而IDU可能只需要一个周期就能完成译码
- 在EXU中, 不同指令的执行时间可能各不相同
- RVI中的整数运算指令通常只需要一个周期就能完成计算
- 除法通常需要执行很久
- 乘法可能更快一些, 但可能也需要数个周期
- 访存指令需要等待的时间无法提前预知
- 一些指令的执行可能会触发异常, 中断也可能会随时到来
在这种复杂场景中, 需要考虑每个模块不同状态的组合, 统一的决策是很困难的.
而上文提到的分布式控制中, 每个模块的行为只取决于自身和下游模块的状态, 每个模块可以独立工作. 例如在乱序执行处理器中, 上游模块可以一直工作, 直到下游模块中的队列满为止. 在分布式控制中, 能够非常容易插入一个新模块, 只需要修改该模块的上下游模块的接口实现即可. 因此, 分布式控制具有更好的可扩展性.
采用这种基于握手的分布式控制, 可以统一不同微结构的处理器的设计. 此外, 乱序执行处理器天生就是分布式控制的, 这是因为乱序执行处理器中的模块和每个模块的状态都非常多, 且随时可能到来一些不同的事件(如中断到来, 流水线阻塞等), 如果采用集中式控制, 我们几乎无法保证控制器能在每个模块发生不同事件时都做出正确的决策.
总线在系统设计中的好处
你应该可以体会到总线在系统设计中的好处之一: 通过划分模块并在模块之间进行通信, 降低整个系统的设计和维护的复杂度. 集中式控制器需要和每一个模块进行通信, 因此它的设计和维护是最困难的; 通过总线协议将全局通信分解到上下游模块之间, 就消除了集中式控制器, 从而降低了整个处理器的设计复杂度.
事实上, 计算机领域中的很多例子都是通过消息通信降低系统的复杂度, 例如操作系统中的微内核, 分布式系统中的MPI编程框架, 软件架构中的C/S模型(客户端-服务器模型), 甚至整个互联网都是通过网络包进行通信.
处理器设计的对象固然是硬件, 但设计模式并不仅仅是一个硬件问题, 我们还是可以从软件领域借鉴一些有用的经验帮助我们把处理器设计这件事做得更好.
利用Chisel中的函数抽象和元编程功能, 我们可以将不同微结构处理器的设计模式统一起来, 并且很容易对处理器微结构进行"升级".
class NPC extends Module {
val io = // ...
val ifu = Module(new IFU)
val idu = Module(new IDU)
val exu = Module(new EXU)
val wbu = Module(new WBU)
StageConnect(ifu.io.out, idu.io.in)
StageConnect(idu.io.out, exu.io.in)
StageConnect(exu.io.out, wbu.io.in)
// ...
}
object StageConnect {
def apply[T <: Data](left: DecoupledIO[T], right: DecoupledIO[T]) = {
val arch = "single"
// 为展示抽象的思想, 此处代码省略了若干细节
if (arch == "single") { right.bits := left.bits }
else if (arch == "multi") { right <> left }
else if (arch == "pipeline") { right <> RegEnable(left, left.fire) }
else if (arch == "ooo") { right <> Queue(left, 16) }
}
}
重构NPC
尝试采用上面的总线思想, 重构NPC. 尽管这并不是强制性的, 但如果你使用Chisel开发, 我们强烈建议你进行重构, 这也是为接下来接入SoC, 以及将来实现流水线提前做好准备.
如果你使用Verilog开发, 你可能会感到重构工作有一些繁琐. 不过, 我们想强调的是, 设计模式和RTL实现是不同的层面, 尽管你可能会遇到一些困难, 但我们还是鼓励你思考如何通过Verilog实现上述正确的设计模式.
系统总线
除了上文介绍的处理器内各模块的连接之外, 处理器如何连接到存储器和设备也是至关重要的, 毕竟真实的处理器无法脱离存储器和外设独立工作. 连接处理器和存储器以及设备之间的总线通常称为系统总线. 下面我们以处理器和存储器之间的连接为例, 介绍系统总线应该如何设计.
系统总线的通信需求
之前NPC通过DPI-C机制和仿真环境提供的pmem_read()等接口访问存储器, 这个过程没有读延迟, 收到读请求的当前周期就可以返回读数据. 但这只是用于方便我们实现单周期处理器, 实际上并不存在这样的存储器器件.
与DPI-C机制相比, 在真实的芯片中, 处理器对存储器的访问的最大不同, 是访问过程存在延迟. 换句话说, 处理器从发起一个读请求, 到收到存储器回复的数据, 中间需要等待若干周期. 这要求处理器额外实现以下机制:
- 需要识别存储器回复的数据何时达到
- 在存储器回复的数据到达前, 处理器需要等待, 直到回复的数据到达后, 处理器才能继续执行当前指令, 这意味着, 处理器将无法满足"每周期都执行一条指令"的属性
- 进一步地, 处理器的取指操作并非每个周期都需要进行, 例如等待存储器回复的过程中就不应该取指, 因此需要告知存储器何时真正进行取指
为了解决这些问题, 在真实的芯片中, 处理器和存储器之间通过异步总线机制进行通信: 通信双方共同依据某种约定进行交互, 从而实现信息的正确传递.
不过, 真实芯片中通常采用类似AXI的工业级总线协议, 细节繁多, 例如AXI总线协议总计约30多个信号. 这意味着, 如果要让真实的芯片和设备进行通信, 原则上就需要在处理器中实现这些总线协议. 为了减轻大家的负担, 我们先从一套最简单的自定义总线协议SimpleBus开始.
访问只读存储器
由于从存储器中读出数据是最基本的需要, 我们首先考虑处理器如何通过系统总线完成读操作. 假设处理器规格固定为Nx32, 即存储器包含N个字, 每个字为32位. 同时假设该存储器的读延迟固定为1周期, 这实际上是一种同步存储器, 即从收到读请求到返回数据之间的延迟是固定的, SRAM的访问特性正是如此.
如果不考虑写操作, 我们只需要一个只读存储器(ROM, Read-Only Memory)即可. 为了从ROM中读出数据, 相应的总线只需要两个信号, 分别为地址和数据, 二者的位宽分别为log2(N)和32.
+-----+ raddr[log2(N)-1:0] ---> +-----+
| CPU | <--- rdata[31:0] | MEM |
+-----+ +-----+
其通信协议为:
- master(CPU)向slave(MEM)发送读地址
raddr - 下个周期slave向master回复数据
rdata - 上述行为每周期都发生
评估单周期NPC的主频和程序性能
在进一步修改NPC之前, 尝试通过你在预学习阶段中使用的yosys-sta项目来评估当前NPC的主频. 不过在评估之前, 你需要进行以下工作:
- 先运行microbench的train规模测试, 记录其运行结束所需的周期数
- 在RTL中注释通过DPI-C调用
pmem_read()和pmem_write()的代码, 然后为取指和访存各自实例化一个存储器. 为了保持单周期的特性, 我们需要实例化的存储器需要当前周期就能返回读数据, 因此我们可以像寄存器堆那样通过触发器实现它. 如果你使用Verilog, 可以直接实例化RegisterFile模块, 当然你需要把端口正确连上. 为了统一测试结果, 我们约定实例化的存储器大小为256x32b, 即1KB, 共实例化两个这样的存储器, 总大小为2KB.
我们之所以这样修改, 是因为单周期NPC要求每个周期都完成一条指令完整的生命周期, 因此无法连接任何现实中的存储器, 只能连带两个类似寄存器堆的存储器一同评估主频. 修改后, 你就可以评估单周期NPC的主频了.
根据评估的主频和刚才记录的microbench执行的周期数, 就可以估算出将来NPC运行microbench需要多久了. 注意这并非仿真的耗时, 而是假设NPC在上述主频下运行程序的时间. 例如, yzh某个版本的NPC在yosys-sta项目默认提供的nangate45工艺下主频为51.491MHz, 因此可以算出microbench需要运行3.870s, 但仿真花费了19.148s.
当然, 这个估算结果其实并不准确, 而且还可以说是非常乐观的:
- 这个单周期NPC距离可流片的配置还差很远, 例如我们刚才修改存储器的时候, 其实把I/O相关的部分都忽略了
- 上述主频是综合后的主频, 布局布线之后引入的线延迟会进一步把主频拉低
- 取指单元对应的存储器因为没有写操作, 被yosys优化掉了
- 访存单元对应的存储器其实也远远装不下microbench. 要成功把train规模的测试运行起来, 数据需要占用1MB内存. 这个大小都已经远远超过实际处理器芯片设计中可以容纳的触发器数量了, 先不考虑EDA工具的处理时间, 光是在芯片上摆满这么多触发器, 从占用面积来估算线延迟就已经大得不得了了.
所以, 这个评估结果的参考意义其实很小, 就当作是给后续的评估练练手吧.
由于指令存放在存储器中, 因此IFU在进行取指操作时, 也需要访问存储器. 同时, 取指过程不会向存储器中写入数据, 因此一个只读存储器就可以支撑IFU进行工作. 为了模拟访存过程存在延迟的现象, 存储器接收到取指请求后, 不能马上返回读出的指令, 而是需要延迟一个周期后才返回读出的指令.
根据上文, 对IFU来说, SimpleBus涉及如下信号:
output [31:0] ifu_raddr,
input [31:0] ifu_rdata,
这些信号的时序如下图所示:
--\ /----------\ /----------\ /----------\ /----------\ /--
ifu_raddr X 0x80000000 X (1) X 0x80000004 X X
--/ \----------/ \----------/ \----------/ \----------/ \--
--\ /----------\ /----------\ /----------\ /----------\ /--
ifu_rdata X X 0x00000413 X (2) X 0x80051137 X
--/ \----------/ \----------/ \----------/ \----------/ \--
为了让NPC实现"等待存储器读出指令"的功能, 我们首先要让IFU得知当前处于取指令的哪个阶段, 并在不同的阶段采取不同的策略. 这种"在不同时候做不同事情"的功能, 可以通过数字电路的状态机来实现! 具体地, 我们可以为IFU实现idle和wait两种状态:
- 在
idle状态下, 需要将ifu_raddr设置为pc, 并跳转到wait状态 - 在
wait状态下, 将ifu_rdata作为有效指令继续执行, 并跳转到idle状态
根据前文的总线协议, 由于通信每周期都发生, 因此向存储器发送地址请求的同时, 存储器也会返回前一周期对应的数据. 例如, 在上图中, NPC发送地址为0x80000004的取指请求时, 存储器同时也返回了记号为(2)的数据, 这个数据对应前一个周期中记号为(1)的地址请求. 如果NPC将(2)作为一条有效指令来执行, 它要么重复执行了地址为0x80000000对应的指令, 要么执行了一条其他位置的指令, 无论是何者, NPC的行为将不符合ISA的约定. 因此, 在idle状态下, NPC不应该将ifu_rdata视为有效的指令来执行, 而是应该不执行任何指令.
之前我们默认NPC每周期都能执行一条指令, 但实现SimpleBus后, NPC在等待指令返回前, 并没有有效的指令可以执行, 因此我们需要考虑"如何让NPC不执行指令". 回顾计算机系统的状态机模型, 处理器执行指令的过程就是改变处理器状态的过程, 换句话说, 我们只要想办法让处理器的状态保持不变, 就能达到"不执行指令"的效果. 聪明的你应该想到解决方案了: 处理器的状态就是时序逻辑元件, 只要让它们的写使能信号无效, 时序逻辑元件的值就不会发生变化. 因此, 你还需要在合适的状态下, 正确地设置NPC中各种时序逻辑元件的写使能信号.
支持SimpleBus的IFU
根据上文, 让IFU支持SimpleBus协议. 对于存储器的取指部分, 你可以参考如下代码:
always @(posedge clock) begin
ifu_rdata <= pmem_read(ifu_raddr);
end
对于LSU的数据访问部分, 目前无需修改, 我们接下来再让它支持SimpleBus.
实现后, 尝试运行一些测试程序, 同时通过查看波形来确认NPC和存储器之间的通信过程是否符合预期. 原则上来说, 总线协议对上层程序是透明的, 因此之前能成功运行的程序, 实现SimpleBus后也应同样能成功运行.
不过由于此时存储器需要经过1周期才能读出数据, 这时候NPC已经不是一个严格意义上的单周期处理器了, 而是一个简单的多周期处理器:
- 在第1个周期, IFU发出取指请求
- 在第2个周期, IFU拿到指令, 并交给后续的模块译码并执行
如果你按照前文的建议重构了NPC, 你会发现将NPC改造成多周期处理器并不难实现.
让DiffTest适配多周期处理器
修改成多周期处理器后, NPC就并非每个周期都执行一条指令了. 为了让DiffTest机制可以正确工作, 你需要对检查的时机稍作调整. 为此, 你可能需要从仿真环境中读取RTL的一些状态, 来帮助你判断应该什么时候进行DiffTest的检查.
访问可读可写存储器
如果要支持写操作, 就需要在总线中添加新的信号:
- 首先自然需要写地址
waddr和写数据wdata - 由于写操作并非每个周期都发生, 因此还需要添加写使能信号
wen- 虽然读操作也并非每个周期都发生, 例如对于上述改成多周期处理器的NPC, 在
wait状态下并不需要向存储器发送取指请求; 但由于读操作不会改变电路状态, 因此理论上读使能并非必须 - 不过实际中一般还是有读使能
ren, 如果没有读请求, 存储器就无需进行读操作, 从而节省能耗
- 虽然读操作也并非每个周期都发生, 例如对于上述改成多周期处理器的NPC, 在
- 写操作可能只写入一个字当中的若干字节(例如
sb指令只写入1字节), 因此还需要添加写掩码信号wmask, 用于指定写入数据中的哪些字节
+-----+ addr[log2(N)-1:0] ---> +-----+
| | wen ---> | |
| CPU | wdata[31:0] ---> | MEM |
| | wmask[3:0] ---> | |
| | <--- rdata[31:0] | |
+-----+ +-----+
同时, 通信协议需要增加写操作行为的定义, 我们用伪代码来表示:
if (wen) {
// wmask_full为wmask按比特展开的结果
M[waddr] = (wdata & wmask_full) | M[waddr] & ~wmask_full;
}
和IFU类似, 我们也来让LSU按照SimpleBus协议的约定来访问存储器. 对LSU来说, 由于store指令需要写入存储器, 故SimpleBus涉及如下信号:
output [31:0] lsu_addr,
output lsu_wen,
output [31:0] lsu_wdata,
output [ 3:0] lsu_wmask,
input [31:0] lsu_rdata,
对于读操作, wdata和wmask可取任意值, 相关信号的时序如下图所示:
--\ /----------\ /------------------------
lsu_addr X 0x80400000 X
--/ \----------/ \------------------------
---+ +-------------------------
lsu_wen | |
+------------+
------------------------------------------
lsu_wdata
------------------------------------------
------------------------------------------
lsu_wmask
------------------------------------------
---------------\ /----------\ /-----------
lsu_rdata X 0x12345678 X
---------------/ \----------/ \-----------
对于写操作, 虽然rdata为无关信号, 相关信号的时序如下图所示:
--\ /----------\ /------------------------
lsu_addr X 0x80400000 X
--/ \----------/ \------------------------
lsu_wen
------------------------------------------
--\ /----------\ /------------------------
lsu_wdata X 0x12345678 X
--/ \----------/ \------------------------
--\ /----------\ /------------------------
lsu_wdata X 0xf X
--/ \----------/ \------------------------
------------------------------------------
lsu_rdata
------------------------------------------
支持SimpleBus的LSU
根据上文, 让LSU支持SimpleBus协议. 对于存储器的数据访问部分, 你可以参考如下代码:
always @(posedge clock) begin
lsu_rdata <= (!lsu_wen) ? pmem_read(lsu_addr) : 32'b0;
if (lsu_wen) begin
pmem_write(lsu_addr, lsu_wdata, lsu_wmask);
end
end
此时可以保留pmem_read()/pmem_write()中的设备访问功能, 我们将在后续讲义中介绍如何通过总线访问外设.
让LSU支持SimpleBus后, 对于load指令, NPC需要3个周期才能完成:
- 在第1个周期, IFU发出取指请求
- 在第2个周期, IFU拿到指令, 并交给后续的模块译码, 发现是load指令后, 则通过LSU发出访存请求
- 在第3个周期, LSU拿到数据, 并交给WBU写回寄存器
因此, 你还需要对IFU进行修改, 让load指令执行结束后, 再取出下一条指令.
实现后, 尝试运行一些测试程序, 同时通过查看波形来确认NPC和存储器之间的通信过程是否符合预期. 同样地, 之前能成功运行的程序, 实现SimpleBus后也应同样能成功运行.
更普遍的存储器
事实上, 读延迟为1周期的特性通常只有SRAM能够满足, 因为它能够使用与处理器制造相同的工艺进行生产, 但SRAM的价格十分昂贵. 为了实现更低成本的存储器, 通常会采用其他存储密度更大的工艺来制造存储器, 例如DRAM. 但由于电气特性, 这些存储器的读延迟通常大于处理器的1周期.
这时处理器不能一直发送读请求, 否则由于处理器的请求速率大于存储器的服务速率, 导致存储器会一直被无用的请求占据, 严重降低整个系统的工作效率. 为了解决这个问题, 处理器需要告诉存储器何时发送有效的请求. 为此, 我们可以在处理器往存储器发送的信号中添加一个新信号reqValid, 让存储器据这个信号来判断何时有真正的请求. 当处理器需要访存时, 就设置好addr和其他信号, 并将reqValid设置为有效; 当处理器不需要访存时, 就将reqValid设置为无效. 而对于存储器来说, 当reqValid信号有效时, 才需要访问addr对应的数据; 当reqValid信号无效时, 存储器将不进行访问操作.
另一方面, 存储器何时能读出数据也是无法提前得知的. 例如DRAM会周期性地对存储单元的电容进行充电刷新, 如果此时收到读请求, 将会在充电刷新结束之后才会真正读出数据. 因此, 存储器也需要告诉处理器何时能返回有效的数据. 类似地, 为了识别存储器的回复何时达到, 我们可以在处理器接收存储器回复的信号中添加一个新信号respValid, 让处理器根据这个信号来判断存储器的回复何时有效. 以读操作为例, 当存储器读出数据时, 就设置好rdata, 并将respValid设置为有效; 当存储器还未读出数据时, 就将respValid设置为无效. 而对于处理器来说, 当respValid信号有效时, 才认为rdata为有效的数据; 当respValid信号无效时, 处理器将认为数据还没有返回, 需要继续等待.
+-----+ reqValid ---> +-----+
| | addr[log2(N)-1:0] ---> | |
| | wen ---> | |
| CPU | wdata[31:0] ---> | MEM |
| | wmask[3:0] ---> | |
| | <--- respValid | |
| | <--- rdata[31:0] | |
+-----+ +-----+
以LSU为例, 扩展后的SimpleBus涉及以下信号:
output lsu_reqValid,
output [31:0] lsu_addr,
output lsu_wen,
output [31:0] lsu_wdata,
output [ 3:0] lsu_wmask,
input lsu_respValid,
input [31:0] lsu_rdata,
对于读操作, wdata和wmask可取任意值, 相关信号的时序如下图所示:
+------------+
lsu_reqValid | |
---+ +-------------------------------------------------
--\ /----------\ /------------------------------------------------
lsu_addr X 0x80400000 X
--/ \----------/ \------------------------------------------------
--\ /------------------------------------------------
lsu_wen X X
--/ ------------ \------------------------------------------------
------------------------------------------------------------------
lsu_wdata
------------------------------------------------------------------
------------------------------------------------------------------
lsu_wmask
------------------------------------------------------------------
+------------+
lsu_respValid | |
----------------------------------------+ +------------
---------------------------------------\ /----------\ /-----------
lsu_rdata X 0x12345678 X
---------------------------------------/ \----------/ \-----------
对于写操作, 虽然rdata为无关信号, 但SimpleBus约定仍然通过respValid指示写操作已完成. 相关信号的时序如下图所示:
+------------+
lsu_reqValid | |
---+ +-------------------------------------------------
--\ /----------\ /------------------------------------------------
lsu_addr X 0x80400000 X
--/ \----------/ \------------------------------------------------
--\ ------------ /------------------------------------------------
lsu_wen X X
--/ \------------------------------------------------
--\ /----------\ /------------------------------------------------
lsu_wdata X 0x12345678 X
--/ \----------/ \------------------------------------------------
--\ /----------\ /------------------------------------------------
lsu_wdata X 0xf X
--/ \----------/ \------------------------------------------------
+------------+
lsu_respValid | |
----------------------------------------+ +------------
------------------------------------------------------------------
lsu_rdata
------------------------------------------------------------------
为SimpleBus添加有效信号后, 我们还需要对状态机进行扩展:
- 在
idle状态下, 如果当前需要访存, 就设置好的reqValid和addr等信号, 并跳转到wait状态; 如果当前不需要访存, 就停留在idle状态 - 在
wait状态下, 如果respValid有效, 就将rdata作为读出的数据继续执行, 并跳转到idle状态; 如果respValid无效, 就停留在wait状态, 从而实现等待的效果
支持有效信号的SimpleBus协议
根据上文, 让IFU和LSU根据有效信号来访问存储器. 对于存储器的数据访问部分, 你可以参考如下代码:
always @(posedge clock) begin
lsu_rdata <= (lsu_reqValid && !lsu_wen) ? pmem_read(lsu_addr) : 32'b0;
if (lsu_reqValid && lsu_wen) begin
pmem_write(lsu_addr, lsu_wdata, lsu_wmask);
end
lsu_respValid <= lsu_reqValid;
end
可通过类似方式对存储器的取指部分进行修改.
实现后, 尝试运行一些测试程序, 同时通过查看波形来确认NPC和存储器之间的通信过程是否符合预期. 同样地, 之前能成功运行的程序, 在扩展SimpleBus后也应同样能成功运行.
测试SimpleBus的实现
在存储器中添加随机延迟的功能, 来测试总线实现是否能在任意延迟下正确工作. 你可以按照从简单到复杂的顺序添加访存延迟:
- 将存储器的访问延迟依次修改成5, 10, 20等
- 在存储器模块中添加一个LFSR, 通过它来决定当前请求的延迟
- 在IFU和LSU中也添加LFSR, 通过它来决定相应
valid信号的延迟
如果NPC在充满LFSR的随机延迟下仍然能正确运行程序, 就能大大增强你对代码的信心.
温馨提示
如果你是为了D阶段流片而学习总线, 学习到此处即可.
更普遍的存储器(2)
有时候虽然处理器要发送请求, 但存储器不一定能马上接收, 原因可能是存储器处于忙碌状态, 或者请求队列已满. 为此, 我们可以在存储器向处理器发送的信号中添加一个新信号reqReady, 让处理器根据这个信号来识别存储器何时能接收请求. 当处理器需要访存时, 如果reqReady有效, 则表示当前请求可以被存储器成功接收; 如果reqReady无效, 则表示当前请求无法被存储器接收, 处理器需要等待.
另一方面, 处理器也可能因为上一次读出的数据还没用完, 而没有准备好接收存储器返回的数据. 类似地, 我们可以在处理器向存储器发送的信号中添加一个新信号respReady, 让存储器根据这个信号来识别处理器何时能接收回复. 当存储器需要发出回复时, 如果respReady有效, 则表示当前回复可以被处理器成功接收; 如果respReady无效, 则表示当前回复无法被处理器接收, 存储器需要等待.
+-----+ reqValid ---> +-----+
| | <--- reqReady | |
| | addr[log2(N)-1:0] ---> | |
| | wen ---> | |
| CPU | wdata[31:0] ---> | MEM |
| | wmask[3:0] ---> | |
| | <--- respValid | |
| | respReady ---> | |
| | <--- rdata[31:0] | |
+-----+ +-----+
以LSU为例, 扩展后的SimpleBus涉及以下信号:
output lsu_reqValid,
input lsu_reqReady,
output [31:0] lsu_addr,
output lsu_wen,
output [31:0] lsu_wdata,
output [ 3:0] lsu_wmask,
input lsu_respValid,
output lsu_respReady,
input [31:0] lsu_rdata,
对于读操作, 相关信号的时序如下图所示:
+-------------------------+
lsu_reqValid | |
---+ +---------------------------------------------------
+------------+
lsu_reqReady | |
----------------+ +---------------------------------------------------
--\ /-----------------------\ /--------------------------------------------------
lsu_addr X 0x80400000 X
--/ \-----------------------/ \--------------------------------------------------
--\ /--------------------------------------------------
lsu_wen X X
--/ ------------------------- \--------------------------------------------------
---------------------------------------------------------------------------------
lsu_wdata
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
lsu_wmask
---------------------------------------------------------------------------------
+-------------------------+
lsu_respValid | |
------------------------------------------+ +------------
+------------+
lsu_respReady | |
-------------------------------------------------------+ +------------
-----------------------------------------\ /-----------------------\ /-----------
lsu_rdata X 0x12345678 X
-----------------------------------------/ \-----------------------/ \-----------
对于写操作, 相关信号的时序如下图所示:
+-------------------------+
lsu_reqValid | |
---+ +---------------------------------------------------
+------------+
lsu_reqReady | |
----------------+ +---------------------------------------------------
--\ /-----------------------\ /--------------------------------------------------
lsu_addr X 0x80400000 X
--/ \-----------------------/ \--------------------------------------------------
--\ ------------------------- /--------------------------------------------------
lsu_wen X X
--/ \--------------------------------------------------
--\ /-----------------------\ /--------------------------------------------------
lsu_wdata X 0x12345678 X
--/ \-----------------------/ ---------------------------------------------------
--\ /-----------------------\ /--------------------------------------------------
lsu_wmask X 0xf X
--/ \-----------------------/ \--------------------------------------------------
+-------------------------+
lsu_respValid | |
------------------------------------------+ +------------
+------------+
lsu_respReady | |
-------------------------------------------------------+ +------------
---------------------------------------------------------------------------------
lsu_rdata
---------------------------------------------------------------------------------
可以看到, 在一次读事务的完成过程中, master和slave都需要经历两次握手: master先等reqReady, 确保slave能接收读请求, 再等respValid接收读数据; 而slave则先等reqValid接收读请求, 再等respReady, 确保master能接收读数据. 当然, 在RTL实现层面, 这些都是状态机.
握手信号的微结构设计意义 - 解耦
从微结构设计来看, 握手信号最重要的意义就是屏蔽通信双方的处理延迟. 例如, DRAM何时读出数据受很多因素的影响, 包括刷新时机, DRAM控制器的请求调度, DRAM颗粒中的row buffer是否命中, 甚至颗粒的电气特性等. 而CPU何时发送请求并接收数据, 同样也受很多因素的影响, 包括程序何时执行访存指令, 流水线的堵塞情况, 缓存的状态等. 如果通信的时候其中一方要考虑另一方的这些情况, 这样的设计是不可能实现的: 我们没有办法知道另一方处于什么状态.
握手信号成功地把双方的状态解耦开来, 有了握手信号之后, 双方都无需关心对方模块的状态, 只需要等待握手即可. 因此, 只要模块遵循同一套总线协议, 接入总线后就可以顺利工作.
支持完整握手信号的SimpleBus协议
根据上文, 让IFU和LSU根据完整的握手信号来访问存储器.
实现后, 尝试运行一些测试程序, 同时通过查看波形来确认NPC和存储器之间的通信过程是否符合预期.
你可以对reqReady和respReady添加随机延迟, 来对总线的实现进行更充分的测试.
错误处理和异常
在部分情况下, 存储器处理读写事务的时候可能会发生错误, 例如读写地址超过了存储区间的范围, 或者通过校验码发现读写的存储单元发生损坏. 在这些情况下, slave通常应该告诉master发生了错误, 让master决定如何处理. 因此, 我们需要在存储器的回复中额外传输一个error信号, 来指示操作是否成功. 若error信号有效, 则返回的读数据rdata是无效的, 或者写入操作不成功. 当然, error信号也需要参与握手.
+-----+ reqValid ---> +-----+
| | <--- reqReady | |
| | addr[log2(N)-1:0] ---> | |
| | wen ---> | |
| | wdata[31:0] ---> | |
| CPU | wmask[3:0] ---> | MEM |
| | <--- respValid | |
| | respReady ---> | |
| | <--- rdata[31:0] | |
| | <--- error | |
+-----+ +-----+
在处理器中, 如果读写操作出错, 可以进一步抛出异常, 通知软件进行处理. 例如, RISC-V设置了3种Access Fault异常, 分别代表在存储器中取指令, 读数据, 写数据时出错. 这样, 存储器内部的错误就可以通过总线协议传递到处理器, 再通过处理器的异常处理机制告知软件了.
业界中广泛使用的总线 - AMBA总线协议
AMBA(Advanced Microcontroller Bus Architecture)是一个在业界广泛使用的总线协议系列, 其中定义了面向各种性能场景的总线协议. 理解了SimpleBus后, 你就有能力去理解这些在业界广泛使用的总线协议了.
APB总线协议
在AMBA中, APB(Advanced Peripheral Bus)是面向低速外设的总线协议. 事实上, 基于无就绪信号版本的SimpleBus进行简单的变换, 就能得到APB总线协议:
- 对信号重命名
- 添加
psel, 用于让master在多个slave中选择一个
reqValid ---> penable ---> psel --->
addr ---> paddr ---> penable --->
wen ---> pwrite ---> paddr --->
wdata ---> 1 pwdata ---> 2 pwrite --->
wmask ---> ===> pstrb ---> ===> pwdata --->
<--- respValid <--- pready pstrb --->
<--- rdata <--- prdata <--- pready
<--- error <--- pslverr <--- prdata
<--- pslverr
这样我们就得到了APB手册中的APB4总线协议了! 不过, APB4对请求的时序要求与SimpleBus有所不同, 这里不详细展开, 需要了解时RTFM即可.
AXI总线协议
由于APB缺少就绪信号, 因此slave一次只能接收并处理一个请求. 对于像串口这样的低速外设来说, 这是可以接受的, 因为在程序运行过程中, 访问低速外设的频率并不高, 因此让低速外设一次处理一个请求, 并不会带来明显的性能损失.
但相对地, 程序访问存储器属于频繁的操作: 处理器执行的大部分load和store指令, 最终都需要访问存储器, 尤其是内存. 因此, 对于高性能处理器来说, 采用"一次只能接收并处理一个请求"的APB会带来明显的性能损失, 使得访存过程成为整个系统的瓶颈. 为了支持处理器更高效地访问存储器, AMBA需要定义不同于APB的另一套总线协议, 这就是AXI(Advanced eXtensible Interface).
为了帮助大家理解AXI, 我们基于完整握手版本的SimpleBus进行简单的变换:
- 将读写请求的地址分开, 读操作相关的信号采用
r前缀, 写操作相关的信号采用w前缀.- 由于写请求有自己的有效信号
wreqValid, 因此无需wen信号
- 由于写请求有自己的有效信号
- 对信号重命名, 读地址采用
ar前缀, 读数据采用r前缀, 写请求采用w前缀, 写回复采用b前缀(表示backward) - 将写地址和写数据分开, 写地址采用
aw前缀, 写数据采用w前缀 - 将信号按功能分成5组
reqValid ---> rreqValid ---> arvalid --->
<--- reqReady <--- rreqReady <--- arready
addr ---> raddr ---> araddr --->
wen ---> <---rrespValid <--- rvalid
wdata ---> 1 rrespReady---> 2 rready --->
wmask ---> ===> <--- rdata ===> <--- rdata
<--- respValid <--- rerror <--- rresp
respReady ---> wreqValid ---> wvalid --->
<--- rdata <--- wreqReady <--- wready
<--- error waddr ---> waddr --->
wdata ---> wdata --->
wmask ---> wstrb --->
<---wrespValid <--- bvalid
wrespReady---> bready --->
<--- werror <--- bresp
arvalid ---> araddr ---> -+
<--- arready arvalid ---> AR
araddr ---> <--- arready -+
<--- rvalid
3 rready ---> 4 <--- rdata -+
===> <--- rdata ===> <--- rresp |
<--- rresp <--- rvalid R
awvalid ---> rready ---> -+
<--- awready
awaddr ---> awaddr ---> -+
wvalid ---> awvalid ---> AW
<--- wready <--- awready -+
wdata --->
wstrb ---> wdata ---> -+
<--- bvalid wstrb ---> |
bready ---> wvalid ---> W
<--- bresp <--- wready -+
<--- bresp -+
<--- bvalid B
bready ---> -+
这样我们就得到了AXI手册中的AXI4-Lite总线协议了! AXI4-Lite是AXI的简化版, 它有5个事务通道, 分别是读地址(AR), 读数据(R), 写地址(AW), 写数据(W)和写回复(B). 这些事务通道的工作状态只取决于各自的握手信号, 因此它们可以独立工作.
和APB相比, AXI4-Lite在性能上具备以下优势:
- 读事务和写事务使用分离的事务通道. 这样, 总线可以在同一个周期同时传输读事务和写事务, 从而实现读请求和写请求之间的并发传输和处理.
- 写地址和写数据使用分离的事务通道. 对一些slave来说, 写操作需要分多个阶段才能完成. 例如, 对于DRAM存储器, 需要先对目标存储单元进行激活操作, 对于这些slave, 如果能提前收到写地址, 即使还没有收到写数据, 也可以先进行写操作的前几个阶段. AXI通过将写地址和写数据分离, 允许master在写数据就绪之前先传输写地址, 让slave先启动写操作, 从而提升写操作的处理效率.
- 每个通道有完整的握手信号. 这样, 总线可以在向master传输上一个请求的回复之前, 就向slave传输发送下一个请求, 从而实现请求的并发传输和处理.
当然, 目前的NPC还是一个多周期处理器, 作为master无法同时发送多个访存请求, 因此也无法将AXI的上述优势利用好. 但对于高性能的乱序多发射处理器, 系统中可能会同时发送多个访存请求, 采用AXI总线协议, 就可以大幅提升处理器的访存并发度, 从而提升处理器的访存效率.
事实上, 我们现在实现的AXI4-Lite只是AXI4的简化版, 完整的AXI总线规范有更多信号, 从而支持更多特性, 如多个请求的重叠和乱序处理等. 如果大家感兴趣, 也可以通过RTFM了解相关细节. 我们会在后续讲义中逐渐介绍更多我们需要使用的特性.
同时读写同一个地址 - RTFM
AXI将读事务和写事务分离, 这意味着可以同时读写存储器的同一个地址. 这种情况下, 存储器究竟读出哪个数据呢? 事实上, 具体的行为需要RTFM: 存储器器件的手册规定了该操作的行为, 在部分器件中, 读结果是未定义的. SRAM和FPGA中的Block RAM大都是这种特性.
因此, master端尽量不要同时读写同一个地址. 如果实在无法避免, 可以在master端加入检测逻辑, 在检测到读写同相同地址时, 可以延迟写操作, 先读出旧数据; 或者延迟读操作, 先写入数据, 再读出写入后的新数据. 这样, 至少可以保证读结果是有定义的.
不过, 当前NPC的IFU只会发出读请求, 而LSU则不会同时发出读请求和写请求 (取决于正在执行的是load指令还是store指令), 因此当前你无需在NPC中考虑这个问题.
在AXI的实际使用中, 我们还需要避免和握手信号相关的两种情况:
- master和slave互相都在等待对方先将握手信号置1: master在等slave将
ready置1后, 才将valid置1; 而slave则在等master将valid置1后, 才将ready置1. 结果就是双方无限制地等待, 造成死锁(dead lock). - master和slave都在试探性地握手, 但试探失败后又都取消握手:
- 在第1周期, master将
valid置1, 但此时ready置0, 握手失败 - 在第2周期, slave发现上一个周期master将
valid置1, 因此这个周期将ready置1; 但因为上一个周期握手失败, master在这个周期将valid置0, 于是这个周期握手仍然失败 - 在第3周期, master发现上一个周期slave将
ready置1, 因此这个周期将valid置1; 但因为上一个周期握手失败, slave在这个周期将ready置0, 于是这个周期握手仍然失败 - 结果双方仍然无限制地等待, 造成活锁(live lock).
- 在第1周期, master将
+---+ +---+ +---+ +---+
clk | | | | | | | |
+ +---+ +---+ +---+ +---+
+-------+ +-------+
valid | | |
+-------+ +--------
+-------+ +--------
ready | | |
+-------+ +-------+
避免握手的死锁和活锁
为了避免上述问题, AXI标准规范对握手信号的行为添加了一些约束. 你需要RTFM找到这些约束, 并正确理解它们.
注意你务必要查阅官方手册, 如果你参考了一些来源不够正规的资料, 你将会在接入SoC的时候陷入痛苦的调试黑洞.
让NPC支持AXI4-Lite
至此, 你已经知道了AXI4-Lite总线中的每一个信号因何加入, 并从需求角度理解了该总线规范的设计思想. 现在就可以把AXI4-Lite加入到NPC中, 让NPC通过AXI4-Lite来访问存储器了.
将IFU和LSU的访存接口改造成AXI4-Lite
你需要在master和slave两端都正确地用握手来实现AXI4-Lite总线协议, 具体地:
- 将IFU和LSU的访存接口改造成AXI4-Lite
- 将存储器的
ifu和lsu两个SimpleBus接口分别改造成AXI4-Lite
由于IFU只会对存储器进行读操作, 不会写入存储器, 因此可以将IFU的AW, W和B三个通道的握手信号均置为0. 当然, 更好的做法是在握手信号的另一端通过assert()确保它们一直为0.
实现后, 尝试运行一些测试程序, 同时通过查看波形来确认NPC和存储器之间的通信过程是否符合预期. 如果NPC在充满LFSR的随机延迟下仍然能正确启动RT-Thread, 就能大大增强你对代码的信心.
思考后消化的知识才是你真正掌握的
传统课本上对总线介绍通常只停留在协议层次, 并没有明确介绍如何从RTL层次实现总线, 因此如果大家只阅读课本, 总线仍然是一个相对抽象的概念. "一生一芯"是一个侧重动手实践的学习项目, 我们在讲义中已经给大家介绍了如何在RTL层次实现总线了.
不过, 如果你发现在实现的过程中还是存在一些难以克服的困难, 那就要给自己敲响警钟了: 你很可能缺乏将需求一步步转换为代码的能力. 你很可能需要反思你过去的学习方式, 例如:
- 是否过分依赖框图, 导致你缺乏微结构设计能力, 在没有框图的情况下感觉无从下手
- 更糟糕地, 是否过分依赖那些充满示例代码的资料和书籍, 导致你不仅缺乏微结构设计能力, 也缺乏将设计转换为代码的能力. 我们强烈不推荐初学者在自己的第一版代码能工作之前阅读这类资料和书籍!
我们希望你可以把"独立思考"放在学习的首位, 而不是当代码的搬运工. 如果你发现从现在开始独立思考是一件很困难的事情, 很有可能是因为你在之前的学习中错过了太多, 使得你没有能力独自完成接下来的任务了. 如果真是这样, 我们建议你带着正确的心态重新开始学习"一生一芯".
端正心态, 在迭代开发和调试中逐渐理解所有细节
不过, 作为一个业界中广泛使用的总线协议, AXI的细节还是不少, 导致大部分初学者其实很难在首次接触AXI的时候就可以理解得十分透彻. 因此, 大家也需要端正心态, "一次把总线代码全部写完, 以后就不用改"的想法是不现实的.
事实上, 所有人都是在迭代开发和调试中逐渐理解总线的所有细节. 资深工程师学习新知识的时候尚且如此, 初学者想一步登天的想法并不符合学习的客观规律.
总线的仲裁
经过上述改动, 我们将存储器改造成了两个AXI4-Lite接口, 分别连接IFU和LSU. 但在真实的硬件中, 大部分存储器只提供一个总线接口. 为了接入后续的SoC, 我们需要考虑如何在硬件实现上让IFU和LSU访问存储器的同一个接口.
这其实是一个多master的问题, 既然slave只有一个接口, 那就通过一个仲裁器(Arbiter)来决策: 当多个master同时访问同一个slave时, 获得访问权的master将得到放行, 可以成功访问slave; 其他master的请求将阻塞在仲裁器, 等待获得访问权的master访问结束后, 它们才能获得接下来的访问权.
简单整理一下, 仲裁器需要实现如下功能:
- 调度: 选择一个正在发送有效请求的master
- 阻塞: 阻塞其他master的访问
- 转发: 将获得访问权的master的请求转发给slave, 并在slave的请求到达时, 将其转发给之前的master
多个master同时访问时具体如何选择, 其实是一个调度策略的问题. 在复杂系统中, 调度策略还需要考虑更多问题: 首先要避免饥饿, 即任一个master都能在有限次仲裁后获得访问权; 其次还要避免死锁, 即仲裁器造成的阻塞不应使整个系统出现循环等待的现象. 不过目前NPC是一个多周期处理器, IFU和LSU的master不会同时发送请求, 因此你也不必考虑复杂的调度策略, 选择任意简单的调度策略即可.
实现AXI4-Lite仲裁器
让存储器保留一个AXI4-Lite接口, 编写一个AXI4-Lite仲裁器, 从IFU和LSU中选择一个master与存储器通信.
Hint: 仲裁器本质上也是一个状态机, 而阻塞和转发的功能本质上是通过操作握手信号来实现的.
评估NPC的主频和程序性能
实现了AXI4-Lite之后, NPC就可以外接真实的存储器了, 我们将要评估的对象是带有一个AXI4-Lite接口的NPC, 其中包含刚才实现的AXI4-Lite仲裁器, 而通过DPI-C实现的AXI4-Lite接口的存储器模块则不在评估范围内.
按照同样的评估方式, yzh另一个版本的NPC在yosys-sta项目默认提供的nangate45工艺下主频为297.711MHz, 因此可以算出microbench需要运行1.394s, 但仿真花费了29.861s. 可以看到仿真时间增加了, 这是因为多周期NPC的IPC小于单周期NPC, 需要花费更多的周期数来执行程序. 虽然IPC下降了, 但因为主频大幅提升, 因此程序反而执行得更快了.
别忘了, 上面的单周期NPC评估结果是非常乐观的, 甚至是乐观到实际中不可行的程度. 但这个多周期NPC的评估结果就真实多了, 至少1MB SRAM是可以实现的. 不过这还是和我们将要流片的配置差别很大, 毕竟1MB SRAM的流片成本仍然很高. 接下来我们会接入SoC, 使得评估结果更接近流片场景.
为什么要先实现总线?
过去有很多同学都对这个问题感到十分困惑, 甚至有同学认为这是讲义给大家挖的坑, 最大的原因是他们认为将来实现流水线的时候所有代码都需要推翻重写. 另一种声音是, 如果先写单周期, 后面也是要推翻重写.
之所以会让这些同学觉得后面需要推翻重写, 一方面有来自传统课本的原因: 传统课本确实把处理器的设计原理介绍得很清楚, 但却几乎不会考虑如何在不同微结构的处理器之间平滑过渡的问题, 毕竟这属于工程实践的范畴, 传统课本并不会将它作为一个知识点来讲解. 所以, 另一方面的原因就是这部分同学过分依赖传统课本: 他们仅仅按照课本上的内容去实现, 没有思考过如何采用合适的设计模式实现上述过渡.
对于初学者来说, 这其实不算一个大问题, 毕竟设计模式需要在充分了解各种细节之后才能进行抽象总结, 我们不应该要求初学者第一次学习就能思考出一个很好的设计模式. 但如果你想学得更多, 就不应该把课本上的内容看作是处理器设计的全部, 不应该把推翻重写看作是浪费时间. 作为还没有深入思考的初学者, 推翻重写的背后其实蕴含着极大的成长机会: 为什么前后两版设计的差别这么大? 能不能从中抽象总结出一些共性特征? 如果要重新来做这件事, 怎么样才能做得更好?
事实上, 好的经验和创新的机会都是从问题中总结出来的, 大家将来走向工作岗位, 肯定还会遇到更多不同的问题, 这些问题都不再像教科书那样有标准答案. 课本中的知识是有限的, 仅仅靠课本, 我们能成长的高度也是有限的, 但能够进一步帮助我们解决将来未知问题的是我们的思维习惯: 你在多次思考的过程中所形成的思维习惯, 要比课本中的知识重要得多.
回到处理器设计模式这个问题, 我们在2017年5月就已经思考并总结出相关经验, 并且在2017年和2018年南京大学参加的两届龙芯杯比赛, 以及2019年中国科学院大学发起的第一期"一生一芯"计划中都实践过, 并没有造成过多的推翻重写. 不少同学并不了解其中的情况, 因此也还是会根据自己的经验来下判断.
具体地, 通过使用Chisel的合适特性, 从单周期修改成多周期, 只需要改动30行代码, 占800行总代码的3.75%; 从多周期改成不带转发功能的流水线, 只需要改动50行代码, 占1000行总代码的5.00%; 为流水线添加转发功能, 只需要改动20行代码, 占1100行总代码的1.82%. 即使你使用Verilog开发, 如果使用正确的设计模式, 改动代码的占比也应该大致相同. 从比例上来看, 还远远不到需要推翻重写的程度.
我们想说的是, 作为初学者, 你需要保持一颗好奇的心, 以及"绝知此事要躬行"的理念. 当别人跟你说这样你需要推翻重写时, 你不应该仅仅听从这些"忠告", 而是应该思考为什么, 并通过自己的实践去钻研, 去回答这个问题. 因为在学习当中, 你才是主角.
所以为什么要先实现总线?
这是为了践行"先完成, 后完美"的设计法则.
如果我们把单周期处理器作为起点, 那流水线就应该属于"后完美"的部分. 因此, 我们先实现总线, 其实是先将处理器往可流片的方向靠拢, 实现"先完成", 即去掉任何一个功能, 要么处理器不能运行RT-Thread, 要么存储器和外设与可流片设计差别很大.
在"先完成"的基础上, 我们再通过量化评估方法理解每一种优化措施带来的性能收益. 这也是希望初学者将来可以量化地理解流水线设计对系统带来的性能提升, 而不仅仅是像传统课本那样, 将流水线设计作为一个将框图翻译成RTL代码的作业.
多个设备的系统
到目前为止, 我们的系统中还只有存储器. 显然, 真实的计算机系统中并不仅仅只有存储器, 还有其他设备. 因此我们需要考虑, 如何让NPC访问其他设备.
之前学习设备的时候, 我们介绍过内存映射I/O, 这种机制通过不同的内存地址来指示CPU访问的设备. 我们之前在仿真环境中通过pmem_read()和pmem_write(), 按照访存地址来选择需要访问的设备, 从而实现内存映射I/O的功能. 但真实的硬件并不存在pmem_read()和pmem_write()这两个仿真环境的函数.
实际上, 硬件是通过crossbar（有时也写作Xbar）模块来实现内存映射I/O. Xbar是一个总线的多路开关模块, 可以根据输入端的总线请求的地址, 将请求转发到不同的输出端, 从而传递给不同的下游模块. 这些下游模块可能是设备, 也可能是另一个Xbar. 例如, 下图中的Arbiter用于从IFU和LSU中选择一个请求转发给下游, 下游的Xbar收到请求后, 根据请求中的地址将其转发给下游设备.
+-----+ +---------+ +------+ +-----+
| IFU | ---> | | | | ---> | UART| [0x1000_0000, 0x1000_0fff)
+-----+ | | | | +-----+
| Arbiter | ---> | Xbar |
+-----+ | | | | +-----+
| LSU | ---> | | | | ---> | SRAM| [0x8000_0000, 0x80ff_ffff)
+-----+ +---------+ +------+ +-----+
如果请求的地址位于串口设备UART的地址空间范围, 那么Xbar会将请求转发给UART; 如果请求的地址位于SRAM的地址空间范围, 则将请求转发给SRAM. 如果Xbar发现请求的地址不属于任何一个下游的地址空间, 例如0x0400_0000, 就会通过AXI4-Lite的resp信号返回一个错误decerr, 表示地址译码错. 这里的“地址译码”表示将请求的地址转换为下游总线通道的编号, 而Xbar中的地址译码器可以看作是内存映射I/O在硬件实现中的核心模块.
Arbiter和Xbar也可以合并成一个多进多出的Xbar, 视场合也称为Interconnect或总线桥. 例如, 下图即为一个2输入2输出的Xbar. 它可以连接多个master和多个slave, 首先通过Arbiter记录当前请求来自哪个master, 再依据该请求的地址决定将其转发给哪个slave.
+-----+ +------+ +-----+
| IFU | ---> | | ---> | UART| [0x1000_0000, 0x1000_0fff)
+-----+ | | +-----+
| Xbar |
+-----+ | | +-----+
| LSU | ---> | | ---> | SRAM| [0x8000_0000, 0x80ff_ffff)
+-----+ +------+ +-----+
物理内存属性(PMA)和裸机程序开发
上面的拓扑连接方式关系也可能会引起一些特殊的问题. 由于IFU可以通过Xbar和UART相连, 说明CPU也可以从UART中取指, 但显然UART设备不能存放程序和指令.
因此, 如果程序错误地跳转到0x1000_0000, CPU将向UART发送读请求, UART依据设备的行为返回一个数据, 它可能表示UART的内部状态的编码, 或者是UART接收到的字符. 一方面, CPU会错误地将UART返回的结果当作指令来执行, 从而造成严重的错误; 另一方面, IFU对UART设备的访问可能会改变设备的状态, 导致UART进入不可预测的状态.
为了避免引发这种问题, 一般会在硬件中添加一些检查机制, 为每段地址空间添加若干权限属性, 如可读标志, 可写标志, 可执行标志等 在IFU发出取指请求前, 先检查请求的地址所属的地址空间是否可执行, 若不可执行, 则直接抛出异常. 在RISC-V中, 如果系统中设备的地址空间是固定的, 则可以通过PMA(Physical Memory Attribute)机制来实现权限检查; 而对于地址空间在操作系统初始化时动态分配的现代PCI-e设备, 则可以通过PMP(Physical Memory Protection)机制或虚拟内存机制来实现权限检查. 如果你对这两种机制感兴趣, 可以参考RISC-V手册中的相关内容.
当然, 如果CPU中没有实现这些检查机制, 在开发裸机程序的时候就要特别小心了: 如果裸机程序跑飞了, 后果可能是难以想象的.
有了Xbar后, 我们就可以把之前在仿真环境中实现的外设功能移动到RTL中了.
实现AXI4-Lite接口的UART功能
编写一个AXI4-Lite接口的slave模块, 其中包含一个设备寄存器. 当往这个设备寄存器发送写请求时, 则将写入数据的低8位作为字符, 通过$write()或printf()输出. 为了方便测试, 这个设备寄存器的地址可以设置成与之前仿真环境中串口的地址相同. 实现后, 你还需要自己编写一个Xbar模块, 来将这个具备UART功能的模块接入系统中.
事实上, 我们并没有完整地用RTL来实现一个UART, 因为$write()或printf()仍然需要依赖仿真环境来实现字符的输出. 但作为一个总线的练习, 这已经足够了, 毕竟UART的实现还需要考虑很多电气细节. 不过我们很快就会接入SoC, 其中包含一个真实的UART控制器. 现在通过这个练习来测试总线的实现, 将来接入SoC的时候也会更顺利.
实现AXI4-Lite接口的CLINT
CLINT(Core Local INTerrupt controller)是RISC-V系统中较通用的中断控制器, 是一个用于维护时钟中断和软件中断的模块. 不过目前我们的系统还不需要中断功能, 因此我们先考虑时钟相关的功能即可.
你需要实现一个AXI4-Lite接口的CLINT模块, 并将其接入系统. CLINT包含一个只读的设备寄存器mtime, 它会以一定的速率增长, 最简单的实现是每周期加1. 同样地, 为了方便测试, 其地址可以设置成与之前仿真环境中时钟的地址相同.
不过, mtime的流逝还不能直接反映时间的流逝, 它们之间相差一个系数, 需要由软件读出后进行处理. 在真实的处理器芯片中, 一般这个系数等于CLINT模块中的时钟频率, 从而可以让软件测量出真实的时间. 不过仿真环境中没有主频的概念, 如果这个系数等于仿真速率, 我们就可以在仿真环境中通过mtime的流逝计算出真实时间的流逝. 具体地, 你还需要修改IOE的相关代码, 让AM_TIMER_UPTIME返回的时间接近真实时间.
最后, 你还需要考虑mtime寄存器的位宽. 上述手册中定义的mtime是64位的, 这是为了避免在实际使用中发生溢出. 但目前NPC是32位的, 如果我们只读出mtime的低32位, 在一段时间之后, mtime将会发生溢出, 从而使系统的时间功能发生错误. 尽管你不太容易在仿真环境中运行到mtime溢出的时刻, 但如果NPC将来运行在500MHz的频率下, 将大概率会发生溢出. 因此, 运行在32位NPC上的软件需要依次读出mtime的低32位和高32位, 将其组合成一个64位的值, 供上层应用使用.