问题描述
查看 gem5 代码，skidBuffer/timeBuffer 方法确实在时钟顺序和添加任意延迟方面提供了极大的灵活性。然而，就拖延而言，它似乎会导致额外的泡沫。在附图中考虑一个“理想”流程以及 gem5 的作用（如果我在这里错了，请纠正我）。这是预期的行为吗？我想我可以通过反转时钟顺序来解决这个问题，并将失速释放线延迟设置为 0。
考虑一个解码、重命名的例子，指令块 A、B、C、D、E 流过。假设解码和重命名时的宽度相同。
-> Cycle0: Decode handles block B,rename 处理block A [ [Decode: B,Rename: A] -> Cycle1：当重命名在 B 上停止时，它会告诉 decode，它会在下一个循环中听到它； [解码：C，重命名：B-skid]
-> Cycle2：在下一个循环中，重命名接收 C（在前一个循环中发送）并添加到现在具有 {B,C} 的skidBuffer。 [解码：，重命名：B-skid，C-skid]
-> Cycle5：当失速释放时，从skidBuffer重命名句柄B。 [解码：，重命名：B，C-skid]
-> Cycle6: Rename 从skidBuffer 处理C，现在告诉decode [Decode:,Rename: C]
-> Cycle7：Decode 听说安装并处理 D，但重命名此循环没有任何内容！
-> Cycle8：重命名得到 D
基本上，在处理完所有滑动缓冲区值后，失速释放会产生额外的气泡。
因此，而不是在下面的两个给定阶段执行此操作的停顿行为。值得关注的是 Stage2 上额外的 unstall 相关气泡
第一阶段：ABCDEF****GH
第二阶段：ABCDE****FGH
相反，您会得到：
第一阶段：ABCDEFG*****H
第二阶段：ABCDE****FG*H
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）