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操作，那么他就不能发挥这个能力，而只能选择被代理了。
