Rocket

分析在透传和代理两种模式下，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操作，那么他就不能发挥这个能力，而只能选择被代理了。