蜂鸟E203学习笔记-取指模块概述（1）

DonovanDuck

已于 2023-09-17 15:50:21 修改

阅读量1.5k

点赞数 3

分类专栏： # RISC-V 处理器设计文章标签： risc-v 学习

于 2022-06-10 11:27:41 首次发布

本文链接：https://blog.csdn.net/Woodencoffee/article/details/125205929

版权

RISC-V 处理器设计专栏收录该内容

2 篇文章 6 订阅

订阅专栏

蜂鸟E203学习笔记

取指模块概述（1）

取指模块概述（1）

（此文参考蜂鸟E203《RISC_V处理器篇》）
取指部分分为三大功能模块，首先是访问指令存储器（Fetching Target），这是取指部分最主要的功能，包含对存储器的取指策略和外部的取指控制，其次是IR对EXU模块的接口，主要是指令解码相关的功能，蜂鸟E203将译码这部分和取指一块并做一级流水线，称为IFU模块，最后是中断事务相关的处理功能。如图1所示，为IFU模块功能树状图，列举了IFU包含的功能模块和其子模块，下文将具体到最小功能模块做粗略概述。

Ifetch 整理

1 取指策略

1.1 存在非对齐情况的取指

关于存储器ITCM书中有详细的说明，其中较为主要的是

ITCM的SRAM宽度为64位，其输出为一个与64位地址区间对齐的数据，称为一个Lane；
ITCM有hold-up特性，如果上次已经访问了ITCM的 SRAM, 下一次取指在同一个Lane的访问不会再次真的读SRAM（即不会打开SRAM的cs使能），而是利用SRAM的Hold-up特点，直接使用其保持不变的输出，这样可以省却SRAM重复打开造成的动态功耗。
取指策略如图2流程图所示，此流程图和源代码中注释的取指策略逻辑一致，其中是否hold-up取决于是否向ITCM发送请求，若发送，数据通道就保持hold-up状态；leftover为16位缓冲寄存器。

取指逻辑
取指过程中为什么存在crossing的情况？
虽然支持地址非对齐的取指，但当前所取的指令是32位还是16位需要译码阶段才能知道，因此在取指时，IFU模块默认从ITCM读取32位，若此时获取的PC（通过分支预测或跳转指令或流水线刷新等方式生成）刚好距离Lane的边界16位，那么在读取Rdata时就会存在crossing the lane boundary的情况。

1.2 Ifetch_req状态机

状态机流程图如图3所示，图中判断条件1.1和1.2为收到总线响应数据，当通过总线向存储对象发送取指请求后，正常情况下就会经总线收到响应信号，其中也包含取到的指令，而根据取指策略的不同，对取到的指令处理方式也不同，对于1.1如前文取指策略所述，当其处于需要将指令存入leftover的情况则存入leftover，若不是，则直接存入bypass buf（旁路缓存，相当于在送入IR之前先把数据做个缓存，和EXU反压有关，这个另做阐述），而后送入IR。对于1.2，此时所处的状态已经是到了将leftover16位和取到的数据低16位拼接的时候了，已经得到一个完整的指令，因此此处若收到响应直接送入bypass buf。条件2“两次请求”指的就是crossing即需要存入leftover的情况。条件3指的是外部存储单元是否准备好接受取指请求。

Ifetch_req 状态机

2 外部取指控制

2.1 创建Ifetch请求/响应通道

Ifetch req/rsp指的是内部功能模块间的取指控制信号，icb cmd/rsp指的是对外面向总线和存储的取指控制信号，他们本质上是一样的，如图4所示，前者（蓝）是取指控制信号的内部传递，向上传递指令到IR，后者（黄）是取指控制信号的对外接口，向下承接对存储器的取指访问。已知存储有ITCM和MEM (BIU)，但构建请求响应通道没必要构建多条，应复用一个，因此，用单条请求/响应通道承接控制信号，如ifu_icb_cmd_hsked表示请求握手信号，而用存储器类别作为选择信号，决定传递的方向，如ifu_icb_cmd2itcm表示对ITCM的请求。
ift_and_bus

2.2 请求/响应握手

请求握手主要涉及就绪(ready)，有效(valid)，数据(地址pc)信号，响应握手主要涉及就绪(ready)，有效(valid)，数据(取到的指令)信号。请求握手逻辑为请求端先判断对方是否对请求表示就绪，是，则发送valid和数据，响应握手逻辑为响应端先判断对方是否对接收响应数据(这里指取到的信号)表示就绪，是，发送valid和数据，可参考图4端口。