为什么这个问题没有考虑控制器延迟？答案

【问题标题】：Why is the controller latency not accounted for in this question?为什么这个问题没有考虑控制器延迟？
【发布时间】：2020-11-30 22:06:36
【问题描述】：

建议的答案是 (a.)：

a. 30(PC Read)+250(IM)+25(Mux)+150(RF)+25(MUX)+200(ALU)+25(mux)+20(Setup) = 725 ps

b. 30+250+25+150+25+200+250+25+20= 975 ps

c. 30+250+25+150+25+200+250=930 ps

d. 30+250+25+150+25+200+5+5+25+20=735 ps

e. 30+250+50+150+25+20=525 ps

f. 30+250+25+150+25+200+25+20=725ps

g. 975 ps

数据路径

正如您在建议的答案中看到的那样，控制器的延迟从未被考虑在内。同样，符号扩展的延迟也未在“f”部分中考虑。

我对问题“a”部分的解决方案与建议的答案完全相同，但我会为控制器添加 50，对于“f”部分，我还为符号扩展添加 50。

那么建议的答案是否正确？还是我？

【问题讨论】：

请勿张贴文字图片。相反，请将这些图片中的文字粘贴到您的问题中。
邮寄支票需要 3 天时间。你有两张支票要寄。需要多长时间才能收到两张支票？如果一个目的地更远，需要 4 天才能送达，而另一个目的地仍然需要 3 天怎么办？答案取决于它们的交付是序列化的还是部分或完全重叠的。硬件并行工作，因此这些块的执行是重叠的。

标签： assembly arm cpu-architecture

【解决方案1】：

您可以计算每个子组件的时间，主要从左到右工作。从中您可以计算任何周期所需的最长时间，或使用仅考虑 R-Type 指令等约束进行评估。

计算子组件时序的方法是：

endTime = startTime + 延迟，并且，
startTime = max(组件输入的所有 endTime)

我们必须特别考虑图中的后边。它们是需要设置时间但不计入组件输入列表的寄存器写入。此图中有两个后沿，一个用于写入 PC，另一个用于写入寄存器文件。（它们都从其他数据路径中脱颖而出，因为它们使用从右到左形成循环的箭头/线。）这两者都发生在周期结束时，因为时钟上升沿触发从后沿捕获数据到登记册。

由于 PC 子组件在这个周期开始时没有输入，我们可以确定它的开始时间为 0。那么它的延迟是 30ps（读取寄存器），所以它的 endTime 是 0+30ps。

鉴于此，我们可以通过使用 30ps 作为它们的 startTime 并添加它们各自的延迟来确定指令存储器和 PC+4 加法器的结束时间。

pc+4 加法器在 30ps 获得良好的输入，所以这是它的 startTime，它的延迟是 150ps；它可以在 180ps 时产生良好的输出。

同样，寄存器文件前面的多路复用器在 30ps 时获得良好的输入，其延迟为 25ps；因此，该多路复用器提供了 55ps 的良好输出。

寄存器文件有三个与此处相关的输入，分别附加到 endTimes 为 30ps、55ps 和 30ps 的组件；因此寄存器文件组件的 startTime 是 55ps...

等等。随着您的深入，您会发现一些较快组件的延迟被其他较慢组件或路径的延迟所隐藏。

【讨论】：