RISC-V Datapath Part3: Control Logic, metric, opt

皋陶

之前的 part2 我们忽略了控制逻辑是怎么实现的，把它当成一件理所当然的事情。我们可以看看 control logic 在处理器中对应的位置：

上面的 control 对应的就是下图中产生必要电信号的逻辑：

其中， Control Logic 有对应的逻辑表：

它会根据指令的类型来判断，而指令的类型有指令中固定的字段来决定。

那么，实际上对应的如上所示，交给 Inst BrEq BrLT 之后，不同的电路会处理以上内容，产生不同的信号，供给 ALU 等使用。

时间度量

在一个 clock 中，对应的指令执行逻辑大概如上所示，那么，实际上

最大的时钟周期，即走 lw 的，为：

f_max = 1/800ps = 1.25GHz

实际上，指令执行的速度比这还快，会到每秒完成 5billion 的 add 。这归功于流水线。

那么对于 CPU 来说，什么算衡量标准呢？我的 3800X 为啥单核那么牛逼呢（误）？标准主要有：

• Latency: 程序需要执行的时间
• Throughput: 程序一小时能够处理的请求数量
  

即：

那么，具体到 CPU 层次而言，性能、Clock cycles per Instruction（即 CPI） 这些会有：

• ISA
• 处理器的实现（这里介绍的 RISC-V 的 CPI 为1）
• Superscalar processors, CPI < 1
  

这些决定本身影响了 CPi。而 Time per Cycle 本身会被下列内容影响：

• 处理器的 microarchitecture
• 技术，14nm 或者 28nm
• 耗电
  

Pipeline

把所有指令的耗时当成一致的，然后用流水线的方式执行。因为每个原件只输出上一个state的状态，这些 state 是可以隔离的。

流水线并不降低 Latency, 而是增大吞吐量。

但是，流水线并不是有几阶段就会变快几倍，实际上，填充流水线的时间和 branch，降低了流水线的可能提升。

Pipeline is not free

• pipeline stage 如果是不平衡的，可能会比较慢
• 寄存器的 setup time 和 clk->q 的时间可能会拖慢
  

pipeline 的 task 如果有 dependency, 比如之前某个指令依赖某个寄存器，寄存器上的值又被后续指令修改，那么会有 dependency, 这个会造成流水线的 stall。

针对时间不平衡，例如 ALU 100ps, memory load 200ps，这个需要抹平这种时间，例如之前的 t_cycle, 都整成 200ps 就行了：

我们会在下一节讨论 Pipeline 的具体实现细节，现在先跳过不表。

Superscalar Processor

CPU 的 clock rate 由技术和电源限制，流水线可以增加阶段，但是有如下 trade-off:

• 每个阶段做的事情少，clock cycle 会减小
• 但是潜在的 hazard 会增加
  

所以可以考虑用 superscalar 处理器：

• 把 pipeline stage 变成多个流水线
• 每个时钟周期执行多个指令
• CPI < 1, so use Instructions Per Cycle (IPC)
• 因为多个流水线，所以可能的 dependency 减小了
  

此外，还可以乱序(Out-of-Order) 的执行：

Reorder instructions dynamically in hardware to reduce impact of hazards:
 EG, memory/cache misses

x86 只有 StoreLoad 乱序，不过 RISC-V 这种 memory model 可以执行的乱序想必更多？

完