3、SpyGlass基本概念：设计读取、规则库、目标（goal）、策略（policy）、报告（report）等核心术语

SpyGlass作为业界领先的早期设计检查（Early Design Check）平台，其核心价值在于将静态验证（Lint）、跨时钟域（CDC）检查、约束一致性检查、可测试性（DFT）分析等能力前置到RTL设计阶段。要真正掌握SpyGlass，首先必须理解其五大核心术语：设计读取（Design Read）、规则库（Rule Library）、目标（Goal）、策略（Policy）与报告（Report）。这五个概念构成了SpyGlass工具运行的完整闭环——从输入设计数据，到选择检查规则，再到配置检查流程，最终输出可操作的结果。本章将逐一拆解这些术语的底层逻辑、配置方法及实战中的常见误区，帮助读者建立对SpyGlass工作机理的系统认知。

上图展示了SpyGlass五大核心术语之间的逻辑关系与数据流向。设计读取是输入层，规则库是知识层，目标（Goal）是配置层，策略（Policy）是执行层，报告（Report）是输出层。整个流程并非单向线性，而是通过报告反馈驱动设计迭代或配置调整，形成闭环。下面我们将逐一深入剖析每个术语的内涵与实战用法。

3.1 设计读取（Design Read）——构建验证的“输入底盘”

核心原理

设计读取是SpyGlass一切检查的起点。它负责将用户的RTL代码（Verilog/VHDL/SystemVerilog）、网表（Netlist）、约束文件（SDC）、功耗意图文件（UPF/CPF）以及工艺库文件（.lib）解析为SpyGlass内部统一的数据库模型。这个模型不仅包含设计的层次结构、信号连接关系，还记录了每个模块的端口方向、位宽、时钟域归属等属性。SpyGlass的读取引擎支持混合语言设计，允许在同一个工程中同时读取Verilog和VHDL模块，并自动处理跨语言实例化问题。

操作流程与关键参数

在SpyGlass环境中，设计读取通常通过图形界面（GUI）的“Read Design”向导或命令行脚本完成。核心操作步骤如下：

1. 指定顶层模块：必须明确设计的Top Module名称，SpyGlass以此作为层次遍历的根节点。
2. 添加源文件：按依赖顺序列出所有RTL文件，支持通配符和文件列表（.f文件）。
3. 配置库文件：对于综合后的网表检查，需要指定目标工艺库；对于RTL检查，通常只需提供仿真库或空白库。
4. 加载约束：可选的SDC文件用于定义时钟、复位、输入输出延迟等，这些信息对CDC检查和约束一致性检查至关重要。
5. 执行elaboration：SpyGlass会进行语义分析、宏展开、参数传递，最终生成可被规则引擎遍历的层次化数据库。

案例拆解：混合语言设计的读取问题

某通信芯片项目包含约200万门逻辑，RTL由Verilog和SystemVerilog混合编写，其中还嵌入了两个VHDL模块。初始读取时，SpyGlass报错“Cannot find module: eth_mac_vhdl”。分析发现，VHDL文件的扩展名为.vhd，而SpyGlass默认不识别该扩展名。解决方案是在文件列表中添加-vhd选项，并显式指定VHDL库名称。修改后的读取命令如下：

read_file -type vhdl -lib work -vhd ./rtl/vhdl/eth_mac.vhd
read_file -type sverilog -lib work ./rtl/verilog/top.sv
read_file -type verilog -lib work ./rtl/verilog/ctrl.v
elaborate -top top_module

重新执行后，设计读取成功，层次树中正确显示了VHDL模块的端口和内部信号。此案例说明，设计读取阶段必须仔细核对文件类型、库映射和顶层指定，任何一环出错都会导致后续检查无法进行。

常见误区与复盘

• 误区一：忽略文件编译顺序。SpyGlass要求被实例化的模块先于上层模块读取，否则会报“Unknown module”错误。建议使用-f文件列表按依赖顺序排列。
• 误区二：不加载UPF文件。对于低功耗设计，若未读取UPF，SpyGlass将无法识别电源域和电平转换器，导致功耗相关规则失效。
• 误区三：顶层模块指定错误。若指定了非顶层模块，SpyGlass只会检查该模块及其以下层次，遗漏顶层互连逻辑。

3.2 规则库（Rule Library）——SpyGlass的“知识大脑”

核心原理

规则库是SpyGlass内置的检查规则集合，每条规则代表一种特定的设计检查项。规则库按类别组织，常见的包括：Lint规则（检查代码风格、未使用信号、位宽不匹配等）、CDC规则（检查跨时钟域同步、亚稳态处理、握手协议等）、约束规则（检查SDC约束的完整性、一致性）、DFT规则（检查扫描链连接、测试时钟等）。每条规则具有唯一的规则ID（如W528表示位宽不匹配）、严重级别（Error/Warning/Info）、适用语言（Verilog/VHDL）以及可配置的参数（如忽略某些特定模式）。

规则库的组织与查询

SpyGlass规则库采用分层结构：规则类别（Category）→ 规则子类（Subcategory）→ 具体规则（Rule）。用户可以通过goal命令查看规则列表，或使用GUI中的“Rule Browser”按类别浏览。下表列出了常用规则类别及其典型规则示例：

规则类别	典型规则ID	检查内容	默认严重级别
Lint / RTL	W528	信号位宽不匹配	Warning
Lint / RTL	W12	未使用的输入端口	Info
CDC	CDC_01	跨时钟域信号未同步	Error
CDC	CDC_15	握手信号缺少同步器	Error
Constraint	SDC_01	时钟定义缺失	Error
Constraint	SDC_12	输入延迟约束冲突	Warning
DFT	DFT_03	扫描时钟未定义	Error

规则库的定制与扩展

除了使用内置规则，SpyGlass允许用户通过Rule Development Kit（RDK）编写自定义规则，使用Tcl或C++语言实现特定的检查逻辑。例如，某团队需要检查所有跨时钟域信号是否都经过两级同步器，但内置规则无法识别其特定的同步器命名规范（如sync_2ff_前缀）。此时可编写自定义规则，通过模式匹配识别同步器实例，并验证其输出是否直接连接到目标寄存器。

常见误区与复盘

• 误区一：混淆规则ID与严重级别。规则ID是固定的，但严重级别可以在Goal中重新定义。例如，将W528从Warning提升为Error，以强制团队修复所有位宽不匹配。
• 误区二：忽略规则参数配置。许多规则支持参数调整，如set_rule_option -rule W528 -option max_width_diff -value 4，允许位宽差小于4时不报错。合理配置参数可减少误报。
• 误区三：依赖旧版本规则库。不同SpyGlass版本的规则库有差异，升级工具后必须重新验证规则行为，避免因规则变化导致检查结果不一致。

3.3 目标（Goal）——检查任务的“执行单元”

核心原理

目标是SpyGlass中一个命名的检查任务集合，它将一组规则、配置参数、严重级别和检查范围绑定在一起。一个Goal可以理解为“针对某个验证维度的一组检查指令”。例如，goal -name lint_rtl可能包含所有RTL Lint规则，并设置输出格式为文本；goal -name cdc_verify则包含CDC相关规则，并启用时钟域交叉分析引擎。Goal的定义使得用户可以将复杂的检查需求模块化，便于复用和团队协作。

Goal的创建与配置

创建Goal的典型流程如下：

1. 命名Goal：使用goal -create -name <goal_name>。
2. 添加规则：使用goal -add_rule -goal <goal_name> -rule <rule_id>，或通过-rule_category添加整个类别。
3. 设置严重级别：使用goal -set_severity -goal <goal_name> -rule <rule_id> -severity Error。
4. 配置规则参数：使用goal -set_rule_option调整特定规则的阈值或行为。
5. 指定检查范围：使用goal -set_scope -goal <goal_name> -scope {top.module1 top.module2}，限制只检查某些模块。

案例拆解：定制一个“复位检查”Goal

某汽车电子项目要求所有寄存器必须具有异步复位，且复位信号必须来自顶层复位管理单元。团队创建了自定义Goal：

goal -create -name reset_check
goal -add_rule -goal reset_check -rule W491   ;# 寄存器无复位
goal -add_rule -goal reset_check -rule W492   ;# 复位信号来源非法
goal -set_severity -goal reset_check -rule W491 -severity Error
goal -set_severity -goal reset_check -rule W492 -severity Error
goal -set_rule_option -goal reset_check -rule W491 -option ignore_scan -value true
goal -set_scope -goal reset_check -scope {top.chip_top}

执行该Goal后，报告显示共发现23处W491违规和5处W492违规。进一步分析发现，其中8处W491违规位于DFT扫描寄存器，由于设置了ignore_scan选项被自动忽略，最终需要修复的违规为15处。此案例展示了Goal的灵活配置能力，通过参数调整和范围限定，精确匹配项目特定需求。

常见误区与复盘

• 误区一：Goal中规则过多。一个Goal包含数百条规则会导致运行时间过长，且报告难以聚焦。建议按检查维度拆分Goal，如lint_rtl、lint_clock、cdc_struct等。
• 误区二：不设置检查范围。默认情况下Goal检查整个设计，对于大型设计会浪费大量时间。应通过-scope限定到本次修改涉及的模块。
• 误区三：忽略Goal之间的依赖。某些Goal需要先运行其他Goal生成的数据（如CDC约束文件）。在Policy中应正确编排顺序。

3.4 策略（Policy）——多Goal的“编排指挥”

核心原理

策略是多个Goal的有序集合，它定义了Goal的执行顺序、是否允许失败、以及Goal之间的数据传递关系。Policy使得用户可以将完整的验证流程封装为一个可重复执行的单元。例如，一个典型的Policy可能包含：先运行lint_rtl检查代码质量，再运行cdc_setup生成CDC约束，接着运行cdc_verify进行跨时钟域验证，最后运行constraint_check验证SDC一致性。Policy支持条件执行（如仅当某个Goal通过后才执行后续Goal）和并行执行（多个独立Goal同时运行以节省时间）。

Policy的构建与执行

构建Policy的步骤包括：

1. 创建Policy：policy -create -name <policy_name>。
2. 添加Goal：policy -add_goal -policy <policy_name> -goal <goal_name> -order 1。
3. 设置依赖关系：policy -set_dependency -policy <policy_name> -goal <goal_name> -depends_on <previous_goal>。
4. 配置失败策略：policy -set_on_fail -policy <policy_name> -goal <goal_name> -action stop（或continue）。
5. 执行Policy：policy -run -policy <policy_name>。

实战场景：回归验证中的Policy应用

在芯片每次代码提交后的回归验证中，团队使用以下Policy：

policy -create -name nightly_regression
policy -add_goal -policy nightly_regression -goal lint_rtl -order 1
policy -add_goal -policy nightly_regression -goal cdc_setup -order 2
policy -add_goal -policy nightly_regression -goal cdc_verify -order 3 -depends_on cdc_setup
policy -add_goal -policy nightly_regression -goal dft_checks -order 4
policy -set_on_fail -policy nightly_regression -goal lint_rtl -action stop
policy -set_on_fail -policy nightly_regression -goal cdc_verify -action stop
policy -run -policy nightly_regression

该Policy的执行逻辑是：先运行Lint检查，若发现Error级别违规则立即停止，避免后续CDC检查在质量较差的代码上浪费时间；CDC验证依赖CDC Setup生成的约束文件；DFT检查独立运行。通过Policy的编排，整个回归流程在2小时内完成，而手动逐个运行Goal需要3.5小时，效率提升约43%。

常见误区与复盘

• 误区一：Policy中Goal顺序不合理。例如，先运行CDC验证再运行Lint检查，可能导致CDC报告被大量代码风格问题干扰。
• 误区二：忽略Goal间的数据依赖。某些Goal会生成中间文件（如CDC约束），后续Goal需要读取这些文件。若未在Policy中正确排序，后续Goal会因找不到文件而失败。
• 误区三：Policy命名不清晰。建议使用具有业务含义的名称，如pre_synth_full_check、post_route_timing_drc，便于团队理解和维护。

3.5 报告（Report）——检查结果的“价值呈现”

核心原理

报告是SpyGlass将检查结果以结构化形式输出的载体。报告不仅列出违规（Violation）的位置、规则ID、严重级别，还提供上下文信息（如信号名、模块路径、RTL行号）以及修复建议。SpyGlass支持多种报告格式：文本（.rpt）、HTML（.html）、数据库（.db）以及可交互的GUI报告。报告的核心价值在于帮助工程师快速定位问题、理解根因、跟踪修复进度。

报告的关键字段与解读

一个典型的Violation条目包含以下字段：

字段	示例值	含义
Rule ID	W528	违规的规则标识
Severity	Warning	严重级别，影响是否阻断流程
File	./rtl/ctrl.v	违规所在的源文件
Line	45	违规在源文件中的行号
Hierarchy	top.chip_top.ctrl	违规模块的层次路径
Message	Width mismatch: A[7:0] vs B[3:0]	违规的具体描述
Source	A[7:0]	涉及的信号或表达式

报告的分析与处理流程

高效处理报告应遵循以下步骤：

1. 按严重级别过滤：首先关注所有Error级别的违规，这些必须修复；Warning级别的违规根据项目规范决定是否修复。
2. 按模块分组：将违规按层次路径分组，识别问题集中的模块，优先处理违规数量最多的模块。
3. 分析根因：使用SpyGlass GUI的“Source”视图跳转到RTL代码，结合Message信息判断是代码错误、约束缺失还是规则误报。
4. 分类处理：对于真正的设计缺陷，修改RTL或约束；对于误报，通过waiver机制添加豁免，并注明豁免原因。
5. 回归验证：修复后重新运行对应的Goal或Policy，确认违规数量下降且无新增违规。

案例拆解：从报告到修复的完整闭环

某AI芯片项目在运行cdc_verify Goal后，报告显示有12条CDC_01违规（跨时钟域信号未同步）。其中8条集中在axi_crossbar模块，4条在dma_ctrl模块。通过GUI查看源码，发现axi_crossbar中的违规信号是awready，从300MHz时钟域传递到150MHz时钟域，但未经过任何同步器。而dma_ctrl中的违规信号irq_pending虽然也跨时钟域，但实际已经通过一个双触发器同步器，只是SpyGlass未能识别该同步器结构（因为同步器实例名不包含“sync”关键字）。处理方案：对于axi_crossbar的8条违规，在目标时钟域添加两级同步器；对于dma_ctrl的4条违规，通过waiver豁免并添加注释说明同步器结构。修复后重新运行，违规数量降为0，且无新增违规。此案例说明，报告分析需要结合设计上下文，不能机械地认为所有违规都是真实缺陷。

常见误区与复盘

• 误区一：只看违规数量不看内容。数量下降不一定代表质量提升，可能只是通过waiver掩盖了问题。
• 误区二：忽略报告中的Info级别信息。Info级别的消息可能提示潜在风险，如未约束的时钟域，应定期审查。
• 误区三：报告格式单一。文本报告适合脚本解析，HTML报告适合人工浏览，数据库报告适合与其他工具集成。应根据使用场景选择合适的格式。