FormalProcessorVerification.pptVIP

因为原来valA是通过选择Select valP和srcA对应的值来的。现在srcA对应的值通过forward模块进行选择到底从那里得到。所以valA必须经过select和forward两个模块。所以简写为 Sel+Fwd A. 注意：五个forward条件之间的顺序不能更换。 因为首先在pipeline中阶段越前的指令越靠近目标指令，所以如果两个不同阶段的指令写同一个寄存器，显然应该保留阶段较前的那个。 其次，同一阶段dstE可能和dstM相同，这发生在 popl %esp上。根据语义，%esp的内容应该是内存的值，而不是计算得到的值。 Forward可以解决大部分data dependence问题。对于上面的load/use问题，虽然他属于我们已经给出的五种forward数据的来源之一（寄存器的结果来自于内存），应该用forward技术。但因为memory来得太晚，所以addl指令必须要stall才能正确。 推广开来，如果产生数据的源和目的之间的最小stage1，那么就必须stall。dstE之所以不引起stall是因为dstE的值由execute stage产生，要使用它的是decode stage。两者之间的stage差为1。 只有mrmovl和popl两条可能从memory中读入数据，所以当他们的目标寄存器与decode阶段的srcA或者srcB重合时就发生了load/use hazard 在最后一个stall之后，必须有一个bubble，不然原来的指令还是会被组合电路传递到下一个阶段去，这样一条指令就执行了两次。 时钟周期70ps。 dependency存在是没有问题的。 但当这种问题解决不了的时候，她就变成了一种hazard。 相关性分为三种：先写后读、先读后写、两个写。 对于简单的PIPELINE来说，只有RAW是有问题的。 其他两种因为PIPELINE保证指令的先后顺序，所以在前面的仍然在前面，不会有问题。 原来的SEQ和SEQ+中不需要考虑这个问题。因为每条指令都是等前面的指令执行完后才进入CPU执行的，所以当他执行时所有前条产生的数据都已经有了。 而现在PIPE中，前条指令还没有执行完，后条就开始执行了，这样就可能要用到的前条产生的数据还没有产生。 这种dependency在SEQ和SEQ+中也是不存在的。道理和前面data dependency的道理相通。 通过增加pipeline寄存器，我们将整个指令执行过程划分为5个阶段(stage)。 因为计算PC这一阶段的工作量太小了，所以于Fetch阶段合并。 注意：事实上PIPE-的很多部件和大体流程都是与SEQ+非常类似的。 图中的长条形灰色方框就是流水线寄存器。每个都包含了许多个对应的寄存器。 我们希望能够设计一个每条指令只用一个周期完成的Pipleline CPU 整个硬件框图。实际上大部分内容与SEQ+相比，是相当类似或者说相同的。 变化有： 信号的重新组织与命名。在原有输入信号前面加上流水线寄存器名称（大写）以区分各自用到的信号。因为例如icode就在Decode、Execute、Memory和Write back阶段都存在，而且这些信号的内容还不同(因为属于不同的指令)，所以用流水线寄存器来加以区分。D_icode, E_icode, M_icode, and W_icode. 如果这些信号是某一阶段产生的，则以小写字母作前缀。例如valE是由Execute阶段产生的，所以在Execute阶段，他的名字叫e_valE. 2. 在Fetch阶段增加了Predict PC部件来预测下一条指令的地址。 3. 将valP和valA在Decode阶段合并为一个信号，所以多了一个Select A部件。书上P321。主要用处是减少控制信号和寄存器的数目。因为只有call指令会在memory阶段用到valP， 只有jump指令会在execute阶段用到valP。这两种指令都不需要用到寄存器A。所以我们可以将这两个控制信号合并。这样，SEQ中的data部件就不需要了。 因为在Fetch阶段本身就有Predict PC部件。这样valP在其他场合也不需要传播到Fetch阶段之外的场合去。 这个CPU中的反馈回路。就是方向从上到下的信号。包括： 预测PC到F。 跳转与否（不是预测）信号到PC选择。 读内存结果到PC选择（这出现在ret指令的场合）和寄存器存储。 计算结果到寄存器存储。 之所以要Predict PC是因为我们在有些时候没有办法在指令刚完成fetch就知道他的下一条指令在哪里。 这种情况出现在我们碰到条件跳转和ret指令时。条件跳转必须到execute阶段执行完才能知道是否跳转。Ret必须等到memory阶段完成才能知道下一条指令的地址。 其他情况，