Rocket - regmapper - RegMapper

Posted wjcdx

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Rocket - regmapper - RegMapper相关的知识,希望对你有一定的参考价值。

https://mp.weixin.qq.com/s/aXxgzWwh6unuztjgyVX0iQ

 

简单介绍RegMapper的实现。

 

1. 简单介绍

 

RegMapper使用指定的输入接口,为一组寄存器生成读写访问逻辑。

 

2. RegMapperParams

 

定义RegMapper需要的参数:

技术图片

a. indexBits:索引号占用的位数;

b. maskBits:数据掩码的位数;

c. extraBits:额外参数的位数;

 

3. RegMapperInput

 

访问逻辑使用的输入接口:

技术图片

a. read:是否读请求;

b. index:访问的目的寄存器的索引号;

c. data:写请求时输入的数据;

d. mask:数据的掩码,每个字节一位掩码;

e. extra:额外的参数;

 

4. RegMapperOutput

 

访问逻辑的输出接口,用于返回请求的响应:

技术图片

a. read:是否读请求的响应;

b. data:读请求的响应数据;

c. extra:返回的额外的数据;

 

5. RegMapper

 

1) 可以提取出来的方法

 

a. toBits/ofBits

 

Convert to and from Bits:

技术图片

 

实例:

技术图片

 

b. litOR

 

用于判断第一个参与OR的参数是否为值为真的字面量,如果是则直接截断返回判断结果,即Bool(true):

技术图片

 

c. mux

 

技术图片

a) MuxSeq使用index从cases中选择,如果没有则使用default值:

技术图片

b) f的类型为Seq[(Bool, Bool)];

c) 每一组s/g/f返回一个out || !g;

d) f所有元组中第二个元素相与(and)的结果输出到out;

 

2) RegMapper.apply

 

下面使用重构之后的代码介绍。

 

A. 参数

 

技术图片

a. beatBytes:总线宽度(字节数);

b. concurrency:支持多少个并发访问;

c. in:访问请求输入接口;

d. mapping:要访问的所有寄存器域:

技术图片

根据注释,Map的第一个元素为字节地址,第二个元素为这个字节地址对应的寄存器包含的寄存器域;

 

B. 过滤掉长度为0的寄存器域

 

技术图片

其中,offset为字节地址偏移量;

 

C. 寄存器的字节地址不能为负值

 

技术图片

 

D. 把字节地址分组的寄存器域,展开成使用位偏移量的寄存器域

 

技术图片

其中,元组的第一个元素为寄存器域的位偏移量。

 

E. 检查寄存器域是否重叠

 

因为bitmap中的寄存器域已经排序了,所以只需要比较相邻的两个寄存器域是否重叠即可:

技术图片

 

F. 把bitmap转换为wordmap:

 

技术图片

每个word包含beatBytes个字节。wordmap中的key为字偏移量。对比之下,bytemap中二元组的第一个元素为字节地址偏移量,bitmap中二元组的第一个元素为位偏移量。

 

G. 确保所有寄存器域都可以按照字偏移量进行索引:

 

技术图片

从中可以看出:寄存器索引(index)以字为单位,每个字包含beatBytes个字节。

 

H. 使用out返回响应结果

 

技术图片

 

I. 使用front接收请求信息

 

技术图片

 

J. 处理并发请求

 

技术图片

a. 若寄存器域的读写有一个是时序逻辑,则需要使用pipeline;

b. depth为可以缓存的请求数量,即可以同时处理的请求数量;

c. back为Queue的输出端,或者就是front本身;

 

K. 找到区分字偏移量所需要的最少的位

 

技术图片

其中:

a. mask:使用AddressDecoder获取到的包含最少掩码位的掩码;

b. maskMatch:undefZero相关,这里不关注;

c. maskFilter:把mask中各个位的值转换为Boolean列表;

d. maskBits:统计mask中为1的位的个数;

 

L. 计算有效寄存器字的数量

 

技术图片

 

M. 计算有效寄存器字索引号

 

技术图片

a. 软件计算:regIndexI;

b. 硬件计算:regIndexU;

 

这里为什么不用重载呢?两个方法都可以叫做regIndex,参数类型不同,编译器可以区分。

 

N. 使用有效字偏移量,摊平寄存器域

 

技术图片

返回值是三元组序列:

a. 第一个元素是使用regIndexI计算出来的有效字偏移量;

b. 第二个元素是寄存器域的字内位偏移量;

c. 第三个元素是寄存器域;

 

O. 为每个寄存器域和有效寄存器字声明控制信号

 

技术图片

其中:

a. frontMask和backMask是把位掩码拓宽为字节掩码的结果;

b. xxvalid/xxready每个寄存器域一个;

c. xxfire每个有效寄存器字一个;

d. dataOut每个有效寄存器字一个,用于处理读取请求时返回寄存器字的数据;

 

P. 逐个处理每个寄存器域

 

技术图片

 

Q. 提取寄存器域信息

 

技术图片

a. reg为有效字索引号;

b. low为字内位起始偏移量;

c. high为字内位终止偏移量;high不能超过字的范围;

d. field为寄存器域;

 

R. 提取寄存器域对应的掩码

 

技术图片

a. rimask:前端掩码相应位相或的结果,r指read,i指input,即读请求的输入掩码;orR()的意义为只要涉及寄存器域的一个位,该寄存器域就参与操作;

b. romask:后端掩码相应位相或的结果,r指read,o指output,即读请求的输出掩码;

c. wimask:前端掩码相应位相与的结果,w指write,i指input,即写请求的输入掩码;andR()的意义为需要涉及寄存器域的全部位,该寄存器域才参与操作;

d. womask:后端掩码相应位相与的结果,w指write,o指output,即写请求的输出掩码;

e. front和back分别是Queue的前端和后端,亦即输入端和输出端,所以这里i和o也有输入端和输出端的意涵(implication),接下来在使用中还要具体辨析其含义;

 

S. 生成寄存器域的读写逻辑

 

技术图片

这里以读请求为例,寄存器域读请求相关信号如下图:

技术图片

先看f_rivalid:

a. rimask表明请求涉及到当前寄存器域;

b. rivalid(i)标识该寄存器域所在寄存器字中的其他寄存器域是否都准备好接收读请求;

c. 可以想见,其他寄存器域是否准备好接收读请求,也依赖于当前这个寄存器域是否准备好接收(f_riready);也就是说当rivalid(i)为真时,f_riready为真;

d. f_rivalid的意义为读请求输入有效;

 

再看f_roready:

a. romask表示请求涉及到当前寄存器域;

b. roready(i)表示是否准备好接收,所属寄存器字中的其他寄存器域的响应;

c. 是否准备好接收其他寄存器域的响应,也依赖于是否准备好接收当前寄存器域的响应(f_rovalid),也就是说当roready(i)为真时,f_rovalid为真;

d. f_roready的意义为准备好接收该寄存器域的响应;

 

然后看i/o:

a. f_rivalid是rimask掩码后的结果,rimask是请求队列(Queue)输入端的掩码,也就是说,只有涉及到该寄存器域时,其输入才有效;

b. f_roready是romask掩码后的结果,romask是请求队列(Queue)输出端的掩码,也就是说只有涉及到该寄存器域的请求出队时,才打开接收响应的开关。Queue是请求队列,没有涉及到该寄存器域的请求出队,则没有对该寄存器域的请求,自然也不需要接收响应;

 

最后:

a. f_riready由寄存器域输出;

b. f_rovalid由寄存器域输出;

c. 由寄存器域输出的信号,由寄存器域的读函数(RegReadFn)决定,而RegMapper这里不涉及如何产生这些信号的问题;

 

T. 收集寄存器字的控制信号

 

技术图片

a. reg为有效寄存器字索引号,随着对所有寄存器域的遍历,该寄存器字包含的所有寄存器域的控制信号二元组都会被归集到该序列中;

b. litOR(f_riready, !rimask)等效于f_riready || !rimask,即寄存器域准备好接收请求或者不涉及该寄存器域;如果不涉及该寄存器域,那么接收请求又何妨呢?

c. rivalid(i)的值使用所在寄存器字的其他寄存器域的litOR(f_riready, !rimask)决定,这在后续代码中实现;

技术图片

根据mux的实现:

技术图片

a) f中包含寄存器字包含的全部寄存器域;

b) ReduceOthers的第一个效果是把f中所有元组的第二个元素相与之后赋值给out;第二个作用就是给rivalid(i)赋值,使用的就是f中除i之外的所有元组的第二个元素相与,然后再与valid && s && g相与;

 

U. 使用寄存器域读出的数据,组合寄存器字读请求应该返回的数据

 

技术图片

a. 如果寄存器域偏移量为0,则直接使用相与的f_data即可;

b. 如果不是0,则需要把已经搜集的寄存器域数据,与f_data组合;需要注意的是flat中的寄存器域都是排过序的,所以f_data应该被置在高位,而dataOut(reg)与UInt(0, width=low)相或,则把现有的dataOut(reg)的位数拓展为low位;

c. 然后再与f_data组合之后的prepend,位数为high位;

d. 更新dataOut(reg)的值为组合之后的新值;需要注意的是,这个更新是在循环中进行。也就是在软件构建过程中进行。当该寄存器字包含的所有寄存器域都遍历完之后,dataOut(reg)中就组合了所有寄存器域读取数据,最后硬件逻辑中使用的是这个构建结果;

 

V. 入队请求索引号/出队请求索引号

 

技术图片

 

W. 是否可以入队/是否可以出队

 

技术图片

a. rifireMux表示读请求是否可以入队;wifireMux表示写请求是否可以入队;

b. rofireMux表示读请求是否可以出队;wofireMux表示写请求是否可以出队;

c. 这里忽略iRightReg/oRightReg,假设其中所有值都为true;

d. 以rifireMux为例:

a) in.valid && front.ready && front.bits.read表示读请求合法,且队列允许输入;

b) 接下来就看各个寄存器域是否允许读请求;

技术图片

c) f为寄存器字中包含的所有寄存器域对应的二元组:

技术图片

d) ReduceOthers把f中所有二元组的第二个元素相与之后,输出给out;也就是所有寄存器域的litOR(f_riready, !rimask),即所有寄存器域都准备好接收输入了;

e) 忽略!g,mux方法的输出为out;

f) out只取决于所有寄存器域是否准备好接收输入(f_riready);

g) 每个寄存器域是否有合法输入(f_rivalid),除了取决于其他寄存器域是否准备好接收输入外,则同时取决于valid && s && g。也就是说,即便所有寄存器域都准备好接收请求了,也未必有合法请求输入,取决于valid && s && g:

技术图片

h) 所有寄存器域的rivalid(i)都依赖于valid && s && g,也就是说,当valid && s && g为假时,所有寄存器域都没有合法请求输入;

i) valid = in.valid && front.ready && front.bits.read,参考a);g忽略;s的意义为请求是否针对当前寄存器字;

j) 可见out在意义上,只相当于ready;在ready为真的情况下,valid && s && g在意义上相当于valid;

 

X. 根据是否读请求,确定请求队列输入端和输出端的ready信号

 

技术图片

 

Y. 把输入接口与队列输入端相连,把输出接口与队列输出端相连

 

技术图片

 

Z. 输出响应

 

技术图片

a. 输出是否读请求的响应;

b. 输出读请求响应的数据;

c. extra原封不动的返回;

 

从中可以看出,输出接口中包含的响应,是针对队列输出端输出的请求的响应。

当然,如果队列为空,输入其中的请求,可以即时输出。队列是先入先出的。

 

3) 遗留问题

 

A. undefZero及其相关的iRightReg/oRightReg:

技术图片

 

B. field.write.combinational选择数据的差异:

技术图片

 

以上是关于Rocket - regmapper - RegMapper的主要内容,如果未能解决你的问题,请参考以下文章

Rocket - regmapper - RegisterCrossing

rocket-api

php [WordPress] [WP Rocket]禁用Automattic AMP插件创建的AMP页面上的所有WP Rocket功能。

云原生之Docker实战使用Docker部署Web在线聊天室Rocket.Chat

php [WordPress] [WP Rocket] Wrapper功能:将WP Rocket的LazyLoad应用于wp_get_attachment_image()

rocket.chat 免费吗