07 DeviceSpec¶
目的¶
本章定义 DeviceSpec 模型。
角色¶
DeviceSpec 是规范性的设备声明 sidecar。它描述后端能力与执行相关结构，同时避免把 canonical 模型坍缩成厂商专有实现细节。
参考 Word 草案中，devicespec.json 被定义为表达设备类别、拓扑、逻辑通道、原生操作、时钟信息与资源约束的工件。本仓库继续保留这一角色。
设备标识与平台类型¶
一个符合要求的 DeviceSpec 应足够清楚地标识目标设备或后端家族，以支撑验证、规划与诊断。至少应包括：
- 设备标识
- 平台类型
- 在有帮助时提供可选厂商或实现标签
平台类型之所以关键，是因为它为超导、离子阱、中性原子、自旋、光子等不同技术路线提供统一的能力解释锚点。
必需内容¶
一个符合要求的 DeviceSpec 应描述：
- backend family 或 platform type
- 寻址模型与拓扑
- 可用通道或逻辑控制资源
- 原生操作能力
- 时序属性与排程约束
- 在必要时提供读出与校准相关元数据
参考草案还隐含了以下结构分组：
- 以节点与边或等效地址图表示的拓扑信息
- 逻辑通道与载波分类
- 原生操作能力声明
- 时钟与时序信息
- 显式约束与并发限制
通道与逻辑控制资源¶
DeviceSpec 中的通道层应描述逻辑控制资源，而不是假设所有平台都暴露相同的物理接口。
代表性的通道相关信息包括：
- 通道标识符
microwave、rf、optical、dc、virtual、readout等载波类型- 可选的频率范围
- 可选的时间分辨率
- 互斥或占用行为
- 用于调度或诊断的资源标签
这种表示方式的目标，是支持跨技术路线的执行规划，而不是把所有平台压平成一种载波模型。
原生操作与时序¶
DeviceSpec 还应描述目标设备或后端原生支持哪些操作。代表性字段包括：
- 操作名称
- 目标元数或目标数量
- 在必要时关联载波类型
- 在必要时提供实现提示
时序相关内容应以验证器与调度器可消费的方式描述后端的时间边界。常见信息包括：
- 最小时隙或最小时间粒度
- 可选的全局时钟信息
- 是否支持绝对时序
- 是否支持相对时序
约束与读出上下文¶
参考草案明确把约束信息视为执行相关内容，而不是说明性点缀。因此，DeviceSpec 可以包含如下约束：
- 耦合器冲突
- blockade 半径限制
- 共享 motional mode 或 beam 资源
- 读出复用限制
- 互斥区域或资源锁
读出与校准相关字段也可以在 DeviceSpec 中出现，但其角色应保持声明性，而不能替代 CalSet。
平台多样性示例¶
典型平台族群包括：
- superconducting
- ion trap
- neutral atom
- spin
- photonic
该模型必须能够覆盖这些平台，而不能假设 microwave、optical、RF 或 imaging 语义天然通用。
规范性规则¶
DeviceSpec 不只是说明性文档，而是验证器、执行计划器、排程器、lowering 逻辑与 backend driver 会消费的规范性执行声明。
因此，它应当足够稳定，以支持：
- 合法性检查
- 调度决策
- 在适用场景下的路由或放置提示
- 面向能力边界的导出与 lowering
- 可复现的 Bundle 解释
边界规则¶
DeviceSpec 应描述能力与约束边界，而不是穷举所有 vendor-private 实现细节。厂商专有的落地实现仍属于 backend 模块和 driver-specific 编译逻辑。
这一边界对整体架构至关重要：UQCI 保持 canonical，DeviceSpec 保持声明性，backend-native 落地始终位于二者下游。