总线选讲

余子濠

中国科学院大学

中国科学院
计算技术研究所

计算机系统与处理器
芯片课程虚拟教研室

引言

我们已经编写了单周期处理器, 并了解了设备如何工作

但处理器如何与其他模块通信?

本次课内容

总线
存储器总线
AXI-Lite

总线的来源 - 数据交换

模块间需要通信

不同的计算机
- 通过互联网通信

在计算机内部

CPU和内存控制器通过一套协议通信
内存控制器和内存颗粒通过另一套协议通信

+-----+      +-------------------+      +---------------+
| CPU | <==> | Memory Controller | <==> | Memory Device |
+-----+      +-------------------+      +---------------+

在CPU内部
- IFU需要和IDU通过信号通信
- IDU需要和EXU通过信号通信
软件模块也有类似的需求
- DiffTest中, NEMU需要和Spike通信, NPC需要和NEMU通信

广义的总线 = 通信系统

Wikipedia中总线的定义:

In computer architecture, a bus is a communication system that transfers data between
components inside a computer, or between computers. This expression covers all
related hardware components (wire, optical fiber, etc.) and software, including
communication protocols.

没错, 以下这些都属于广义的总线概念:

TCP/IP, 以太网, 网线, RTL信号, 系统调用, …
华为鸿蒙OS的一大卖点 “分布式软总线”, 好像也没那么高端了 😂
- 就是一套分布式通信协议

这次课我们学习狭义的总线

但理解其本质需求是很重要的

狭义的总线 - 硬件模块间的通信协议

最简单的总线

+-----+           +-----+
| IFU | inst ---> | IDU |
+-----+           +-----+

大家在单周期处理器里面就是这样做的

简单到你几乎不会去往总线的方向深入思考

主动发起通信的模块叫master(主设备), 响应通信的模块叫slave(从设备)

其实背后藏着一套通信协议

master(IFU)往slave(IDU)发送消息(inst信息)
双方约定, 只要master发送, slave立即收到
上述发送行为每周期都发生
- 即每周期master都往slave发送有效的指令
- 在单周期处理器中确实是这样

如果IFU并非每周期都能取到指令

+-----+ inst  ---> +-----+
| IFU | valid ---> | IDU |
+-----+            +-----+

需要添加valid(有效)信号, 通信协议如下

master(IFU)往slave(IDU)发送消息(inst信息)
双方约定, 只要master发送, slave立即收到
上述发送行为仅在valid有效时发生

Q: 如何避免处理器执行了无效指令?

A: 处理器是个状态机!

valid无效时, 只需要不修改处理器的状态即可
- 状态 = 时序逻辑元件, 将其写使能无效即可

如果IDU并非每周期都能译码指令

+-----+ inst  ---> +-----+
| IFU | valid ---> | IDU |
+-----+ <--- ready +-----+

需要添加ready(就绪)信号, 通信协议如下

master(IFU)往slave(IDU)发送消息(inst信息)
双方约定, 若master发送, 则ready有效时, 才认为slave收到
上述发送行为仅在valid有效时发生

这就是异步总线

通信发生的时刻无法提前预知, 在valid & ready时才发生, 称 “握手”
valid & !ready时, master需要暂存消息, 避免丢失

异步总线的RTL实现 - 接口信号

Chisel提供了Decoupled模板, 通过元编程轻松实现异步总线接口
- 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 = Filpped(Decoupled(new Message)) })
  // ...
}

加一个信号

 class Message extends Bundle {
   val inst = Output(UInt(32.W))
+  val pc = Output(UInt(64.W))
 }

异步总线的RTL实现 - 模块逻辑

master和slave需要根据握手信号的情况来实现约定的总线协议

不同情况做不同的事情 -> 状态机!
总线的RTL实现 = 接口信号 + 状态机

# master
   +-+ valid = 0
   | v  valid = 1
1. idle -------> 2. wait_ready <-+
   ^ ready = 1       |      |    | ready = 0
   +-----------------+      +----+

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.fire, s_idle, s_wait_ready) // fire = valid & ready
  ))

  // ...
}

总线视角下的处理器设计

+-----+ inst  ---> +-----+  ...  ---> +-----+  ...  ---> +-----+
| IFU | valid ---> | IDU | valid ---> | EXU | valid ---> | WBU |
+-----+ <--- ready +-----+ <--- ready +-----+ <--- ready +-----+

一个观察: 不同微结构的处理器, 只是模块间的通信协议不同

单周期 - 每周期上游发送的消息均有效, 下游均就绪接收新消息
带阻塞功能的单周期/多周期 - 模块空闲时消息无效, 模块忙碌时不接收新消息, IFU收到WBU的完成信号后再取下一条指令
- 基于消息控制的分布式多周期处理器
- 和课本上用一个大状态机控制的集中式多周期处理器不同
流水线 - IFU一直取指, 各模块每个周期都尝试往下游发送消息
乱序执行 - 下游模块有一个队列, 上游只需要把消息发到队列, 即可继续处理新消息

分布式控制 vs. 集中式控制

                   +--------------+
   +-------------> |  Controller  | <--------------+
   |               +--------------+                |
   |                ^            ^                 |
   v                v            v                 v
+-----+  inst   +-----+   ...   +-----+   ...   +-----+
| IFU | ------> | IDU | ------> | EXU | ------> | WBU |
+-----+         +-----+         +-----+         +-----+

集中式控制 - 控制器需收集所有模块状态, 并决定如何控制各模块工作
- 可扩展性较低, 随着模块数量和复杂度提升, 控制器越来越难设计
  - 各模块可能会工作多个周期(例如除法器)/冲刷(抛异常)/阻塞
分布式控制 - 各模块的行为仅取决于自身状态和下游模块状态
- 各模块可独立工作, 直到下游无法接收消息
- 容易插入新模块

采用基于握手的分布式控制可以统一不同微结构的处理器设计!

乱序执行天生就是分布式控制的

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) }
  }
}

存储器总线

最简单的存储器总线

读操作是最基本的需求

假设存储器的规格是固定的 - 32 bits x N words
存储器读数据的延迟固定为1周期 - 同步存储器
- NPC仿真环境提供的pmem_read()没有读延迟, 实际上不存在这样的器件

+-----+ raddr[log2(N)-1:0] ---> +-----+
| CPU | <---        rdata[31:0] | MEM |
+-----+                         +-----+

这就是只读存储器(ROM, Read-Only Memory), 其通信协议如下

master(CPU)往slave(MEM)发送读地址raddr
下个周期slave向master回复读数据rdata
上述发送行为每周期都发生

新需求: 如何支持写操作?

可读可写的存储器总线

+-----+ raddr[log2(N)-1:0] ---> +-----+
|     | <---        rdata[31:0] |     |
|     | waddr[log2(N)-1:0] ---> |     |
| CPU | wdata[31:0]        ---> | MEM |
|     | wen                ---> |     |
|     | wmask[3:0]         ---> |     |
+-----+                         +-----+

需要添加新信号:

写地址waddr, 写数据wdata
并非每周期都需要写, 因此需要写使能wen
- 为什么可以没有读使能?
  - 状态机视角: 读操作不改变电路的状态
  - 实际中一般还是有读使能, 不用读的时候节省能耗
允许只写入一部分字节, 因此需要写掩码wmask
- 用于支持CPU的sb, sh等指令

可读可写的存储器总线(2)

通信协议 - wen有效时, M[waddr]更新为

// wmask_full为wmask按比特展开
M[waddr] <= (wdata & wmask_full) | (M[waddr] & ~wmask_full);

若同时读写同一地址, 读出结果需要RTFM(有可能undefined)

            +---+   +---+   +---+   +---+   
            |   |   |   |   |   |   |   |   
        ----+   +---+   +---+   +---+   +---+
                    /------\
waddr   ------------  addr  -----------------
                    \------/
                    +------+
wen                 |      |
        ------------+      +-----------------
                    /------\
wmask   ------------  1111  -----------------
                    \------/
            /----------------------\
raddr   ----           addr         ---------
            \----------------------/
                    /------\/------\/------\
rdata   ------------  old    XXXXXX   new   -
                    \------/\------/\------/

SRAM和FPGA中的Block RAM都是类似上述特性

如果读延迟更大

由于电气特性, 实际中很多存储器(例如DRAM)的读延迟大于CPU的1周期

这下不能一直发送读请求了, 否则MEM将一直被无用请求占用
- 请求速率 > 服务速率, 整个系统效率很低

新需求

slave需要识别master何时发送有效请求
master也需要识别slave何时可以接收请求

这就需要握手信号!

握手 = 双方对请求的发送和接收达成共识
- 不会遗漏/重复

异步的存储器总线

+-----+ raddr[log2(N)-1:0] ---> +-----+
|     | rvalid             ---> |     |
|     | <---             rready |     |
|     | <---        rdata[31:0] |     |
| CPU | waddr[log2(N)-1:0] ---> | MEM |
|     | wdata[31:0]        ---> |     |
|     | wen                ---> |     |
|     | wmask[3:0]         ---> |     |
+-----+                         +-----+

添加rvalid(也充当了ren的作用)和rready, 实现读请求raddr的握手

新问题

slave读出rdata的时刻无法提前确定
- DRAM会定时对存储单元的电容进行充电刷新, 此时读操作需要等待
master也不一定总是准备好接收slave读出的数据
- 例如上一次读出的数据还没用完, 取决于状态机的状态

异步的存储器总线(2)

+-----+ araddr[log2(N)-1:0] ---> +-----+
|     | arvalid             ---> |     |
|     | <---             arready |     |
|     | <---         rdata[31:0] |     |
|     | <---              rvalid |     |
| CPU | rready              ---> | MEM |
|     | waddr[log2(N)-1:0]  ---> |     |
|     | wdata[31:0]         ---> |     |
|     | wen                 ---> |     |
|     | wmask[3:0]          ---> |     |
+-----+                          +-----+

读出的数据rdata也需要握手

为了避免重名, 给地址相关的信号添加前缀a

在一次读数据过程中, master和slave都需要等待两次握手

master先等arready, 确保slave接收读地址后, 再等rvalid接收读数据
slave先等arvalid接收读地址, 再等rready, 确保master接收读数据
当然在RTL层面这些都是状态机

异步的存储器总线(3)

+-----+ araddr[log2(N)-1:0] ---> +-----+
|     | arvalid             ---> |     |
|     | <---             arready |     |
|     | <---         rdata[31:0] |     |
|     | <---              rvalid |     |
| CPU | rready              ---> | MEM |
|     | waddr[log2(N)-1:0]  ---> |     |
|     | wdata[31:0]         ---> |     |
|     | wmask[3:0]          ---> |     |
|     | wvalid              ---> |     |
+-----+ <---              wready +-----+

同理, 写请求也需要握手

握手信号的意义 - 解耦

为双方屏蔽对方模块内部的细节

DRAM何时读出数据受很多因素影响
- 充电的时机
- DRAM控制器的row buffer是否命中
- DRAM控制器的请求调度
- 颗粒的电气特性
CPU何时发请求并接收读数据, 同样受很多因素影响
- 程序何时执行访存指令
- 流水线的堵塞情况
- 缓存的状态

上述细节都无需关心, 只要等待握手即可

只要模块遵循同一套通信协议, 即可替换/接入, 各模块可顺利工作

错误处理

读写请求可能会出错, 例如超过存储区间的边界

+-----+ araddr[log2(N)-1:0] ---> +-----+
|     | arvalid             ---> |     |
|     | <---             arready |     |
|     | <---         rdata[31:0] |     |
|     | <---          rresp[1:0] |     |
|     | <---              rvalid |     |
|     | rready              ---> |     |
| CPU | waddr[log2(N)-1:0]  ---> | MEM |
|     | wdata[31:0]         ---> |     |
|     | wmask[3:0]          ---> |     |
|     | wvalid              ---> |     |
|     | <---              wready |     |
|     | <---          bresp[1:0] |     |
|     | <---              bvalid |     |
+-----+ bready              ---> +-----+

通过rresp和bresp向master回复读写操作是否成功

若失败, CPU可抛出异常, 通知软件处理
- RISC-V中可抛出3种Access Fault异常
为了让master成功收到写回复信号, 也需要握手

AXI-Lite总线规范

araddr  --->               araddr  --->              araddr  ---> -+
arvalid --->               arvalid --->              arvalid --->  AR
<--- arready               <--- arready              <--- arready -+
<--- rdata                 <--- rdata                
<--- rresp                 <--- rresp                <--- rdata   -+
<--- rvalid                <--- rvalid               <--- rresp    |
rready  --->       1       rready  --->      2       <--- rvalid   R
waddr   --->      ===>     awaddr  --->     ===>     rready  ---> -+
wdata   --->               awvalid ---> *            
wmask   --->               <--- awready *            awaddr  ---> -+
wvalid  --->               wdata   --->              awvalid --->  AW
<--- wready                wmask   --->              <--- awready -+
<--- bresp                 wvalid  --->              
<--- bvalid                <--- wready               wdata   ---> -+
bready  --->               <--- bresp                wstrb   --->  |
                           <--- bvalid               wvalid  --->  W
                           bready  --->              <--- wready  -+
1. 将写地址和写数据分开
2. 分组, 并将wmask改名为wstrb
                                                     <--- bresp   -+
                                                     <--- bvalid   B
                                                     bready  ---> -+

我们得到了手册上的AXI-Lite总线规范!

多个master访问一个slave

CPU中IFU需要从内存取指, LSU需要读写内存中的数据

需要一个仲裁器(Arbiter)来决定当前谁可以访问

+-----+       +---------+
| IFU | ----> |         |
+-----+       |         |       +-----+
              | Arbiter | ----> | MEM |
+-----+       |         |       +-----+
| LSU | ----> |         |
+-----+       +---------+

Arbiter = 状态机

记录当前哪个master正在访问, slave回复时转发给之前记录的master

完整的AXI总线规范

更多的信号和特性

突发读写(burst) - arburst, arlen, arsize, rlast
- 在介绍缓存时一起讲解
多个请求并发访问(可选) - arid
窄传输
- 在介绍SoC设备时一起讲解
非对齐传输(无需实现) - CPU首先就抛异常了
更多属性(这些信号我们不使用) - arlock, arcache, arqos, aruser

大家一定要RTFM

很多细节只有仔细RTFM才会发现
只需要了解AXI4即可, 我们流片的外设采用AXI4

实现的建议

首先端正学习心态

总线是传统课本上一个相对抽象的概念

不像流水线那样可以看框图写代码
只介绍协议, 没有明确说明总线的RTL实现是什么

AXI的细节对初学者来说并不少

初学者很难在首次接触AXI协议时就理解到位

大家首先要端正学习心态

不要想着一次把总线代码写完, 以后就不用改
- 如果水平没到, 这是不现实的
真相 - 在迭代开发和调试中逐渐理解总线的所有细节

先完成, 后完美

先从简单的特性开始实现:

将IFU的取指接口改造成AXI-Lite
- 用RTL编写一个AXI-Lite的SRAM模块
- 收到读请求后, 通过DPI-C调用pmem_read(), 并延迟一周期返回读出的数据
  - IFU每次取指都要等待一个周期, 才能取到指令交给IDU

将LSU的访存接口改造成AXI-Lite
- 用RTL编写另一个AXI-Lite的SRAM模块
- 收到读写请求后, 通过DPI-C调用pmem_read()/pmem_write(), 并延迟一周期返回读出的数据/写回复
  - LSU每次访存都要等待一个周期

先完成, 后完美(2)

严格来说, 这个CPU有点像多周期了

IPC有所下降, 但这才符合真实情况
- 从存储器器件中读出数据本来就有延迟

保留一个AXI-Lite的SRAM模块, 编写一个AXI-Lite的Arbiter, 从IFU和LSU的AXI-Lite中选一个master与SRAM模块交互

后续安排
- 下次课介绍SoC, 大家会把AXI-Lite拓展成AXI, 接入各种真实的外设
- 之后将会介绍处理器设计的优化原则, 大家将会感受到处理器的性能如何逐步提升

总结

总线 = 通信协议

通过握手信号屏蔽模块内部细节
- 握手时master和slave对数据传输达成一致

总线的RTL实现 = 接口信号 + 状态机
- 不同的状态下控制不同的接口信号

一定要RTFM了解具体细节