简介SpyGlass LintRules Reference GuideQ-2020.03-SP1版是Synopsys官方发布的静态分析规则参考手册面向从事IC设计验证的工程师、Verilog/VHDL开发者及验证流程搭建人员用于在设计早期定位语法错误、编码规范偏离、时序与功耗隐患等问题。文档系统收录了SpyGlass lint产品的全部规则集每条规则均给出规则ID、功能描述、示例代码、修改方案与严重性等级并说明allow_clk_in_condition、allviol、avoid_seq_logic等参数配置方式读者可据此自定义规则集、调整阈值与例外将检查流程贴合项目规范。资源为单个PDF文件压缩包约2.04MB结构按前言、规则参数、规则条目依次展开便于按模块检索查阅。目前已有4460人学习下载适合需要深入理解lint规则语义、完善设计约束与接口检查的工程师作为案头工具书使用。1. SpyGlass Lint Rules Reference 到底在解决什么问题如果你写过 RTL大概率经历过这种场景综合能过、仿真能跑结果一到 SpyGlass 就刷出几百条 Lint 告警团队里没人说得清哪条该修、哪条能 waive。SpyGlass_LintRules_Reference.pdf这类文档本质就是把这堆告警背后的规则逐条讲清楚——它规定了每条 Lint Rule 检查什么、为什么这么检查、触发条件是什么、怎么改才合规。它面向的是做数字前端设计、SoC 集成、签核sign-off流程的工程师尤其是要建 Lint 基线、定 waive 策略、把规则接进 CI 的那批人。这篇笔记不逐条翻译手册而是讲清楚怎么把这份规则参考用成一套可落地的 Lint 治理方案从规则分类、参数配置到跑通最小流程、排掉高频误报最后落到怎么定自己的规则子集。2. 先搞懂 Lint 规则的分层为什么不能一把梭全开2.1 规则按检查对象分成哪几类SpyGlass Lint 的规则不是平铺的一堆编号它按检查对象和意图分层。常见做法是把它归成几大族结构类structural、语义类semantic、可综合性类synthesizability、可测性类DFT、时钟与复位类clock/reset、命名与风格类naming/style。结构类查的是模块端口、例化、位宽匹配这类硬伤语义类查的是组合环、锁存器推断、多驱动可综合性类专门盯那些仿真能过但综合工具不认的写法DFT 类查扫描链、时钟门控的可测性时钟复位类查跨时钟域、复位同步命名风格类基本是团队规范跟功能无关。分层的意义在于不同族的规则严重级别和修复成本差得很远。结构类和语义类里的组合环、多驱动基本是必须清零的命名风格类可以整族降级或 waive。我一般会先按族把规则过一遍而不是从第一条编号顺序往下读否则很容易在风格规则上耗掉半天真正的硬伤反而漏了。2.2 严重级别和 waive 策略怎么定每条规则在参考里都会标注默认严重级别通常是 Error / Warning / Info 三档。但默认级别不等于你项目里的级别。落地时要做的是「重定级」把跟功能正确性强相关的规则提到 Error把纯风格类降到 Info 甚至关掉。一个可操作的定级原则是这样会导致综合结果与仿真不一致的一律 Error会导致后端实现困难的比如超大扇出、隐式锁存至少 Warning只影响可读性的Info。waive 不是删规则而是带理由、带责任人、带过期时间的豁免。参考文档里通常会给每条规则的 waive 语法关键是别用全局 waive 把整条规则关死而是按模块、按实例精确豁免。提示waive 一定要留痕。我见过项目把 waive 写在脚本里没注释半年后没人知道为什么豁免回归时全被当成新问题重新查一遍。2.3 规则编号和文档结构的对应关系参考手册一般按规则族分章每条规则有固定字段规则名、所属族、默认级别、检查描述、触发示例、修复建议、相关参数。读的时候不要只读「检查描述」真正决定你踩不踩坑的是「触发示例」和「相关参数」——示例告诉你什么写法会触发参数告诉你这条规则的灵敏度能不能调。我习惯先建一张表把项目要用的规则名、族、目标级别、是否可参数化列出来再对着手册逐条填。这张表后面直接变成 Lint 配置文件的输入比边跑边改高效得多。字段作用落地时怎么用规则名唯一标识写进配置文件的目标所属族决定处理优先级按族批量定级默认级别参考起点重定级为项目级别触发示例判断误报对照自己的代码风格相关参数调灵敏度决定是否参数化3. 把规则接进流程从配置文件到最小可跑命令3.1 规则配置文件怎么写SpyGlass 的规则控制通常落在一个项目配置文件里按族或按规则名设置级别和参数。下面是一个结构化的示例展示怎么把「重定级 参数化 精确 waive」三件事写在一起。注意规则名和参数名要对着你手上的参考手册填不同版本命名可能有差异。# lint_setup.tcl —— SpyGlass Lint 规则控制示例 # 1) 按族重定级结构类提到 Error set_rule_severity -rule_group structural -severity Error # 2) 单条规则参数化调整位宽检查的容忍度 set_rule_parameter -rule WIDTH_MISMATCH -param tolerance -value 0 # 3) 精确 waive只豁免某个模块的命名规则带理由 set_rule_waiver -rule NAMING_STYLE \ -module u_legacy_wrapper \ -reason third_party_ip_frozen \ -owner frontend_lead # 4) 关闭纯风格类整族确认团队规范后 set_rule_severity -rule_group naming_style -severity Info逻辑说明第一步按族批量定级避免逐条改第二步只对关键规则调参数tolerance设 0 表示位宽必须严格匹配第三步的 waive 带了模块、理由、责任人三个字段方便审计第四步把风格类降级而不是删除保留可见性。参数说明-rule_group接受族名-rule接受单条规则名-severity接受 Error/Warning/Info-param和-value成对出现。实际字段名以你项目所用版本的参考手册为准这里给的是结构范式。3.2 跑通一次最小 Lint 流程配置写好后最小流程是「读设计 → 应用规则 → 出报告」。命令行大致长这样# 最小 Lint 运行单模块指定规则配置输出报告 spyglass -project lint_project.prj \ -goal lint/lint_rtl \ -batch \ -rules lint_setup.tcl \ -report ./reports/lint_report.rpt逻辑说明-project指向项目文件里面定义了源文件列表和顶层-goal选 Lint 目标lint/lint_rtl是常见的 RTL Lint 目标-batch表示非交互批处理适合接 CI-rules挂上刚才的规则配置-report指定报告输出路径。参数说明-goal的具体名字取决于你安装的规则集跑之前先用工具列出可用 goal-batch模式下不会弹 GUI出错信息直接进日志所以第一次跑建议先不加-batch用 GUI 看一遍规则加载有没有报错。跑完先别急着看告警数量先确认三件事规则配置有没有加载成功、源文件有没有全部读进去、顶层有没有选对。这三件事任何一件出问题报告里的数字都是假的。3.3 报告怎么读才不浪费时间报告出来通常是按规则分组的告警列表。高效读法是先按严重级别排序再看每条的「触发位置」和「规则名」最后才看描述。因为描述是通用的触发位置才是你的代码。我一般会做一次「告警聚类」把同一规则、同一模块的告警归到一起。如果一条规则在同一个模块里触发几十次大概率是模块级的设计习惯问题改一处模式就能消掉一片如果一条规则散落在几十个模块各触发一次那可能是规则本身跟团队风格冲突该考虑参数化或降级。这个判断直接决定你是去改代码还是去改配置。4. 高频误报和真实硬伤怎么区分4.1 组合环告警真环还是工具误判组合环combinational loop是 Lint 里最容易被误报也最不能放过的。真环会导致仿真和综合行为不一致必须修。但工具有时会把「带条件的三态逻辑」或「跨模块反馈」误判成环。区分方法看告警给的环路径手动追一遍信号。如果路径里经过了一个由使能信号控制的门控单元且使能本身不依赖环内信号那多半是误判可以用精确 waive 处理如果路径是纯组合反馈、没有任何时序打断那就是真环必须插寄存器或改逻辑。别偷懒直接全局 waive 组合环规则这是血泪经验——真环漏到后端时序和功能都会翻车。4.2 位宽不匹配什么时候可以容忍位宽不匹配告警分两种一种是隐式截断赋值左边比右边窄一种是隐式扩展左边比右边宽。扩展通常无害截断才是危险信号。参考手册里一般会区分这两类落地时可以把扩展类降级、截断类保持 Error。但有个例外如果截断发生在明确的掩码操作里比如assign a b[7:0];而b是 16 位且你就是要低 8 位这是有意为之。这种情况用参数把该规则的容忍度调一下或者在该行加行内 waive比全局降级更精确。4.3 锁存器推断为什么仿真过了综合才报隐式锁存器是典型的「仿真能过、综合报警」。原因是仿真里 if 没有 else 时信号保持原值行为上像锁存器综合工具则会真的推断出一个锁存器带来时序和 DFT 问题。Lint 在这里的价值就是提前抓出来。修法有两种补全 else 分支或者把信号声明成时序逻辑。选哪种取决于设计意图——如果这个信号本来就该保持那就用寄存器明确表达如果是漏写了 else那就补上。别用「加默认赋值」糊弄那只是把锁存器藏起来逻辑意图还是不清。4.4 跨时钟域告警Lint 能查到什么程度Lint 对跨时钟域的检查是有限的它能查到位宽不匹配、缺少同步器这类结构问题但查不了同步器本身的正确性比如两级触发器够不够、握手协议对不对。所以看到 CDC 相关告警要清楚它只是第一道筛子。我的做法是Lint 的 CDC 告警全部当 Warning 处理逐条确认有没有同步结构真正的 CDC 签核交给专门的 CDC 工具。别指望 Lint 把 CDC 全包了那是另一个工具族的活。5. 避坑与排查五条踩过的坑5.1 坑一全局 waive 把规则关死现象回归时某条规则再也不报但代码里明明有违规写法。原因早期为了快速清零用了全局 waive 把整条规则关掉后来没人记得。解决waive 必须带模块、理由、责任人、过期时间并且定期审计 waive 列表过期的自动失效。5.2 坑二规则配置没加载成功却以为跑了现象报告里告警数量异常少看着很干净。原因-rules指向的配置文件路径写错或者语法错误被工具静默跳过。解决跑完先看日志里规则加载那几行确认配置生效第一次跑用 GUI 模式配置错误会直接报出来。5.3 坑三源文件列表漏了 include现象某些模块的告警完全不出现。原因项目文件里的源文件列表没包含被 include 的头文件或子模块工具没读到。解决跑之前用工具的文件列表功能核对一遍确认顶层和所有依赖都在漏文件比漏告警更危险。5.4 坑四把风格规则当硬伤修现象团队花大量时间改命名和缩进真正的组合环没人管。原因没做规则分层按编号顺序处理。解决先按族定级风格类整族降级或关掉把精力集中在结构、语义、可综合性三族上。5.5 坑五参数调过头导致漏报现象调了某条规则的容忍度后真实违规也不报了。原因参数放宽是为了消误报但放宽幅度太大把真问题一起放过。解决参数调整要小步走每次只调一档调完用一组已知违规的测试用例验证规则还抓得住。6. 把规则参考变成自己的 Lint 基线6.1 从参考手册到项目规则子集参考手册是全集项目要的是子集。做法是先按族定级再按项目阶段裁剪。早期开发阶段可以只开结构、语义、可综合性三族的 Error 级规则让开发者先清硬伤临近签核再把 DFT、CDC 相关规则打开。这样不会一上来就被几百条告警淹没。裁剪的依据不是「哪条烦就关哪条」而是「这条规则对应的问题在这个阶段会不会造成返工」。会造成返工的留着不会的先降级。6.2 用回归验证规则基线有没有退化规则基线定好后要防止它悄悄退化。做法是每次改配置都跑一次回归拿一组已知违规的测试模块确认该报的还报、该 waive 的还 waive。下面是个简单的回归检查脚本骨架#!/bin/bash # lint_regression.sh —— 规则基线回归检查 # 对已知违规用例跑 Lint比对期望告警数 EXPECTED_ERRORS12 spyglass -project lint_project.prj -goal lint/lint_rtl -batch \ -rules lint_setup.tcl -report ./reports/regression.rpt # 从报告里提取 Error 级告警数 ACTUAL$(grep -c Severity: Error ./reports/regression.rpt) if [ $ACTUAL -ne $EXPECTED_ERRORS ]; then echo 规则基线退化期望 $EXPECTED_ERRORS实际 $ACTUAL exit 1 fi echo 规则基线正常逻辑说明脚本对固定测试用例跑 Lint提取 Error 级告警数跟期望值比对不一致就报错退出适合接进 CI。参数说明EXPECTED_ERRORS要随测试用例更新而维护grep的匹配串要对着你报告的实际格式调不同版本报告字段可能不同。这个脚本的价值在于任何一次配置改动只要导致告警数变化CI 立刻拦住避免基线被悄悄改坏。6.3 一个具体技巧按模块打标签做差异化规则大项目里不同模块的质量要求不一样第三方 IP 和自研核心不能用同一套规则。技巧是给模块打标签规则配置里按标签差异化。比如自研模块开全量规则第三方 IP 只开结构类硬伤规则。这样既保证核心质量又不会在不可改的 IP 上浪费精力。实现上可以在项目文件里给模块加属性规则配置里用条件判断读取属性。具体语法看工具支持思路是「规则跟着模块标签走而不是一刀切」。我自己的习惯是每次项目收尾把这一版实际用的规则子集和 waive 列表单独存档下一个项目直接拿来当起点比每次从手册全集重新裁快得多。规则参考手册是死的基线是活的活的那份才是真正值钱的东西。希望帮到你。本文还有配套的精品资源点击获取
简介SpyGlass LintRules Reference GuideQ-2020.03-SP1版是Synopsys官方发布的静态分析规则参考手册面向从事IC设计验证的工程师、Verilog/VHDL开发者及验证流程搭建人员用于在设计早期定位语法错误、编码规范偏离、时序与功耗隐患等问题。文档系统收录了SpyGlass lint产品的全部规则集每条规则均给出规则ID、功能描述、示例代码、修改方案与严重性等级并说明allow_clk_in_condition、allviol、avoid_seq_logic等参数配置方式读者可据此自定义规则集、调整阈值与例外将检查流程贴合项目规范。资源为单个PDF文件压缩包约2.04MB结构按前言、规则参数、规则条目依次展开便于按模块检索查阅。目前已有4460人学习下载适合需要深入理解lint规则语义、完善设计约束与接口检查的工程师作为案头工具书使用。1. SpyGlass Lint Rules Reference 到底在解决什么问题如果你写过 RTL大概率经历过这种场景综合能过、仿真能跑结果一到 SpyGlass 就刷出几百条 Lint 告警团队里没人说得清哪条该修、哪条能 waive。SpyGlass_LintRules_Reference.pdf这类文档本质就是把这堆告警背后的规则逐条讲清楚——它规定了每条 Lint Rule 检查什么、为什么这么检查、触发条件是什么、怎么改才合规。它面向的是做数字前端设计、SoC 集成、签核sign-off流程的工程师尤其是要建 Lint 基线、定 waive 策略、把规则接进 CI 的那批人。这篇笔记不逐条翻译手册而是讲清楚怎么把这份规则参考用成一套可落地的 Lint 治理方案从规则分类、参数配置到跑通最小流程、排掉高频误报最后落到怎么定自己的规则子集。2. 先搞懂 Lint 规则的分层为什么不能一把梭全开2.1 规则按检查对象分成哪几类SpyGlass Lint 的规则不是平铺的一堆编号它按检查对象和意图分层。常见做法是把它归成几大族结构类structural、语义类semantic、可综合性类synthesizability、可测性类DFT、时钟与复位类clock/reset、命名与风格类naming/style。结构类查的是模块端口、例化、位宽匹配这类硬伤语义类查的是组合环、锁存器推断、多驱动可综合性类专门盯那些仿真能过但综合工具不认的写法DFT 类查扫描链、时钟门控的可测性时钟复位类查跨时钟域、复位同步命名风格类基本是团队规范跟功能无关。分层的意义在于不同族的规则严重级别和修复成本差得很远。结构类和语义类里的组合环、多驱动基本是必须清零的命名风格类可以整族降级或 waive。我一般会先按族把规则过一遍而不是从第一条编号顺序往下读否则很容易在风格规则上耗掉半天真正的硬伤反而漏了。2.2 严重级别和 waive 策略怎么定每条规则在参考里都会标注默认严重级别通常是 Error / Warning / Info 三档。但默认级别不等于你项目里的级别。落地时要做的是「重定级」把跟功能正确性强相关的规则提到 Error把纯风格类降到 Info 甚至关掉。一个可操作的定级原则是这样会导致综合结果与仿真不一致的一律 Error会导致后端实现困难的比如超大扇出、隐式锁存至少 Warning只影响可读性的Info。waive 不是删规则而是带理由、带责任人、带过期时间的豁免。参考文档里通常会给每条规则的 waive 语法关键是别用全局 waive 把整条规则关死而是按模块、按实例精确豁免。提示waive 一定要留痕。我见过项目把 waive 写在脚本里没注释半年后没人知道为什么豁免回归时全被当成新问题重新查一遍。2.3 规则编号和文档结构的对应关系参考手册一般按规则族分章每条规则有固定字段规则名、所属族、默认级别、检查描述、触发示例、修复建议、相关参数。读的时候不要只读「检查描述」真正决定你踩不踩坑的是「触发示例」和「相关参数」——示例告诉你什么写法会触发参数告诉你这条规则的灵敏度能不能调。我习惯先建一张表把项目要用的规则名、族、目标级别、是否可参数化列出来再对着手册逐条填。这张表后面直接变成 Lint 配置文件的输入比边跑边改高效得多。字段作用落地时怎么用规则名唯一标识写进配置文件的目标所属族决定处理优先级按族批量定级默认级别参考起点重定级为项目级别触发示例判断误报对照自己的代码风格相关参数调灵敏度决定是否参数化3. 把规则接进流程从配置文件到最小可跑命令3.1 规则配置文件怎么写SpyGlass 的规则控制通常落在一个项目配置文件里按族或按规则名设置级别和参数。下面是一个结构化的示例展示怎么把「重定级 参数化 精确 waive」三件事写在一起。注意规则名和参数名要对着你手上的参考手册填不同版本命名可能有差异。# lint_setup.tcl —— SpyGlass Lint 规则控制示例 # 1) 按族重定级结构类提到 Error set_rule_severity -rule_group structural -severity Error # 2) 单条规则参数化调整位宽检查的容忍度 set_rule_parameter -rule WIDTH_MISMATCH -param tolerance -value 0 # 3) 精确 waive只豁免某个模块的命名规则带理由 set_rule_waiver -rule NAMING_STYLE \ -module u_legacy_wrapper \ -reason third_party_ip_frozen \ -owner frontend_lead # 4) 关闭纯风格类整族确认团队规范后 set_rule_severity -rule_group naming_style -severity Info逻辑说明第一步按族批量定级避免逐条改第二步只对关键规则调参数tolerance设 0 表示位宽必须严格匹配第三步的 waive 带了模块、理由、责任人三个字段方便审计第四步把风格类降级而不是删除保留可见性。参数说明-rule_group接受族名-rule接受单条规则名-severity接受 Error/Warning/Info-param和-value成对出现。实际字段名以你项目所用版本的参考手册为准这里给的是结构范式。3.2 跑通一次最小 Lint 流程配置写好后最小流程是「读设计 → 应用规则 → 出报告」。命令行大致长这样# 最小 Lint 运行单模块指定规则配置输出报告 spyglass -project lint_project.prj \ -goal lint/lint_rtl \ -batch \ -rules lint_setup.tcl \ -report ./reports/lint_report.rpt逻辑说明-project指向项目文件里面定义了源文件列表和顶层-goal选 Lint 目标lint/lint_rtl是常见的 RTL Lint 目标-batch表示非交互批处理适合接 CI-rules挂上刚才的规则配置-report指定报告输出路径。参数说明-goal的具体名字取决于你安装的规则集跑之前先用工具列出可用 goal-batch模式下不会弹 GUI出错信息直接进日志所以第一次跑建议先不加-batch用 GUI 看一遍规则加载有没有报错。跑完先别急着看告警数量先确认三件事规则配置有没有加载成功、源文件有没有全部读进去、顶层有没有选对。这三件事任何一件出问题报告里的数字都是假的。3.3 报告怎么读才不浪费时间报告出来通常是按规则分组的告警列表。高效读法是先按严重级别排序再看每条的「触发位置」和「规则名」最后才看描述。因为描述是通用的触发位置才是你的代码。我一般会做一次「告警聚类」把同一规则、同一模块的告警归到一起。如果一条规则在同一个模块里触发几十次大概率是模块级的设计习惯问题改一处模式就能消掉一片如果一条规则散落在几十个模块各触发一次那可能是规则本身跟团队风格冲突该考虑参数化或降级。这个判断直接决定你是去改代码还是去改配置。4. 高频误报和真实硬伤怎么区分4.1 组合环告警真环还是工具误判组合环combinational loop是 Lint 里最容易被误报也最不能放过的。真环会导致仿真和综合行为不一致必须修。但工具有时会把「带条件的三态逻辑」或「跨模块反馈」误判成环。区分方法看告警给的环路径手动追一遍信号。如果路径里经过了一个由使能信号控制的门控单元且使能本身不依赖环内信号那多半是误判可以用精确 waive 处理如果路径是纯组合反馈、没有任何时序打断那就是真环必须插寄存器或改逻辑。别偷懒直接全局 waive 组合环规则这是血泪经验——真环漏到后端时序和功能都会翻车。4.2 位宽不匹配什么时候可以容忍位宽不匹配告警分两种一种是隐式截断赋值左边比右边窄一种是隐式扩展左边比右边宽。扩展通常无害截断才是危险信号。参考手册里一般会区分这两类落地时可以把扩展类降级、截断类保持 Error。但有个例外如果截断发生在明确的掩码操作里比如assign a b[7:0];而b是 16 位且你就是要低 8 位这是有意为之。这种情况用参数把该规则的容忍度调一下或者在该行加行内 waive比全局降级更精确。4.3 锁存器推断为什么仿真过了综合才报隐式锁存器是典型的「仿真能过、综合报警」。原因是仿真里 if 没有 else 时信号保持原值行为上像锁存器综合工具则会真的推断出一个锁存器带来时序和 DFT 问题。Lint 在这里的价值就是提前抓出来。修法有两种补全 else 分支或者把信号声明成时序逻辑。选哪种取决于设计意图——如果这个信号本来就该保持那就用寄存器明确表达如果是漏写了 else那就补上。别用「加默认赋值」糊弄那只是把锁存器藏起来逻辑意图还是不清。4.4 跨时钟域告警Lint 能查到什么程度Lint 对跨时钟域的检查是有限的它能查到位宽不匹配、缺少同步器这类结构问题但查不了同步器本身的正确性比如两级触发器够不够、握手协议对不对。所以看到 CDC 相关告警要清楚它只是第一道筛子。我的做法是Lint 的 CDC 告警全部当 Warning 处理逐条确认有没有同步结构真正的 CDC 签核交给专门的 CDC 工具。别指望 Lint 把 CDC 全包了那是另一个工具族的活。5. 避坑与排查五条踩过的坑5.1 坑一全局 waive 把规则关死现象回归时某条规则再也不报但代码里明明有违规写法。原因早期为了快速清零用了全局 waive 把整条规则关掉后来没人记得。解决waive 必须带模块、理由、责任人、过期时间并且定期审计 waive 列表过期的自动失效。5.2 坑二规则配置没加载成功却以为跑了现象报告里告警数量异常少看着很干净。原因-rules指向的配置文件路径写错或者语法错误被工具静默跳过。解决跑完先看日志里规则加载那几行确认配置生效第一次跑用 GUI 模式配置错误会直接报出来。5.3 坑三源文件列表漏了 include现象某些模块的告警完全不出现。原因项目文件里的源文件列表没包含被 include 的头文件或子模块工具没读到。解决跑之前用工具的文件列表功能核对一遍确认顶层和所有依赖都在漏文件比漏告警更危险。5.4 坑四把风格规则当硬伤修现象团队花大量时间改命名和缩进真正的组合环没人管。原因没做规则分层按编号顺序处理。解决先按族定级风格类整族降级或关掉把精力集中在结构、语义、可综合性三族上。5.5 坑五参数调过头导致漏报现象调了某条规则的容忍度后真实违规也不报了。原因参数放宽是为了消误报但放宽幅度太大把真问题一起放过。解决参数调整要小步走每次只调一档调完用一组已知违规的测试用例验证规则还抓得住。6. 把规则参考变成自己的 Lint 基线6.1 从参考手册到项目规则子集参考手册是全集项目要的是子集。做法是先按族定级再按项目阶段裁剪。早期开发阶段可以只开结构、语义、可综合性三族的 Error 级规则让开发者先清硬伤临近签核再把 DFT、CDC 相关规则打开。这样不会一上来就被几百条告警淹没。裁剪的依据不是「哪条烦就关哪条」而是「这条规则对应的问题在这个阶段会不会造成返工」。会造成返工的留着不会的先降级。6.2 用回归验证规则基线有没有退化规则基线定好后要防止它悄悄退化。做法是每次改配置都跑一次回归拿一组已知违规的测试模块确认该报的还报、该 waive 的还 waive。下面是个简单的回归检查脚本骨架#!/bin/bash # lint_regression.sh —— 规则基线回归检查 # 对已知违规用例跑 Lint比对期望告警数 EXPECTED_ERRORS12 spyglass -project lint_project.prj -goal lint/lint_rtl -batch \ -rules lint_setup.tcl -report ./reports/regression.rpt # 从报告里提取 Error 级告警数 ACTUAL$(grep -c Severity: Error ./reports/regression.rpt) if [ $ACTUAL -ne $EXPECTED_ERRORS ]; then echo 规则基线退化期望 $EXPECTED_ERRORS实际 $ACTUAL exit 1 fi echo 规则基线正常逻辑说明脚本对固定测试用例跑 Lint提取 Error 级告警数跟期望值比对不一致就报错退出适合接进 CI。参数说明EXPECTED_ERRORS要随测试用例更新而维护grep的匹配串要对着你报告的实际格式调不同版本报告字段可能不同。这个脚本的价值在于任何一次配置改动只要导致告警数变化CI 立刻拦住避免基线被悄悄改坏。6.3 一个具体技巧按模块打标签做差异化规则大项目里不同模块的质量要求不一样第三方 IP 和自研核心不能用同一套规则。技巧是给模块打标签规则配置里按标签差异化。比如自研模块开全量规则第三方 IP 只开结构类硬伤规则。这样既保证核心质量又不会在不可改的 IP 上浪费精力。实现上可以在项目文件里给模块加属性规则配置里用条件判断读取属性。具体语法看工具支持思路是「规则跟着模块标签走而不是一刀切」。我自己的习惯是每次项目收尾把这一版实际用的规则子集和 waive 列表单独存档下一个项目直接拿来当起点比每次从手册全集重新裁快得多。规则参考手册是死的基线是活的活的那份才是真正值钱的东西。希望帮到你。本文还有配套的精品资源点击获取
