灵犀Core v0.56 微架构合约¶
此发布的页面镜像了规范的 灵犀Core 源代码
rtl/ZXTERMEN45QXZCore/docs/architecture/microarchitecture.md。
基线 super标量 合约¶
灵犀Core 是 灵犀指令集 v0.56 的规范 super标量 乱序核心。
它精确地退出，无序执行，并保留块排序
跨 标量 和引擎支持工作的架构控制模型。
当前基线限制：
- 获取宽度：4
- 调度宽度：4
- 问题宽度：最多 4
- 提交宽度：最多 4
- 路易斯安那州立大学宽度：1
这些限制是实时 v0.56 闭合基线。更广泛的问题或多 LSU
扩展是一个后续轨道，而不是这里规范合同的一部分。
架构状态模型¶
灵犀Core 必须保留以下 架构状态 类：
- 标量，灵犀指令集
v0.56定义的控制和特权状态， - CSR、陷阱、MMU 和 中断-可见状态，
BSTART、BSTOP的块可见 架构状态 和 边界权威重定向，- 通过
block_uid和block_bid动态块标识， - 通过 ROB 精确退休命令，
- 通过微指令和块级元数据跟踪可见的动态身份。
实现私有预测器、队列、重放或调度状态可能存在， 但它绝不能创建第二台退役、恢复或阻塞的机器。
机器组织¶
灵犀Core 分为以下主要架构域：- 前端获取和指令传递，
- 解码、排序 ID 分配和重命名，
- 重命名后调度、发布和执行集群，
- LSU 和内存排序机器，
- ROB 和精确提交机制，
- 块控制机械（BISQ、BCTRL、BROB、BID 流量）、
- 通过块结构选择的集成引擎，
- 跟踪和可观察性生产者。
本文档的其余部分冻结了跨这些域的合同。
模块分解合约¶
灵犀Core 被指定为命名模块的层次结构。模块分解 是建筑合同的一部分，因为管道所有权、区块 所有权和跟踪所有权必须在 pyCircuit、RTL 中保持可检查性 生成、跟踪生产和启动工具。
阶段到模块规则¶
- 每个架构上可见的阶段令牌必须映射到专用模块 业主。
- 集成包装器可以组成阶段模块，但它们不能吸收 将状态阶段化为匿名胶水。
- 共享帮助程序文件可以提供类型、组合帮助程序或打包的帮助程序 元数据，但阶段本地状态必须保留在所属阶段模块中。
- 如果启动 shell 绕过阶段源，则替换源必须 仍然向下游解码、跟踪和提供相同的命名阶段边界 比较工具。
详细的结构目录规范如下：
rtl/ZXTERMEN45QXZCore/docs/architecture/module-catalog.mdrtl/ZXTERMEN45QXZCore/docs/architecture/pipeline-stage-catalog.md
管道合同（LC-MA-PIPE-001）- 阶段所有权必须在前端、解码、重命名、发布、¶
执行并提交；不允许隐藏的直通塌陷。
- 每个架构上可见的阶段必须保留为 pyCircuit 中的一个模块
层次结构，作为直接阶段模块或作为专用所有者模块
在后端家族内部。
- 提交行为必须保持精确并按架构退休排序。
- ROB 簿记必须在多个提交周期中保持一致。
- BSTART和BSTOP是D2解析的ROB可见边界微指令；他们做
不需要 IQ 或 FU 问题就能在架构上变得可见。
当前提升的关闭切片¶
当前推广阶段合约涵盖前端/解码路径、
重命名后调度路径，以及来自 F0 的基线问题/唤醒切片
通过W1：
F0、F1、F2、F3、IB、F4D1、D2、D3S1、S2、IQP1、I1、I2、E1、W1
除了提升的切片之外的后续执行/写回细节可以通过以下方式细化 未来的规范更新，但不得与以下规则相矛盾。
前端合约详细信息（F0 到 F4）¶
F0- F0 是专用的 PC 选择级。¶
F0接收多个候选 PC 并在控制逻辑下选择一台。F0 -> F1是已注册的管道边界。- 面向架构的
F0 -> F1接口是每个线程的，而不是一个 具有显式线程多路复用的单个共享端口。
F1¶
F1拥有 I-cache 查找和标记检查语义。F1确定命中或未命中，并在未命中时应用前端背压。- 架构模型保留每个线程未命中的独立性。
- 当前物理I-cache读取路径是单端口的，因此
F1仲裁 每个周期在线程和服务之间最多进行一次线程查找。 F1 -> F2是已注册的边界。
F2¶
F2从F1接收缓存读取数据以及线程和 PC 上下文。F2执行 ECC 检查并暂存原始缓存读取结果。- 当 ECC 错误时，
F2阻止正常传送到F3并报告获取端 错误而不是转发正常的带有标志的捆绑包形式。 F2不具备变长拼接或十字线组装功能。
F3- F3拥有可变长度指令汇编和每线程进位/缝合¶
缓冲。
- F3 执行静态预测。
- F3 必须至少识别 BSTART 和 BSTOP 并明确注释
块边界元数据。
- 主要边界元数据是语义 start_of_block 且
end_of_block，不是原始操作码标签残留。
- 模板指令（FENTRY、FEXIT、FRET.*）可能会被
CTU 不会强制同一提取包中的后续指令消失。
那些后面的指令可以保留在前端队列中，但它们不能
在该模板的 CTU 扩展子流之前输入 IB。
- 当 CTU 子流主动注入指令时，IB 写入端口
源选择是 CTU 优先级，普通 IFU 写入会等到
活动子流完成。
国际文凭¶
IB按线程分区；每个线程拥有一个独立的bank或FIFO。IB条目可以合法地跨越块边界。- 块元数据按指令携带，而不是作为每个条目一个摘要位。
- 每个存储的指令都携带其自己的长度元数据。
- PC 编码使用
entry_base_pc加上每条指令的偏移量和长度 而不是每条指令都有一个完全显式的 PC。 - 每个线程
IB存储体每个周期提供最多decodeWidth通道读取 因此D1可以组装一个解码宽度对齐的连续解码组。
F4- F4 每个周期提供 4 个时隙窗口。¶
- 每个插槽都是来自其自己的 PC 的连续 64 位视图。
- 解码严格按顺序消耗槽。
- 解码不得跨槽连接形成 48 位或 64 位 说明。
- 槽位消耗在第一个无效或被杀死的槽位处停止；没有插槽 允许压缩或跳过。
解码并重命名-uop 合约（D1 至 D3）¶
D1¶
D1从IB读取程序顺序连续解码组。D1执行指令解码并分配RID、BID和LSID。- 解码组的分配是全有或全无；如果整个小组不能 分配成功，管道停止并重试整个组。
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或S2IQ路由；它已经是 具体化到位于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选择就绪的非inflightIQ 条目并标记所选条目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/ZXTERMEN45QXZCore/docs/architecture/branch_recovery_rules.mdrtl/ZXTERMEN45QXZCore/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]。 - 块完成是
ZXTERMEN44QXZ_done && (needs_engine ? engine_done : 1)。 ZXTERMEN44QXZ_done在BSTART退休和BSTOP退休时触发。- 刷新和重定向行为在每个 BID 承载队列中都是基于 BID 的：
保留
bid <= flush_bid，杀死bid > flush_bid。 - BROB、BISQ 和每个块承载路径必须保留全角 BID 跨槽排序。
架构块完成抽象- 对于块完成语义，灵犀Core 遵循 ISA 可见规范¶
块型结构域{STD, FP, SYS, MPAR, MSEQ, VPAR, VSEQ, TMA, CUBE, TEPL}。
- STD、FP 和 SYS 在两层完成模型中等效。
- 动态块实例完全崩溃为三种架构之一
参与者集：
- {} 用于空/仅控制 标量 系列实例，
- {ZXTERMEN44QXZ} 适用于 标量 系列实例，具有真正的 标量 块体，
- {non-ZXTERMEN44QXZ} 适用于规范的非 标量 块类型。
- 仅 标量/控制系列块允许动态退化为 {}
类型。
- 规范的非 标量 块类型 始终带有 {non-ZXTERMEN44QXZ} 完成
义务。
- 架构{non-ZXTERMEN44QXZ}参与者具有单点解析
语义：BROB 和退休观察每个 non-ZXTERMEN44QXZ-done 事件
块实例。
区块生命周期规则¶
BSTART携带新块的新BID。BSTOP仅当活动块不再被发动机阻挡时才退出 完成。- 只有最古老的符合架构要求的区块才可以退役。
- 较新的引擎支持的工作必须在正常重定向下保持可取消状态，并且 冲洗规则。
详细的 BROB 和块结构行为仍然记录在：
rtl/ZXTERMEN45QXZCore/docs/architecture/stages/BROB.mdrtl/ZXTERMEN45QXZCore/docs/architecture/block_fabric_contract.md
特权/陷阱合约 (LC-MA-PRV-001)- U->S 陷阱条目和 SRET 返回必须保留架构控制和状态¶
过渡。 - 陷阱包络和 CSR 可见的副作用必须保持一致 提交可见的行为。 - super标量 退役时需要精确的 异常 报告。
MMU合约（LC-MA-MMU-001）¶
- 翻译成功和失败必须产生确定性陷阱包络。
- MMU 行为必须与
v0.56特权合同措辞保持一致。 - 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/ZXTERMEN45QXZCore/docs/architecture/lsid_memory_ordering.md
发动机集成合同（LC-MA-ENG-001）¶
- 引擎支持的执行必须通过以下方式保持架构可见 降低了块流。
- 发动机的完工必须与精确的退役和现有的 块引擎完成模型。
- 引擎本地工作不得在外部产生隐藏的全局内存副作用 架构上可见的内存操作和提交的块边界。
- 面向图块的引擎（例如
TAU）必须保留当前的图块到图块 除非未来的规范架构更新改变了该规则。
工作负载-引擎组成¶
VEC仍然是通用可编程 SIMT 计算引擎。TMA通过与 灵犀Core 相同的区块/BID 合约集成到 灵犀Core 机器的其余部分，但其南向内存流量归 CSU 所有 子系统并以 CSU L2 和前端填充流量为目标。CUBE和TAU继续通过相同的区块/BID 合约进行集成 作为对等引擎。- 引擎问题、完成、异常 和刷新行为必须保持可见 通过规范接口来 ROB、BROB 和跟踪机器。
远期合约 (LC-MA-FWD-001)- 分支、刷新、加载未命中、重放和 中断 交互不得¶
僵局。 - 所需的关闭门必须包括明确的前进证据通道。
合同证据映射¶
本文档中每个合约 ID 的门映射定义如下：
rtl/ZXTERMEN45QXZCore/docs/architecture/verification-matrix.md