目录一、前言(无厘头)单周期CPU传送门二、流水线特性分析2.1为什么我们需要流水线？ 2.2流水线思想和示意图3、理想流水线预备知识3.1单周期CPU知识3.2寄存器(触发器) 4、理想流水线的主要部件分区4.1流水线寄存器4.2流水线分区4.3流水线寄存器中存储什么？ 五、流水线实现5.1示意图5.2小技巧：分段变量命名方式5.3流水线寄存器部分代码5.4理想流水线的局限性六、后话流水线冲突解决传送门
一、前言(无厘头)单周期CPU传送门
如果朋友还没有实现过单周期，我建议你先实践单周期再钻流水线哦。 点击下面的链接进入单周期CPU的实现过程
单周期CPU传送门
二、管道特性分析2.1为什么我们需要管道？ 单周期CPU的实现在某种意义上是为了为流水线CPU奠定基础。 单周期CPU本来在理论和工程上都没有什么意义。 在一个时钟周期内处理CPU的所有工作将浪费宝贵的硬件资源。 体现分布式战略思想的同时，更重要的是为了提高CPU的时钟速度实现更高的性能，在不能改变硬件条件的情况下，流水线是非常经典的性能优化战略。
2.2管线的想法和形象我们可能知道。 在繁忙的车间里，工人们工作得非常热心。 从一个工业设备的原料到成品的加工可能需要经过多个步骤。 想象一下，如果把所有的工作都堆在一个工人的头上，会是多么可怕的任务。 但是，如果分解该加工过程，则例如原料、设计、成形、打磨、质量检查； 而且，如果每个工人只负责一个步骤，这个原本的繁重任务会更轻松。
这是管道的想法，与分割统治的想法不同。 通过分解任务，将本来一个周期在一个CPU周期内要解决的问题分为多个周期来解决，大大减轻了CPU在一个时钟周期内的工作负担，缩短了CPU完成一个任务所需的时间，提高了CPU频率。
流水线的动作示意图如图1所示
图中的IM是命令存储器，Reg是寄存器文件，DM是数据存储器。
三、如果没有理想流水线预备知识3.1单周期CPU知识单周期CPU理论知识的基础，即使设计流水线也只是瞎猫遇到死老鼠的偶然，所以基础知识要打牢。
3.2寄存器(触发器)后一章中流水线寄存器的原型是数字逻辑设计中时序逻辑部分的重点内容)触发器； 我建议充分掌握其理论内容。 这里只简单表示d触发器的部分。
d触发器是最简单的触发器之一，当输入d在第一个时钟周期发生变化时，在第二个时钟周期，输出q会随着d的变化而变化。 也就是说，输出会随着输入d的变化而变化。 基于输入d的每周期变化，输出q总是延迟“d”时钟周期，其类似于d的跟随者呈现阴影的形状。 这一特性决定了是否想人为分割
四、理想流水线的关键部件被划分为4.1流水线寄存器，将CPU工作划分为五个步骤的工作处于理论层面，实际上Verilog需要在一些特殊模块中实现这一划分功能。
虽然被称为“寄存器”，但其本质仍然是触发器，对于存储什么内容，需要仔细分析分割一个指令的过程。
4.2流水线划分我们可以很容易地将一个指令的执行过程分为五个部分(也可以分为更多的部分，但这里只讨论最简单的五级流水线)，其实这个划分出现在单周期CPU设计中。 这五个阶段分别是指、解码、执行、访问、回写； “其中控制单元处于解码阶段”，这意味着我们的流水线可能在一个CPU周期内同时处理五个不同阶段的指令。 例如，考虑图1的例子。
CC5 )在CPU时钟5 )中，从纵向时间截面看，流水线当前处理五个命令，第一个命令LD X10，40 ) x1 )在下一个CPU循环中从流水线流出，第六个命令(未示出)是下一个CPU循环类似地，在另一CPU循环(例如CC1 )中，管线正好开始移动，只有第一条命令流到管线，而在CC9中，管线快结束，只有最后一条命令仍在执行。
第一指令LDX10、40(x1 )已经是第五阶段(写回，第二指令sub x11、x2、x3是第四阶段)访问，第三指令add x12、x3、x4是第三阶段)执行，第四指令LDX13、40(x1 )
图中两个器件之间的蓝色竖条是我们流水线的重要部件，流水线寄存器。 因此，从图中可以看出，流水线寄存器用作两个流水线阶段之间的“缓冲器”。
以上，通过分析某个CPU循环的流水线整体的执行状况，在流水线CPU的执行中，看起来像是分为5个阶段进行独自的工作。 而且，除了整个程序的开始和结束这一特殊时期以外，剩下的大部分时间在所有阶段都“不断”工作，每当时钟的上升沿到来时，就有一个指令从这个阶段开始
段完成对应操作并流出，同时下一条指令又立刻流入这个阶段并开始进行处理，可以类比为一条工厂的装配线，履带不断向前以固定速度滚动着，各个装配阶段的机械臂不断落下对经过的元器件进行一些操作，然后抬起，待下一个元器件经过，再次落下，这种情况正是我们流水线CPU的工作情形。4.3 流水线寄存器存些什么？
显然，不同阶段之间不可能真的相互独立，甚至可以说每个阶段之间都有着密切的数据、控制联系，所以很简单地能够想到我们要将两个阶段之间有关联的数据存入对应流水线寄存器，使得被关联的阶段能够拿到关联之阶段的相关数据，所以流水线寄存器输入的第一类信号就很明确了——相关数据。
但是问题并未就此结束，我们只有一个控制单元！（当然，如果你非要给各个阶段都增加对应控制单元，也不是不可以，但是这么做的结果将是导致硬件资源的浪费以及电路延时的增加，从而违背了我们建立流水线的初衷！）而且我们大部分的控制信号都是从控制单元出发向其他单元传送，按照我们流水线划分，控制单元在第二阶段——指令译码（Instruction Decode）；
我们不妨单从一条指令的执行角度来看，此指令的第一个CPU周期时就会将指令取出，第二个CPU周期时就会将指令送入控制器进行译码，从而产生各个控制信号；但是指令的完整执行需要五个CPU周期，后面的三个CPU周期要正确运行，不可能离得开这第二CPU周期中产生的控制信号；但是从完整的一个程序来看，这些信号也不能一直保持在“原地”，不然后序指令就只能塞在这里等待前面这条指令执行，这样的话流水线就形同虚设了。
因此，一条指令在第二CPU周期产生的控制信号不能原地滞留，需要跟着流水线一起流动，回到我们上一小节做的类比，如果生产线上面的机械臂能够识别元器件内部信息，同时我们向这个元器件内部写入一些信息告诉后面的机械臂“对这个器件，你要这么那么做”，是不是就能够在不增加控制单元的前提下将控制信号向后传递呢？所以我们向流水线寄存器输入的第二类信号也就明确了——后序相关控制信号
流水线工程划分大致如图2所示，其中流水线寄存器命名方式为：上一阶段名/下一阶段名
图2
由于我们要将控制信号和一些相关数据都顺着流水寄存器向后传递，因此每一阶段的传递都需要一个额外的变量，故我们的变量较单周期CPU而言有着数量上的陡然增长，为了代码方便管理同时为了debug时不至于头昏眼花，我们在变量命名方面也需要一些小技巧，就是在原本名称的前面加上其作用阶段的简写，比如我们EXE阶段里，ALU单元需要alu_op信号，但是这个信号才CU单元中产生，那么产生的信号命名为cu_alu_op，并将之输入IF/EXE流水寄存器，但是其对应的输出信号可以命名为exe_alu_op，这样子能够极大地方便我们编写流水线。
以EXE/MEM流水寄存器为例：
module EXE_MEM( input clk , input rst , input [31:0] wb_wD , input [31:0] exe_imm , input [31:0] exe_pc , input [31:0] exe_alu_c , input [31:0] exe_rD2 , input exe_rf_we , input exe_dram_wr , input [ 1:0] exe_wd_sel , input [ 4:0] exe_wR , output reg [31:0] mem_imm , output reg [31:0] mem_pc , output reg [31:0] mem_alu_c , output reg [31:0] mem_rD2 , output reg mem_rf_we , output reg mem_dram_wr , output reg [ 1:0] mem_wd_sel , output reg [ 4:0] mem_wR ); always @(posedge clk, posedge rst) begin if(rst) mem_imm <= 32'h0 ; else mem_imm <= exe_imm; end always @(posedge clk, posedge rst) begin if(rst) mem_pc <= 32'h0 ; else mem_pc <= exe_pc; end /*...其余的变量类似赋值*/endmodule5.4 理想流水线的局限性
其实理想流水线的功能很有限，除了使用了哈佛结构解决了结构冲突，另外两种冲突无法解决，甚至可以说一旦出现这两种冲突，整条流水线将会崩溃。
仅仅有理想流水线是远远不够的，我们还需要更多的模块和变量信号来解决数据冲突和分支冲突，此文章不涉及此类内容，后序我会对此进行补充并放置超链接。