模块功能说明

功能1：发生ld-ld违例的指令请求入队

当query到达load流水线的s2时，判断是否满足入队条件，如果在当前load指令之前有未完成的load指令,且当前指令没有被flush时，当前load可以入队。

具体入队条件如下：

1. 指令的入队请求必须有效，具体通过检查 query.req.valid 是否等于 1。如果该条件满足，系统将继续处理指令的入队。

2. 指令必须确认尚未写回到重排序缓冲区（ROB）。这一条件通过比较指令在 VirtualLoadQueue 中的写回指针与该指令分配的 lqIdx 来验证。指令只有在到达 VirtualLoadQueue 的队头，并且其地址和数据均已准备好后，才能被写回到 ROB。这一机制确保了指令执行的顺序性和数据的有效性。

3. 指令不能处于冲刷状态。为此，系统需要比较重定向指针所指向的指令与该指令的 robIdx、ftqidx及 FTQ 内的偏移（ftqoffset）。如果两者不相同，则说明该指令可以安全入队，从而避免潜在的冲突和数据不一致性。

在 LoadQueueRAR 指令成功入队后，系统会执行一系列响应操作，以确保指令被正确管理和处理。具体的入队响应操作如下：

1. 拉高 allocated 寄存器。系统将指令的 allocated 寄存器设置为高电平。这一操作的目的是明确标识该指令已成功分配到 LoadQueueRAR 中。通过将 allocated 寄存器拉高，后续的处理逻辑能够迅速识别出该指令的状态，从而避免对未分配指令的误操作。

2. 写入指令相关信息到 uop。指令的相关信息将被写入到微操作（uop）中。这些信息包括指令的类型、目标寄存器、操作数等关键信息。将这些信息存储在 uop 中，确保后续的执行阶段能够准确获取和使用这些数据，从而执行相应的操作。这一过程对于指令的正确执行至关重要。

3. 物理地址写入 PaddrModule。指令的物理地址将被写入到 PaddrModule 中。这一操作的主要目的是为后续的地址查询和管理提供支持。

4. 检测 Release 的 Valid 信号。系统将检测 release 的有效信号是否被拉高。如果该信号有效，将进一步比较物理地址是否相同。如果物理地址一致，则对应条目的 released 信号将被设置为高电平，可以用于后续操作。

功能2：检测ld-ld违例条件

在 Load 指令的处理过程中，为了确保数据的一致性和正确性，系统需要检测潜在的 Load-Load 违例。当 load 到达流水线的 s2 时，会检查RAR队列中是否存在与当前load指令物理地址相同且比当前指令年轻的load指令，如果这些 load 已经拿到了数据，并且被标记了release，说明发生 load - load 违例，被标记release的指令需要从取指重发。 该检测过程主要涉及将查询指令的物理地址和相关信息与队列中存储的指令进行对比。具体流程如下：

1. 对比 ROB 索引。通过对比两条指令的robidx识别队列中是否存在比查询指令更年轻的指令。
2. 物理地址匹配。检查这两条指令的物理地址是否相同。这一对比通过 releaseViolationMmask(w)(i) 来进行，以确定两条指令是否访问了相同的内存位置。
3. 检查 Released 标记。如果该条指令的 released 寄存器被拉高，表明该指令已被标记为释放，说明它可以被重新使用。

一旦检测到 Load-Load 违例，系统将在下一个时钟周期内将 resp.rep_rm_fetch 信号拉高，以通知其他组件发生了违例。触发 Load-Load 违例的 Load 指令将被标记为需要重新从取指阶段执行。重定向请求将在这些指令到达 ROB 队列的尾部时发出，确保指令能够在合适的时机得到正确的处理。

该过程分为两个时钟周期进行：

• 第一拍进行条件匹配，对比物理地址和指令状态，得到mask。
• 第二拍生成是否发生违例的响应信号（resp.rep_rm_fetch ）。

由于 Load-Load 违例出现的频率相对较低，因此系统会选择在指令到达 ROB 的头部时才进行处理。这种处理方式类似于异常处理，确保系统能够在合适的时机对潜在的违例情况进行响应。

功能3：released寄存器更新

released寄存器需要更新的三种情况：

1. missQueue模块的replace_req在mainpipe流水线的s3栈发起release释放dcache块，release信号在下一拍进入loadqueue。
2. probeQueue模块的probe_req在mainpipe流水线的s3栈发起release释放dcache块，release信号在下一拍进入loadqueue。
3. atomicsUnit模块的请求在mainpipe流水线的s3栈发生miss时需要释放dcache块，release信号在下一拍进入loadQueue。

release信号的到达时机可以分为以下两种情况：

1. 指令入队时到达。如果查询指令传来的paddr的高42位信号与paddr的高位信号相同，并且该指令能够成功入队将对应entry的released寄存器信号拉高
2. 指令入队后到达。如果paddrmodule中存放的paddr的高42位信号与paddr的高位信号相同,将对应的released寄存器信号拉高

值得注意的是，dcache release 信号在更新 load queue 中 released 状态位时, 会与正常 load 流水线中的 load-load 违例检查争用 load paddr cam 端口. release 信号更新 load queue 有更高的优先级. 如果争用不到资源, 流水线中的 load 指令将立刻被从保留站重发.

功能4：指令的出队

Load指令的出队需要满足以下条件其中之一：

1. 当比队列entry中存放的指令更老的指令已经全部写回到ROB时，该指令可以出队。
2. 当这条指令需要被冲刷时，通常是出现数据依赖性问题、预测错误、异常或错误的情况下，迫使系统强制性地移除该指令，以保证处理器能够恢复到一个稳定的状态。

出队执行的操作：

1. 将指令对应的 allocated 寄存器设置为低电平。这一操作的目的是标识该指令不再占用 LoadQueueRAR 的资源，从而为后续指令的入队和处理腾出空间。
2. 将entry对应的free掩码拉高，表示该条目已被释放并可供后续使用。

在load流水线的s3阶段可以向队列发送revoke信号撤销上一拍的请求。如果指令当前周期的revoke信号拉高（revoke ==1），并且在上一个周期已经入队，需要执行撤销操作：

1. 该entry对应的allocated寄存器清零
2. 该entry对应的free掩码拉高

模块功能说明

功能1：发生st-ld违例的指令请求入队

当query到达load流水线的s2时，判断是否满足入队条件，如果在当前load指令之前有地址未准备好的store指令，且当前指令没有被flush时，当前load可以入队。具体流程如下：

1. 判断入队条件：检查在当前 Load 指令之前是否存在未准备好的 Store 指令。如果存在这样的 Store 指令，并且当前 Load 指令尚未被冲刷（flush），则当前 Load 指令可以入队。
2. 分配 Entry 和 Index：在 Freelist 中，系统将获得一个可分配的 Entry 及其对应的 Index，以便为 Load 指令分配资源。
3. 保存物理地址：在 PaddrModule 中将入队的 Load 指令的物理地址保存到对应的 Entry。这一操作确保在后续访问中能够正确引用该地址。
4. 保存掩码信息：在 MaskModule 中，系统将入队的 Load 指令的掩码信息保存到对应的 Entry。掩码信息用于后续的地址匹配和数据访问。
5. 写入uop：将 Load 指令的uop信息写入到相应的结构中，以完成入队过程。

功能2：检测st-ld违例条件

在 Store 指令到达 Store 流水线的 s1 阶段时，系统会进行 Store-to-Load 违例检查。此时，Store 指令需要与 Load Queue 中已经完成访存的 Load 指令，以及在 Load 流水线 s1 和 s2 阶段正在访存的 Load 指令进行比较。这些 Load 指令可能尚未通过前递（forwarding）机制获取 Store 指令执行的结果。

具体的违例检查流程如下：

1. 物理地址匹配：在第一拍中，系统将进行物理地址匹配，并检查条件。此时，将匹配在当前 Store 指令之后的所有新的 Load 指令。如果这些 Load 指令已经成功获取了数据（datavalid），或者由于缓存未命中正在等待数据回填（dcache miss），则可以确定这些 Load 指令不会将数据前递给当前的 Store 指令。
2. 匹配 Load 指令：在第二拍中，Store 流水线中的 Store 指令根据匹配结果中的掩码（mask），在 Load Queue 的 RAW（Read After Write）结构中查找所有匹配的 Load 指令。Load Queue 中共有 32 项，这些项将被平分为4组。每组从 8 项中选出一个最老的 Load 指令，最多可得到 4 个候选最老的 Load 指令。
3. 选择最老的 Load：在第三拍中，从上述 4 个候选最老的 Load 指令中，系统将选出一个最老的 Load 指令，作为最终的目标。
4. 处理违例情况：在第四拍中，如果在两条 Store 流水线中均发生了 Store-to-Load 违例，系统将从各自的 Queue 中匹配到的最老 Load 指令中选出一个更老的 Load 指令，以产生回滚请求并发送给重定向模块（Redirect）。此时，违例的条件包括：
   • Load 和 Store 的地址相同。
   • Load 指令比 Store 指令年轻。
   • Load 指令已经成功获取了数据。

功能3：指令的出队

Load指令的出队需要满足以下条件其中之一：

1. 当比队列entry中存放的指令更老的指令已经全部写回到ROB时，该指令可以出队。
2. 当这条指令需要被冲刷时，通常是出现数据依赖性问题、预测错误、异常或错误的情况下，迫使系统强制性地移除该指令，以保证处理器能够恢复到一个稳定的状态。

出队执行的操作：

1. 将指令对应的 allocated 寄存器设置为低电平。这一操作的目的是标识该指令不再占用 LoadQueueRAR 的资源，从而为后续指令的入队和处理腾出空间。
2. 将entry对应的free掩码拉高，表示该条目已被释放并可供后续使用。

在load流水线的s3阶段可以向队列发送revoke信号撤销上一拍的请求。如果指令当前周期的revoke信号拉高（revoke ==1），并且在上一个周期已经入队，需要执行撤销操作：

1. 该entry对应的allocated寄存器清零
2. 该entry对应的free掩码拉高

模块功能说明

功能1：需要重发的指令请求入队

根据是否满足以下条件以及freelist是否可以分配的空闲槽位决定能否直接入队：

1. enq_X.valid 信号有效。
2. 即将入队的项不需要重定向。
3. 该项被标记为需要重发(enq.bits.rep_info.need_rep)。
4. 没有异常。在入队时，必须确保没有异常发生。如果当前指令处于异常状态，入队操作应被禁止，以防止无效指令的执行。

功能2：指令重发解锁

LoadQueueReplay 中的指令出队分三拍：

在重发过程中，根据重发的原因和当前条件解锁相应项。在不满足解锁条件时，将会被阻塞，无法参与重发仲裁。其中C_BC（Dcache 块冲突）、C_NK（oad_unit 在 S1、S2 阶段发生 store-load 违例）、C_DR（Dcache miss 且 MSHR 满）、C_WF（路径预测失败）无需条件即可立即重发。

其他重发原因和对应的解锁条件如下：

1. C_MA（store_load 预测违例）：已经被分配入队并且store准备好了相应的地址，具体如下：
   1. store unit 的地址信号有效，且 sqIdx 与被阻塞的 Idx 相同，store 地址未发生 TLB miss。
   2. 被阻塞的 SeqIdx 在 store_queue 发送的 stAddrReadySqPtr 之前。
   3. 非严格阻塞，且阻塞的 SeqIdx 在 stAddrReadyVec 的向量组内。
   4. store queue 为空，无未处理项。
2. C_TM（TLB Miss）：resp信号有效，并且输入的id号等于Tlb Hint的id号，或者replay_all信号有效。
3. C_FF（store_load 数据前递失败）：因为数据前递失败导致指令重发的释放条件有下面四条：
   1. store unit 的数据信号有效，且 sqIdx 与被阻塞的 Idx 相同。
   2. 被阻塞的 SqIdx 在 store_queue 发送的 stDataReadySqPtr 之前。
   3. 阻塞的 SeqIdx 在 stDataReadyVec 的向量组内。
   4. store queue 为空，无未处理项。
4. C_DM（Dcache Miss）：Dcache 的信号有效，且 tl_d_channel.mshrid 与阻塞的 missMSHRId 相同。
5. C_RAR（RAR queue 没有回应）：RAR 未满，或 lqIdx 在 ldWbPtr 之前。
6. C_RAW（RAW 没有回应）：RAW 未满，或 lqIdx 在 stAddrReadySqPtr 之前。

功能3：指令重发优先级

LoadQueueReplay有3种选择调度方式：

1. 根据入队年龄

   LoadQueueReplay使用3个年龄矩阵(每一个Bank对应一个年龄矩阵)，来记录入队的时间。年龄矩阵会从已经准备好可以重发的指令中，选择一个入队时间最长的指令调度重发。

2. 根据Load指令的年龄

   LoadQueuReplay可以根据LqPtr判断靠近最老的load指令重发，判断宽度为OldestSelectStride=4。

3. DCache数据相关的load指令优先调度

   • LoadQueueReply首先调度因L2 Hint调度的重发（当dcache miss后，需要继续查询下级缓存L2 Cache。在L2 Cache回填前的2或3拍，L2 Cache会提前给LoadQueueReplay唤醒信号，称为L2 Hint）当收到L2 Hint后，LoadQueueReplay可以更早地唤醒这条因dcache miss而阻塞的Load指令进行重发。

   • 如果不存在L2 Hint情况，会将其余Load Replay的原因分为高优先级和低优先级。高优先级包括因dcache缺失或st-ld forward导致的重发，而将其他原因归纳为低优先级。如果能够从LoadQueueReplay中找出一条满足重发条件的Load指令（有效、未被调度、且不被阻塞等待唤醒），则选择该Load指令重发，否则按照入队顺序，通过AgeDetector模块寻找一系列load replay queue项中最早入队的一项进行重发。

功能4：指令重发逻辑

1. Load_unit s3过来的请求根据enq.bits.isLoadReplay判断是否是已经从replay_queue出队的序列，如果是已经出队的序列，根据是否needReplay和有异常做下一步的判断，如果有异常或者不需要重发则释放这个槽位，并从agedetector里面把该项出队，如果需要重发则将这个项对应的scheduled位置为false来参与后续的出队仲裁竞争。

2. 从freelist中选出发给load unit的有效项，项数为load unit的宽度（即有几条load unit的流水线），根据优先级来进行出队。

3. 第0拍将数据传递给第1拍由s0_can_go控制，当s0_can_go为1时才能将0拍得到的数据发给第一拍，s0_can_go有效的条件是s0被重定向或者s1_can_go为1。

4. 第一拍从vaddr内部取出需要的虚拟地址，发给下一拍流水线。 ColdCouter的值在0到12之间，上一拍没有被阻塞并且整个过程没有发生重定向的时候，向load unit发送请求。

5. 发送给下一拍流水线的数据受s1_can_go控制，s1_can_go为1的条件是:

• ColdCouter的值在0到12之间 且 上一拍完成操作(未被阻塞)或者不需要发送数据两者之一。

• 发生数据的重定向。

6. 第二拍将收到第一拍的数据发送给对应的load unit,获取仲裁权限，完成重发指令的任务。

模块功能说明

功能1：Uncache指令请求入队

LoadQueueUncache 负责接收来自 LoadUnit 0、1、2 三个模块的请求，这些请求可以是 MMIO 请求，也可以是 NC 请求。

1. 首先，系统会根据请求的 robIdx 按照时间顺序（从最老到最新）对请求进行排序，以确保最早的请求能优先分配到空闲项，避免特殊情况下因老项回滚（rollback）而导致死锁。

2. 进入入队处理的条件是：请求没有重发、没有异常，并且系统会根据 FreeList 中可分配的空闲项依次为请求分配项。

3. 当 LoadQueueUncache 达到容量上限，且仍有请求未分配到项时，系统会从这些未分配的请求中选择最早的请求进行 rollback。

UncacheBuffer 的入队分为 s1 和 s2 两个阶段：

s1：

• 请求收集：通过 io.req.map(_.bits) 收集所有请求的内容，形成 s1_req 向量。

• 有效性标记：通过 io.req.map(_.valid) 收集所有请求的有效性，形成 s1_valid 向量。

s2：

执行入队操作，主要分为以下几步：

• 使用 RegEnable 将 s1 阶段的请求 s1_req 注册到 s2_req，确保在请求有效时保持其状态。

• 通过以下条件生成s2_valid向量，判断每个请求是否有效：

  1. RegNext(s1_valid(i))：确保请求在 s1 阶段有效。

  2. !s2_req(i).uop.robIdx.needFlush(RegNext(io.redirect))：确保请求的 ROB 索引不需要因重定向而被刷新。

  3. !s2_req(i).uop.robIdx.needFlush(io.redirect)：确保请求的 ROB 索引不需要因当前重定向而被刷新。

• 检查每个请求是否需要重发，结果存储在 s2_need_replay 向量中。

• 在 s2 阶段，使用 s2_enqueue 向量来决定哪些请求成功入队。入队条件包括：

  • s2_valid(w)：请求在 s2 阶段有效。

  • !s2_has_exception(w)：请求没有异常。

  • !s2_need_replay(w)：请求不需要重发。

  • s2_req(w).mmio：请求是一个内存映射 IO（MMIO）请求。

• 通过 enqValidVec 和 enqIndexVec 的有效管理，确保每个加载请求在满足有效性和可分配条件时能够正确地申请和分配FreeList槽位。

功能2：Uncache指令的出队

1. 当一个项完成 Uncache 访问操作并返回给 LoadUnit ，或被 redirect 刷新时，则该项出队并释放 FreeList 中该项的标志。

   具体流程如下：

   • 计算freeMaskVec掩码，用于标记每个槽位的释放状态，指示相应槽位是否可用。

   • 如果当前条目被选择 (e.io.select) 且其输出信号有效 (e.io.ldout.fire)，则对应槽位的释放状态被标记为 true，表示该槽位可用。

   • 如果接收到刷新信号 (e.io.flush)，同样将对应槽位的释放状态设置为 true。

2. 同一拍可能有多个项出队。返回给 LoadUnit 的请求，会在第一拍中选出，第二拍返回。

3. 其中，可供处理 uncache 返回请求的 LoadUnit 端口是预先设定的。当前，MMIO 只返回到 LoadUnit 2；NC 可返回到 LoadUnit 1\2。在多个端口返回的情况下，利用 uncache entry id 与端口数的余数，来指定每个项可以返回到的 LoadUnit 端口，并从该端口的候选项中选择一个项进行返回。

功能3：Uncache交互逻辑

1. 发送 req

第一拍先从当前已准备好 uncache 访问中选择一个，第二拍将其发送给 Uncache Buffer。发送的请求中，会标记选中项的 id，称为 mid 。其中是否被成功接收，可根据 req.ready 判断。

2. 接收 idResp

如果发送的请求被 Uncache Buffer 接收，那么会在接收的下一拍收到 Uncache 的 idResp。该响应中，包含 mid 和 Uncache Buffer 为该请求分配 entry id（称为 sid）。LoadQueueUncache 利用 mid 找到内部对应的项，并将 sid 存储在该项中。

3. 接收 resp

待 Uncache Buffer 完成该请求的总线访问后，会将访问结果返回给 LoadQueueUncache。该响应中，包含 sid。考虑到 Uncache Buffer 的合并特性（详细入队合并逻辑见 Uncache），一个 sid 可能对应 LoadQueueUncache 的多个项。LoadQueueUncache 利用 sid 找到内部所有相关项，并将访问结果传递给这些项。

功能4：Uncache回滚检测

freelist 没有空闲表现导致 MMIO Load 进入 UncacheBuffer 失败时需要进行 rollback，此 时需要根据 robidx 选择不能入队的 MMIO 中最老的指令进行 rollback。整个流程分为以下几个周期：

• Cycle 0：进行 uncache 请求入队。

• Cycle 1：选择最旧的 uncache 加载请求。

• Cycle 2：发出重定向请求。

  • 从 load 流水线中选择最旧的 load 请求。

  • 根据检测到的拒绝情况准备重定向请求。

  • 如果重定向请求有效，则发出请求。

使用 selectOldestRedirect 函数来选择最旧的重定向请求，具体步骤如下：

• 比较向量生成：

  • 创建一个比较向量 compareVec，用于判断请求的顺序，比较每个请求的 ROB 索引。

• 生成独热编码结果：

  • resultOnehot 向量根据有效性和比较结果生成，标记出最旧的可重定向请求。

模块功能说明

功能1：store指令请求入队

1. StoreQueue 每次最多会有 2 个 entry 入队，通过入队指针 enqPtrExt 控制。在 dispatch 阶段最多可以分配2个 entry，指针每次右移 1 位或 2 位。

2. 通过比较入队指针 enqPtrExt 和出队指针 deqPtrExt 得出已经在队列中有效 entry。只有空闲的 entry 大于需要请求入队的指令时才会分配 entry 入队。

3. 入队时设置 entry 的状态位 allocated 为 true，其他状态位都为 false。

功能2：指令的出队

1. StoreQueue 每次最多会有2个 entry 出队释放，通过输出指针 deqPtrExt 控制，每次指针右移一位或 2 位。

2. STQ 出队的触发信号是isbuffer(i).fire延后一拍的信号，因为 sbuffer 的写动作要用 2 拍完成，在 sbuffer 写完成之前 entry 不释放可以继续 forward 数据。

功能3：从store的地址流水线写回结果

store 的地址从保留站发出来后会经过 StoreUnit 流水线，通过lsq/lsq_replenish总线接口在S1/S2把地址信息更新到store queue 中：

1. 在store流水线s1阶段，获得 DTLB hit/miss 的信息, 以及指令的虚拟地址vaddr和物理地址paddr

2. 在store流水线s2阶段，获得 mmio/pmp 信息，以及是否是mmio地址空间操作等信息

功能4：接收 store 的数据到STQ 的Datamodule

store 的数据是从与地址不同的保留站发出来的后经过StdExeUnit流水线，通过storeDataIn接口在S0/S1把数据写到对应的entry的datamodule里:

1. S0：给datamodule发写请求

2. S1：写入数据到datamodule同时更新 entry 的datavalid属性为True，接收 store 的mask到STQ 的Datamodule

store 的地址从保留站发出来之后会经过StoreUnit流水线，s0_mask_out在S0把地址中的mask信息更新到对应entry的datamodule里。

功能5：为 load 提供 forward 查询

1. load 需要查询 store queue 来找到在它之前相同地址的与它最近的那个 store 的数据。
   • 查询总线(io.forwrd.sqIdx) 和 StoreQueue 的出栈指针比较，找出所有比 load 指令老的 storeQueue 中的 entry。以 flag 相同或不同分为2种情况：

(1)same flag-> older Store范围是 (tail, sqIdx)，如图3(a)所示

(2)different flags-> older Store范围是(tail, VirtualLoadQueueSize) +(0, sqIdx)，如图3(b)所示

图3：StoreQueue前递范围生成

2. 查询总线用va 和pa同时查询，如果发现物理地址匹配但是虚拟地址不匹配；或者虚拟地址匹配但是物理地址不匹配的情况就需要将那条 load 设置为 replayInst，等 load 到 ROB head 后replay。

3. 如果只发现一笔 entry 匹配且数据准备好，则直接 forward

4. 如果只发现一笔 entry 匹配且数据没有准备好，就需要让保留站负责重发

5. 如果发现多笔匹配，则选择最老的一笔 store forward，StoreQueue以1字节为单位，采用树形数据选择逻辑,如图4

图4：StoreQueue前递数据选择

6. store 指令能被 load forward的条件：

   • allocated：这条 store 还在 store queue 内，还没有写到 sbuffer
   • datavalid：这条 store 的数据已经就绪
   • addrvalid：这条 store 已经完成了虚实地址转换，得到了物理地址

7. SSID (Store-Set-ID) 标记了之前 load 预测执行失败历史信息，如果当前 load 命中之前历史中的SSID，会等之前所有 older 的 store 都执行完；如果没有命中就只会等pa相同的 older Store 执行完成。

功能6：MMIO与NonCacheable Store指令

• MMIO Store指令执行:

1. MMIO 空间的 store 也只能等它到达 ROB 的 head 时才能执行，但是跟 load 稍微有些不同，store 到达 ROB 的 head 时，它不一定位于 store queue 的尾部，有可能有的 store 已经提交，但是还在 store queue 中没有写入到 sbuffer，需要等待这些 store 写到 sbuffer 之后，才能让这条 MMIO 的 store 去执行。

2. 利用一个状态机去控制MMIO的store执行

   • s_idle：空闲状态，接收到MMIO的store请求后进入到s_req状态;

   • s_req：给MMIO通道发请求，请求被MMIO通道接受后进入s_resp状态;

   • s_resp：MMIO通道返回响应，接收后记录是否产生异常，并进入到 s_wb 状态

   • s_wb：将结果转化为内部信号，写回给 ROB，成功后,如果有异常，则进入s_idle, 否则进入到 s_wait 状态

   • s_wait：等待 ROB 将这条 store 指令提交，提交后重新回到 s_idle 状态

• NonCacheable Store指令执行：

1. NonCacheable空间的store指令，需要等待上一个NonCacheable Store指令提交之后，才能从StoreQueue按序发送请求

2. 利用一个状态机去控制NonCacheable的store执行

   • nc_idle：空闲状态，接收到NonCacheable的store请求后进入到nc_req状态;

   • nc_req：给NonCacheable通道发请求，请求被NonCachable通道接受后, 如果启用uncacheOutstanding功能，则进入nc_idle，否则进入nc_resp状态;

   • nc_resp：接受NonCacheable通道返回响应，并进入到nc_idle状态

功能7：store指令提交以及写入SBuffer

StoreQueue采用提前提交的方式进行提交。

• 提前提交规则:

1. 检查进入提交阶段的条件

   (1)指令有效。

   (2)指令的ROB对头指针不超过待提交指针。

   (3)指令不需要取消。

   (4)指令不等待Store操作完成，或者是向量指令

2. 如果是CommitGroup的第一条指令, 则

   (1)检查MMIO状态: 没有MMIO操作或者有MMIO操作并且MMIO store以及提交。

   (2)如果是向量指令，需满足vecMbCommit条件。

3. 如果不是CommitGroup的第一条指令，则：

   (1)提交状态依赖于前一条指令的提交状态。

   (2)如果是向量指令，需满足vecMbCommit条件。

提交之后可以按顺序写到 sbuffer, 先将这些 store 写到 dataBuffer 中，dataBuffer 是一个两项的缓冲区（0，1通道），用来处理从大项数 store queue 中的读出延迟。只有0通道可以编写未对齐的指令,同时为了简化设计，即使两个端口出现异常，但仍然只有一个未对齐出队。

• 写入sbuffer的过程：

1. 写入有效信号生成

2. 0通道指令存在非对齐且跨越16字节边界时：

   (1) 0通道的指令已分配和提交

   (2) dataBuffer的0，1通道能同时接受指令，

   (3) 0通道的指令不是向量指令，并且地址和数据有效；或者是向量且vsMergeBuffer以及提交。

   (4) 没有跨越4K页表；或者跨越4K页表但是可以被出队,并且1）如果是0通道：允许有异常的数据写入; 2）如果是1通道：不允许有异常的数据写入。

   (5) 之前的指令没有NonCacheable指令，如果是第一条指令，自身不能是Noncacheable指令

3. 否则，需要满足：

   (1) 指令已分配和提交。

   (2) 不是向量且地址和数据有效，或者是向量且vsMergeBuffer以及提交。

   (3) 之前的指令没有NonCacheable和MMIO指令，如果是第一条指令，自身不能是Noncacheable和MMIO指令。

   (4) 如果未对齐store，则不能跨越16字节边界，且地址和数据有效或有异常

• 地址和数据生成：

1. 地址拆分为高低两部分：

   (1) 低位地址：8字节对齐地址

   (2) 高位地址：低位地址加上8偏移量

2. 数据拆分为高低两部分：

   (1) 跨16字节边界数据：原始数据左移地址低4位偏移量包含的字节数

   (2) 低位数据：跨16字节边界数据的低128位；

   (3) 高位数据：跨16字节边界数据的高128位；

3. 写入选择逻辑：

   如果dataBuffer能接受非对齐指令写入,通道0的指令是非对齐并且跨越了16字节边界，则检查：

   (1) 是否跨4K页表同时跨4K页表且可以出队: 通道0使用低位地址和低位数据写入dataBuffer; 通道1使用StoreMisaligBuffer的物理地址和高位数据写入dataBuffer

   (2) 否则: 通道0使用低位地址和低位数据写入dataBuffer; 通道1使用高位地址和高位数据写入dataBuffer

   (3) 如果通道指令没有跨越16字节并且非对齐，则使用16字节对齐地址和对齐数据写入dataBuffer

   (4) 否则，将原始数据和地址写给dataBuffer

功能8：强制刷新sbuffer

StoreQueue采用双阈值的方法控制强制刷新Sbuffer：上阈值和下阈值。

1. 当StoreQueue的有效项数大于上阈值时， StoreQueue强制刷新Sbuffer
2. 直到StoreQueue的有效项数小于下阈值时，停止刷新Sbuffer。

模块功能说明

功能1：load指令请求入队

在调度阶段，保留站通过入队（enq）总线向VirtualLoadQueue发起入队请求，最多支持六组并发请求。成功入队的条件包括以下几点：

1. StoreQueue 和 LoadQueue 有预留空间：确保LoadQueue有足够的容量来接收新的加载指令，以避免队列溢出。确保StoreQueu有预留空间则是基于数据一致性和避免指令阻塞的考虑，因为store指令入队阻塞可能会导致load指令无法正确读取或forward到数据。
2. 入队请求有效：入队请求必须是合法的，确保指令在调度过程中可以被正确处理。
3. 指令未被冲刷：确保指令在入队时没有被系统标记为无效或被撤销。

成功入队之后，系统会执行以下操作：

1. 将指令的lqidx作为索引，将对应的allocated寄存器置1，bits信息写入uop寄存器。
2. 计算新的lqidx值，作为enq_resp传送给保留站。

功能2：接收load流水线写回的数据

在 load 流水线的s3阶段，load unit会将指令执行的信息通过总线 ldin 写回到 VirtualLoadQueue。具体写回信息包括：

1. 是否发生了异常以及异常类型
2. dcache是否命中
3. tlb是否命中
4. 是否为mmio指令
5. 是否为软件预取或者硬件预取
6. 是否需要重发以及重发的原因
7. 写uop的使能信号

写回需要满足的条件如下：

1. ldin 总线的 valid 信号需要拉高，表明当前正在进行有效的数据传输。
2. 指令不应需要重发（即 need_rep 信号为 0），否则将影响写回的正常进行。

在满足写回条件后，系统将生成相应的写回响应，具体包括以下几个方面：

1. 如果在执行过程中发生了异常、TLB命中或软件预取操作，addrvalid 信号将被置为 1，表示地址信息有效。
2. 如果在执行过程中发生了异常、MMIO操作、DCACHE命中并且不需要重发，或是软件预取操作，datavalid 信号将被置为 1，表示数据有效。
3. 指令在流水线的 S3 阶段有效（注意：不能是硬件预取指令）。当 ldin 总线的写使能信号 data_wen_dup 拉高时，将更新队列中的uop信息，以确保指令的状态及时反映。

系统将addrvalid和datavalid分开进行处理是考虑到在一些情况下，地址可以被重用，而数据可能需要重新请求（如dcache miss/mmio/软件预取等）。分开标识可以减少流水线停顿，允许处理器在地址有效时继续执行其他指令，而不必等待数据有效性确认，从而优化整体性能。

功能3：load指令的出队(提交)

1. 出队时机：当被分配的entries（allocated为高）到达队头，同时allocated与committed都为1时，表示可以出队，如果是向量load，需要每个元素都committed。