Rocket - tilelink - AtomicAutomata之二
2024-09-06 19:30:15
https://mp.weixin.qq.com/s/XDUtw0uPrVXC4CChbydF_A
分析在透传和代理两种模式下,AtomicAutomata可能出现的问题。
1. 透传
如果下游节点支持某一个Atomic操作,并且AtomicAutomata节点被允许不做代理的话,可以由下游节点处理这个Atomic操作:
因为透传的请求不会被缓存到CAM中,而CAM中已缓存的请求具有更高的优先级,所以当透传的 请求发送到out.a时,CAM实际上是空的。
当这个Atomic请求的响应返回到out.d时,如果CAM仍然是空的,或者没有其他同source的请求缓存在CAM中时,d_cam_sel_match和d_cam_sel是全0:
d_drop为假,进而out.d被透传到in.d:
问题来了:CAM中是否会存在同source的Atomic请求呢?
2. 部分透传、部分代理
答案是会:这意味着针对某个manager部分Atomic请求由他自己处理,部分请求由AtomicAutomata代理。符合传递给上游节点的参数范围:
假设beatBytes = 8,m.supportsArithmetic = [4, 16],
那么告诉上游节点的支持范围是widen之后的,即[1, 16]。其中[1, 2]由AtomicAutomata代理,[4, 16]透传给下游节点自行处理。
如果在透传了一个大小为8字节的透传请求后,又紧接着来了一个2字节的代理请求呢?
规范中似乎没有禁止这种请求顺序:
a. 可不等响应而连发多个请求,响应也不必按照请求的顺序发送:
b. 可以连发两个同类型的请求,而不必等待回复:
3. 问题情况
如果透传了一个Atomic请求,而没有回复的情况下,又来了一个同source的Atomic请求被缓存入CAM中。
那么当第一个透传请求的回复AccessAckData到来时,会把第二个请求的缓存条目(CAM entry)当做自己的条目对待:
进而数据被缓存到cam_d中参与AMO运算。
第二个请求的响应到来时,如果代理操作的Put/Ack已完成,会被透传返回。如果早于Put/Ack到来,那么会被存入cam_d。
4. burst的情况
如果第一个被透传的是一个burst请求,情况比较复杂。需要注意的是后续beat时d_first为假,导致d_drop为假。这里不做分析了。
5. 发生概率
很少有节点只支持大范围的Atomic操作,而不支持小范围的Atomic操作。
如果连发两个相同类型的消息,那么响应消息就难以确认是针对的哪一个请求。
所以上述情况存在的可能性很低。
6. 解决办法
比较简单的办法是:把widen取消掉,只支持ourSupport大小的Atomic请求。
如果下游节点只支持大范围的Atomic操作,那么他就不能发挥这个能力,而只能选择被代理了。
最新文章
- 浅析/dev/shm
- 异步记载数据时page是怎么计算的
- Example For maven-compiler-plugin
- JS控制的动态表格
- ManageEngine Glossary
- 深入理解Java:注解(Annotation)基本概念
- MySQL Replication浅析
- Mac 终端命令汇总
- java web每天定时执行任务
- BPMN2新规范与Activiti5
- Backbone.js学习之初识hello-world
- Nginx详细配置
- codeforces 21D. Traveling Graph 状压dp
- ORA-01034: ORACLE not available ORA-27101: shared memory realm does not exist
- DVA框架统一处理所有页面的loading状态
- 给xmpphp添加了几个常用的方法
- C++ 左值与右值 右值引用 引用折叠 =>; 完美转发
- C++智能指针剖析(上)std::auto_ptr与boost::scoped_ptr
- Python与R的区别和联系
- SpringBoot注解大全 转