灵犀Core v0.58.1 微架构合约¶

本页是中文摘要；完整规范来源为 rtl/LinxCore/docs/architecture/microarchitecture.md。

基线 super标量合约¶

灵犀Core 是灵犀指令集 v0.58.1 的规范超标量乱序核心。它精确地退出，无序执行，并保留块排序跨标量和引擎支持工作的架构控制模型。

当前基线限制：

获取宽度：4
调度宽度：4
问题宽度：最多 4
提交宽度：最多 4
路易斯安那州立大学宽度：1

这些限制是当前 v0.58.1 闭合基线。更广泛的问题或多 LSU 扩展是一个后续轨道，而不是这里规范合同的一部分。

架构状态模型¶

灵犀Core 必须保留以下架构状态类：

标量，灵犀指令集 v0.58.1 定义的控制和特权状态，
CSR、陷阱、MMU 和中断-可见状态，
BSTART、BSTOP 的块可见架构状态和边界权威重定向，
通过 block_uid 和 block_bid 动态块标识，
通过 ROB 精确退休命令，
通过微指令和块级元数据跟踪可见的动态身份。

实现私有预测器、队列、重放或调度状态可能存在，但它绝不能创建第二台退役、恢复或阻塞的机器。

机器组织¶

灵犀Core 分为以下主要架构域：- 前端获取和指令传递， - 解码、排序 ID 分配和重命名， - 重命名后调度、发布和执行集群， - LSU 和内存排序机器， - ROB 和精确提交机制， - 块控制机械（BISQ、BCTRL、BROB、BID 流量）、 - 通过块结构选择的集成引擎， - 跟踪和可观察性生产者。

本文档的其余部分冻结了跨这些域的合同。

模块分解合约¶

灵犀Core 被指定为命名模块的层次结构。模块分解是建筑合同的一部分，因为管道所有权、区块所有权和跟踪所有权必须在 pyCircuit、RTL 中保持可检查性生成、跟踪生产和启动工具。

阶段到模块规则¶

每个架构上可见的阶段令牌必须映射到专用模块业主。
集成包装器可以组成阶段模块，但它们不能吸收将状态阶段化为匿名胶水。
共享帮助程序文件可以提供类型、组合帮助程序或打包的帮助程序元数据，但阶段本地状态必须保留在所属阶段模块中。
如果启动 shell 绕过阶段源，则替换源必须仍然向下游解码、跟踪和提供相同的命名阶段边界比较工具。

详细的结构目录规范如下：

rtl/LinxCore/docs/architecture/module-catalog.md
rtl/LinxCore/docs/architecture/pipeline-stage-catalog.md

管道合同（LC-MA-PIPE-001）- 阶段所有权必须在前端、解码、重命名、发布、¶

执行并提交；不允许隐藏的直通塌陷。 - 每个架构上可见的阶段必须保留为 pyCircuit 中的一个模块层次结构，作为直接阶段模块或作为专用所有者模块在后端家族内部。 - 提交行为必须保持精确并按架构退休排序。 - ROB 簿记必须在多个提交周期中保持一致。 - BSTART和BSTOP是D2解析的ROB可见边界微指令；他们做不需要 IQ 或 FU 问题就能在架构上变得可见。

当前提升的关闭切片¶

当前推广阶段合约涵盖前端/解码路径、重命名后调度路径，以及来自 I-F0 的基线问题/唤醒切片通过W1：

I-F0、I-F1、I-F2、I-F3、I-F4、Instruction Buffer
B-F0、B-F1、B-F2、B-F3、B-F4
D1、D2、D3
S1、S2、IQ
P1、I1、I2、E1、W1

除了提升的切片之外的后续执行/写回细节可以通过以下方式细化未来的规范更新，但不得与以下规则相矛盾。

IFU 合约（I-SIDE 与 B-SIDE）¶

IFU 由两个解耦引擎组成。I-SIDE 拥有 I-F0..I-F4 和 Instruction Buffer；B-SIDE 拥有 B-F0..B-F4。两个引擎通过 request、prediction、 training、redirect ready/valid 接口交互，独立反压、不锁步。

I-F0¶

接受/选择 PC；
分配 request ID、STID 和 epoch；
寄存 I-SIDE 请求并发送相关联的 B-SIDE 预测请求。

I-F1¶

对同一虚拟 PC 和请求身份并行启动 ITLB 与 L1I；
不允许串行实现为 ITLB 完成后才启动 L1I。

I-F2¶

汇合 ITLB 结果和 L1I tag/data 查询状态；
ITLB miss 启动页表遍历并产生 I-SIDE inner flush；
inner flush 只清除对应 STID/epoch 的年轻 I-SIDE 工作和陈旧 cache 响应，不是 OOO/global flush；
L1I miss 保留请求身份并进入 refill。

I-F3¶

保存一个 cacheline、ECC/refill、byte cursor 和跨 line carry；
向 I-F4 提供有序字节流；
不做完整译码，也不做跳转预测。

I-F4¶

是真实第 4 级，与 Instruction Buffer 相互独立；
判断 2/4/6/8-byte 长度并拼成完整指令；
只识别 BSTART/BSTOP 类 block boundary；
把每条指令零扩展成固定 64-bit insn64；
按程序顺序写入 Instruction Buffer；
不译码通用 opcode、operand、immediate、branch kind/target 或 template。

Instruction Buffer¶

按 STID 分区，位于 I-F4 与 D1 之间；
每项保存 PC、原始长度、insn64、boundary bits、fault、 request/checkpoint 和相关 B-SIDE prediction metadata；
每周期向 D1 提供最多四条连续 64-bit 指令。

B-F0..B-F4¶

B-F0：L0/NLP next-line prediction、投机 checkpoint、GHR/GHRQ 快照；
B-F1：uBTB 类型/目标和投机 RAS；
B-F2：PBTB/BTB 类型/目标和 BIM 方向；
B-F3：short/medium-history TAGE，启动 IBTB；
B-F4：基于匹配 I-F4 boundary metadata 的 static prediction、 long-history TAGE、IBTB/loop 结果和 final arbitration。

provider rank 为 B-F4 > B-F3 > B-F2 > B-F1 > B-F0 > sequential。B-F4 内 exact RAS return 或 high-confidence IBTB 赢得对应 target；direction rank 为 loop > long-TAGE > short-TAGE > BIM > static；BTB 提供 direct target。backend restart 优先级更高，但属于 typed-recovery source，不是 prediction provider。

后级 B-stage 纠正已经驱动 I-SIDE 的预测时，inner-flush I-SIDE 并从 I-F0 重启；B-F4 是最后一个 prediction-driven inner flush 点。其 final prediction record 随每条指令进入 D1。B-F4 之后，Dispatch 校验 direct/call，BRU E1 校验 conditional direction 和 indirect/return target； mismatch 使用 BRU flush/recover 并发布 frontend restart。

解码并重命名-uop 合约（`D1` 至 `D3`）¶

D1¶

D1 每周期从 Instruction Buffer 读取最多四条程序顺序连续的 64-bit 指令。
D1 首次完成完整 opcode、operand、immediate、异常及 split/fuse 译码。下游不再重新切分变长字节流。
解码组的分配是全有或全无；如果整个小组不能分配成功，管道停止并重试整个组。
D1 可以拆分或融合解码的工作，但必须发出较旧的拆分工作在较新的指令被消耗之前。
D1 输出微指令已经携带解码的操作码或微指令语义、固定操作数槽、架构操作数标签、扩展立即值和块/顺序元数据。

D2¶

D2 是重命名请求和翻译阶段。
D2 在一个解码组中保留解码槽程序序。
D2 解析边界元数据并准备 ROB 可见的边界 uops。
D2 具有规范的建筑 uop 形状：

text { valid, thread_id, pc, opcode, uop_type, src[3], dst[1], imm, imm_type, imm_valid, rid, bid, lsid, sob, eob, boundary_type, boundary_target, pred_taken, insn_len, insn_raw }- 源槽使用操作数类别 {P, T, U, CARG}。 - 目的地槽位使用{P, T, U}； CARG 仅包含源代码。 - P 搭载建筑 atag。 - T 搭载 t_rel。 - U 搭载 u_rel。 - CARG仅携带type=CARG；实际的块参数通过以下方式解决 bid 而不是一个独立的操作数id。

D3¶

D3 是重命名的 uop 锁存器边界。
D3 保留语义操作数身份，同时还携带解析的后期需要的后端标签形式。
P 保留了 atag 并增加了 ptag。
T 保留了 t_rel 并添加了已解析的 ttag。
U 保留了 u_rel 并添加了已解析的 utag。
CARG 在 D3 处解析为块范围的 CARG 文件，索引为 bid；它不会继续作为 IQ 可见的操作数有效负载。

重命名规则- `P` 重命名是基于地图的。¶

CMAP 是提交的重命名映射。
SMAP 是可重命名的推测地图。
MapQ 记录相对于 CMAP 的推测 P 重命名增量。
MapQ 仅适用于 P 类型的目的地。
恢复是指令精确的：MapQ 切割点由 rid 键入，而不是只是bid。
默认刷新重放边界保持映射直至并包括 young-squash 重定向路径的刷新指令（<= flush_rid）。
同周期P重命名记账使用稳定的FIFO插入顺序导出来自 rid + decode_slot。
T 和 U 不使用 CMAP、SMAP 或 MapQ。
T 从 T_FIFO 分配； U从U_FIFO分配。
相同周期的 T 和 U 分配按解码时隙顺序执行。
每个区块正好有一个 CARG。
CARG 由 bid 隐式标识，并且不独立重命名。

重命名后调度合约（`S1`、`S2` 和 `IQ`）¶

S1¶

S1 是第一个重命名后调度准备阶段。
S1 从 D3 接收重命名的微指令，根据执行情况对每个微指令进行分类或问题类，选择目标物理IQ，并查询操作数准备好用于初始化最终 IQ 条目的状态。

S2- `S2` 是实际的 IQ 写入阶段。¶

S2从S1接收路由和注释的uop并执行真实的排队到选定的下游 IQ 中。

IQ 路由和入队规则¶

架构路由规则是类型导向的：目标物理 IQ 是解码或重命名的执行类加上固定优先级的函数具有多个合法队列的类的物理队列选择策略。
S1 执行路由选择和就绪状态查询。
S2 执行实际的 IQ 条目写入。
CARG不参与S1或S2 IQ路由；它已经是具体化到位于 D3 的 CARG 文件中。
当 S1 和 S2 在一个解码或重命名组中保留程序序时呈现多个同周期排队尝试。
BBD 不输入智商；边界处理必须在 S2 之前解决将 uop 写入 IQ 结构。

物理智商布局- 痕迹可见的外部命名和工具必须保留黄金¶

uop_kind 映射（issq_alu、issq_bru、issq_agu、issq_std、 issq_fsu、issq_sys、issq_cmd、...）。 - 物理智商可以在内部合并或拆分，但它们必须保留大学开设的建筑课程。 - 当前的物理智商设置为： - alu_iq0 - shared_iq1 - bru_iq - agu_iq0 - agu_iq1 - std_iq0 - std_iq1 - cmd_iq - 基线物理实现为每个端口提供两个入队/写入端口身体智商。 - 架构级别到物理 IQ 映射的基线是： - ALU -> alu_iq0，否则溢出到 shared_iq1 - BRU -> bru_iq - AGU -> agu_iq0，否则溢出到 agu_iq1 - STD -> std_iq0，否则溢出到 std_iq1 - FSU -> shared_iq1 - SYS -> shared_iq1 - CMD -> cmd_iq - 如果针对一个 IQ 的同周期入队尝试次数多于其可接受的数量，则当前解码宽度组中较旧的指令以解码时隙获胜订单。

准备表初始化¶

ready_table_p、ready_table_t 和 ready_table_u 代表非规格仅准备。
只有当相应的产生值是时才可以设置就绪表位架构稳定，以后不会被普通人撤回仍然投机的生产商的取消或清仓。
S1 通过查询相应的就绪表来初始化操作数就绪情况：
P 通过 ready_table_p[ptag]
T 通过 ready_table_t[ttag]
U 通过 ready_table_u[utag]

危险和重赛合同 (LC-MA-HAZ-001)- 唤醒、记分板和重放控制必须保留确定性问题¶

合法性。 - 重定向、刷新和重放不得提交较新的错误路径状态。

IQ 驻留、挑选和发放规则¶

每个 IQ 条目携带每个源的 src_valid 和 src_ready 状态。
默认情况下，无效的源操作数被视为就绪。
未准备好的有效源使驻留在 IQ 中的条目处于等待状态用于唤醒。
仅当 IQ 条目的所有有效源操作数都符合选择条件时已准备就绪，条目尚未 inflight。
选择政策是最早准备好的优先。
Pick 不会立即从 IQ 中删除条目。
当选择一个条目时，该条目仍然有效并转换为 inflight状态。
如果随后下游问题进展失败，则不会重新插入该条目；相反，inflight 被清除，并且该条目有资格在以后进行重试。
该架构禁止针对普通问题采用“拾取然后重新插入”模型取消或重试。
真正的IQ入口释放点是I2：仅在uop到达之后 I2 并确认不可取消 IQ 是否清除该条目的 valid 状态。

就绪表与投机就绪表¶

ready_table 仅适用于非投机准备。
投机准备状态处于带有 is_spec 标记的 IQ 进入状态。
操作数就绪的合并规则是： src_ready = src_ready_nonspec || src_ready_spec

管道和唤醒时序- 提升的问题片中使用的管道阶段是`P1 -> I1 -> I2 -> E1 ->¶

W1。 - 唤醒不得影响同一周期内的pick：周期N的唤醒变得可见，可在周期N+1进行拾取。 - 基线延迟到唤醒映射为： -lat=1 -> wakeup at P1-lat=2 -> wakeup at I2-lat=3 -> wakeup at E1-lat=4 -> wakeup at W1`

`P1`、`I1`、`I2`、`E1` 和 `W1`¶

P1 选择就绪的非 inflight IQ 条目并标记所选条目 inflight。
I1 负责决定哪些源操作数需要物理操作数读入当前的问题尝试。
I1 在整个集合中执行全局操作数读取和 RF 读取端口仲裁当前周期中选取的微指令数。
如果选定的 uop 丢失所需的 I1 读端口仲裁，则尝试本周期取消：IQ 输入保持有效，inflight 被清除，并且uop恢复正常的未来选秀资格。
I2 是问题确认边界和 IQ 释放点。
E1 是问题确认后的第一个执行阶段。
W1 是架构上可见的后期解析和唤醒阶段提升基线切片。

寄存器文件仲裁- 读取端口可能会发生争用；默认 `int_rf_rports` 为 3。¶

I1 执行全局读端口仲裁。
仲裁政策按照 ROB 年龄相对于 ROB 头数的顺序排列。
未能赢得仲裁会取消正在进行的尝试而不取消分配 IQ 条目。
写入端口不得竞争。
每个 IQ 选择器/发出端口对应一个管道和一个专用 RF 写入端口。
STD 有读端口，但没有写端口。

加载推测唤醒、转发和未命中处理¶

负载在 LD_E1 处产生推测性唤醒。
仅在 LD_E4 加载返回数据。
仅通过负载规范唤醒准备就绪的消费者：
不得请求 I1 中该源的 RF 读取端口，
必须使用旁路网络通过E4 -> consumer-I2转发获取数据。
ld_gen_vec 是一个位集，而不是 onehot，代表加载管道阶段 E1 至 E4。
ld_gen_vec 必须沿着依赖链传播。
加载管道运动通过位移位推进 ld_gen_vec。
LSU 提供源自 E4 漏检的 miss_pending。
当miss_pending == 1时，发布队列必须抑制拾取条目，其源依赖仍然带有LD_E4。
顶级配置挂钩稍后可能会将未命中可见性扩展到 E5，但是默认合约为上面的E4方案。

T/U点对点唤醒- `P` 唤醒通过物理标签全局广播。¶

T 和 U 唤醒是点对点的 qtag = (phys_issq_id, entry_id)。
phys_issq_id 是通过 JIT 规范模板派生的物理 IQ 枚举。
entry_id 宽度是根据 IQ 导出的，并打包为统一的最大宽度 qtag 线。

区块和恢复合约（LC-MA-BLK-001）¶

块结构控制流是强制性的。
BSTART 和 BSTOP 语义对于架构重定向具有权威性和退休行为。
架构重定向是边界权威的。执行端 setc.cond 记录修正元数据但不直接重写架构电脑。
BSTART 在块头打开一个块。
BSTART 遇到 - 块体终止前一个块，并可能在以下位置重新启动与下一个块头相同的 PC。
RET、IND 和 ICALL 需要在同一块中显式 SETC.TGT。
BSTART.CALL 不会隐式写入 ra。寄件人地址已更新仅来自显式 SETRET 或 C.SETRET。
FENTRY、FEXIT、FRET.RA 和 FRET.STK 是有效的独立宏块边界并在提交的块元数据中保持可见。
恢复目标必须解析为合法的区块启动。非集体目标提高正是TRAP_BRU_RECOVERY_NOT_BSTART (0x0000B001)。

边界权威重定向- BRU 侧条件评估可能会及早发现不匹配，但是¶

架构重定向仍然是边界消耗的操作。 - 边界提交是架构重定向选择的唯一权威。 - 执行端更正元数据不得绕过 ROB 排序。

宏观边界规则¶

FENTRY、FEXIT、FRET.RA 和 FRET.STK 是架构边界形式，而不是仅跟踪的实施设备。
模板扩展必须保留架构顺序、块可见性、和返回目标的合法性。

详细的恢复行为记录在：

rtl/LinxCore/docs/architecture/branch_recovery_rules.md
rtl/LinxCore/docs/architecture/linxisa_block_control_flow.md

BID 和 BROB 合约¶

BID 由 BROB 生成并保持 64 位。
默认 BID 编码为 BID = (uniq << 7) | slot_id， slot_id = BID[6:0]为默认128条。
对于 PE 响应路由，cmd_tag 必须等于 bid[7:0]。
块完成是 scalar_done && (needs_engine ? engine_done : 1)。
scalar_done 在 BSTART 退休和 BSTOP 退休时触发。
刷新和重定向行为在每个 BID 承载队列中都是基于 BID 的：保留bid <= flush_bid，杀死bid > flush_bid。
BROB、BISQ 和每个块承载路径必须保留全角 BID 跨槽排序。

架构块完成抽象- 对于块完成语义，灵犀Core 遵循 ISA 可见规范¶

编译块族域 {STD, FP, SYS, MPAR, MSEQ, VPAR, VSEQ, TLSU, CUBE, TEPL, FIXP}。 TEPL 是唯一解码载体；其 Mode/Function 再决定语义引擎 VEC 或 SFU。 - STD、FP 和 SYS 在两层完成模型中等效。 - 动态块实例完全崩溃为三种架构之一参与者集： - {} 用于空/仅控制标量系列实例， - {scalar} 适用于标量系列实例，具有真正的标量块体， - {non-scalar} 适用于规范的非标量块类型。 - 仅标量/控制系列块允许动态退化为 {} 类型。 - 规范的非标量块类型始终带有 {non-scalar} 完成义务。 - 架构{non-scalar}参与者具有单点解析语义：BROB 和退休观察每个 non-scalar-done 事件块实例。

区块生命周期规则¶

BSTART携带新块的新BID。
BSTOP 仅当活动块不再被发动机阻挡时才退出完成。
只有最古老的符合架构要求的区块才可以退役。
较新的引擎支持的工作必须在正常重定向下保持可取消状态，并且冲洗规则。

详细的 BROB 和块结构行为仍然记录在：

rtl/LinxCore/docs/architecture/stages/BROB.md
rtl/LinxCore/docs/architecture/block_fabric_contract.md

特权/陷阱合约 (LC-MA-PRV-001)- U->S 陷阱条目和 `SRET` 返回必须保留架构控制和状态¶

过渡。 - 陷阱包络和 CSR 可见的副作用必须保持一致提交可见的行为。 - super标量退役时需要精确的异常报告。

MMU合约（LC-MA-MMU-001）¶

翻译成功和失败必须产生确定性陷阱包络。
MMU 行为必须与 v0.58.1 特权合约措辞保持一致。
MMU 故障路径必须保持精确的退役和恢复顺序。

中断合约 (LC-MA-IRQ-001)¶

定时器中断传送必须在严格系统通道中保持启用状态。
中断进入和返回必须与块边界和重放或冲洗行为。
中断处理必须在持续混合的情况下保持前进的进展工作压力。

中断不得在提交可见和外部创建隐藏状态转换陷阱可见的建筑行为。

内存订购合约 (LC-MA-MEM-001)¶

加载/存储排序、转发和重放行为必须保留建筑上合法。
提交时的内存可见性必须与记录的跟踪保持一致内存元数据。
Dispatch 为每个内存 uop 和 LSU 问题分配单调 load_store_id 仍按 lsid_issue_ptr 订购。
承诺存储通过承诺存储消耗路径保持解耦；较年轻的推测内存状态在提交之前仍然必须是可刷新的。
排序检查必须包括阻止和重定向交互。

路易斯安那州立大学规则- 实时合约是单 LSU 宽度的机器。¶

LSU 发行仍由 load_store_id 订购。
负载转发、重放和存储消耗行为必须保持精确尊重承诺状态。
MMIO 提交可见行为必须保持架构明确。

详细的排序行为记录在：

rtl/LinxCore/docs/architecture/lsid_memory_ordering.md

发动机集成合同（LC-MA-ENG-001）¶

引擎支持的执行必须通过以下方式保持架构可见降低了块流。
发动机的完工必须与精确的退役和现有的块引擎完成模型。
引擎本地工作不得在外部产生隐藏的全局内存副作用架构上可见的内存操作和提交的块边界。
面向 Tile 的 TEPL 操作必须保留 Mode/Function 载体身份，并由当前 catalog 明确路由到 VEC 或 SFU。

工作负载-引擎组成¶

VEC 仍然是通用可编程 SIMT 计算引擎。
TLSU 通过与灵犀 Core 相同的块/BID 合约集成到灵犀 Core 机器的其余部分，但其南向内存流量归 CSU 所有子系统并以 CSU L2 和前端填充流量为目标。
CUBE、VEC 和 SFU 通过相同的块/BID 合约集成； TEPL 本身不是执行引擎。
引擎问题、完成、异常和刷新行为必须保持可见通过规范接口来 ROB、BROB 和跟踪机器。

远期合约 (LC-MA-FWD-001)- 分支、刷新、加载未命中、重放和中断交互不得¶

僵局。 - 所需的关闭门必须包括明确的前进证据通道。

合同证据映射¶

本文档中每个合约 ID 的门映射定义如下：

rtl/LinxCore/docs/architecture/verification-matrix.md