RISC-V Datapath Part3: Control Logic, metric, opt
本帖最后由 皋陶 于 2020-10-21 00:15 编辑之前的 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 可以执行的乱序想必更多？
完
页:
[1]