极客工场

Appearance

共 8,351 字预计阅读约 28 分钟

FPGA 原型验证专题 24：原型活动、覆盖率与性能调试闭环——翻转热点、瓶颈定位与 RTL 侧根因回放 ​

更新时间：2026-09-12。本文是「ASIC FPGA 原型验证系统」专题 06~25 深体系列分册，对应阶段 5~6 的分析闭环。采集见 22 Gate 域信号采集 ILA/trace/带宽深度权衡、回映见 23 Gate→RTL 数据回映 查表/聚合/SAIF、功耗签核见 25 真实激励驱动 ASIC 签核 SAIF 反标/边界。

这一篇在链路里的位置 ​

阶段 6 输出的 RTL 层次数据有两类用途：一类交 ASIC 团队做签核（阶段 7），另一类回到验证/设计团队改进设计与验证本身。本篇讲后者——原型相对仿真的独特价值是用真实速度跑超长软件场景，暴露仿真够不着的性能、并发、活锁/死锁、资源竞争问题。

本文要回答的问题 ​

  • 原型上能回收哪些覆盖率（代码/功能/断言/场景），与仿真如何互补而不重复？
  • 长软件场景（启动 OS、真实流量）会暴露哪些仿真难以发现的问题？
  • 如何用活动/翻转数据找热点模块、死代码、长期不活动的疑似异常区？
  • 性能调试：性能计数器、trace、时间剖片如何定位吞吐瓶颈/流水线气泡/仲裁饥饿？
  • 并发类问题（竞态、死锁、活锁、优先级反转）在原型速度下如何复现与抓现场？
  • 发现问题后如何用回映的 RTL 层次波形回放做根因定位，再改 RTL 回归？
  • 活动数据如何反哺下一轮：补插桩、调分区、改激励、补断言？

一、闭环总览：让「跑过」变成「改进」 ​

原型验证最常见的浪费是：板子跑了三天，只得到一堆「pass/fail」和无人再看的 trace。闭环的意义是把每次运行产出结构化反馈，驱动下一轮工程：

bash
真实负载上板（[21 激励注入与软硬协同 co-model/transactor](/fpga/prototyping/20-proto-stimulus-comodel.md)）
   → Gate 域采集（[22 Gate 域信号采集 ILA/trace/带宽深度权衡](/fpga/prototyping/21-proto-signal-capture-gate-domain.md)）
   → 回映成 RTL 层次数据（[23 Gate→RTL 数据回映 查表/聚合/SAIF](/fpga/prototyping/22-proto-postprocess-gate-to-rtl.md)）
   → 三条分析线：覆盖率 / 活动热点 / 性能·并发
   → RTL 根因回放 → 四类改动：改 RTL、改激励、补插桩、调分区/约束
   → 重编译（局部增量优先）→ 回归基线对比 → 再上板

阶段 6 输出的数据有两个去向：交 ASIC 团队做签核消费是阶段 7（25 真实激励驱动 ASIC 签核 SAIF 反标/边界）；回到设计与验证团队改进系统本身，就是本篇。

二、原型速度下的覆盖率回收 ​

先分清原型在覆盖率体系里的位置——它不是仿真的替代，而是补仿真够不着的长尾：

覆盖类型仿真原型回收方式
行/条件/翻转（代码覆盖）主力，快、全、可合并仅补长场景增量轻量计数探针或从活动统计折算未触达点
功能覆盖（covergroup）主力（UVM 采样）长软件场景下的罕见场景关键 bin 的片上命中计数器，经 co-model 回传主机合并
断言主力只放轻量并发断言/协议检查（断言失败即触发 trace）综合可综合断言或手写检查 FSM
场景/状态空间定向+随机，受速度限OS 启动、真实流量、压力 soak 的主战场状态枚举覆盖矩阵 + 事务流记录

合并纪律：原型覆盖数据与仿真覆盖数据用同一套层次名（RTL ID 对齐，10 RTL ID 体系 分配规则/层次绑定/稳定性）汇入统一覆盖率数据库，标明来源；原型不重跑仿真已充分覆盖的点，而是定向回答「真实软件跑 24 小时后，还有哪些状态/组合没见过」。典型收获：驱动里的错误恢复分支、罕见仲裁组合、长时间运行才出现的计数器回绕。

三、活动/翻转分析：热点、空转与死模块 ​

回映后的 T0/T1/翻转数据（23 Gate→RTL 数据回映 查表/聚合/SAIF）按 RTL 实例子树聚合，得到三张视图：

  1. 热点排序：翻转率按模块/层级降序——找最「忙」的子系统。结合性能数据区分「在干有用的活」（数据通路高活动+高吞吐）和「在空转烧电」（轮询寄存器、无效握手反复、FSM 在 busy 态打转）；
  2. 死模块/冷区：整段负载活动为零或极低的实例。三种解释都重要——功能没跑到（覆盖缺口，补激励）、时钟/使能被关（正常低功耗设计，核实是不是预期）、死代码（RTL 里存在但系统结构上不可达，反馈给设计清理，也减轻下次分区压力，12 多 FPGA 分区算法 割集/容量/图划分）；
  3. 时间剖片：把负载切成启动/稳态/突发等区间，看活动随时间迁移（启动阶段配置总线忙、稳态数据通路忙），为签核侧选择「典型工况窗口」提供依据。

与功耗签核的边界（25 真实激励驱动 ASIC 签核 SAIF 反标/边界）：本篇只做相对分析（谁比谁热、热点对不对、结构合理性）；绝对功耗数字、电压/库/寄生相关的结论属于阶段 7，原型活动率不等于芯片功耗（时钟树、SRAM 内部、glitch 都不在探针可见范围，见 23 Gate→RTL 数据回映 查表/聚合/SAIF）。

四、性能剖视：吞吐、延迟与流水线气泡 ​

真实速度下的性能数据是仿真难以提供的：

  • 性能监控单元（PMU）式计数：事务计数、字节吞吐、延迟直方图（请求发出→响应返回的周期数分桶）、队列水位峰值/均值、仲裁授予次数与等待次数；计数器是常驻粗粒度探针（22 Gate 域信号采集 ILA/trace/带宽深度权衡），开销极小；
  • 气泡归因：低吞吐时用 trace 回答流水线在等什么——valid 常低（上游供数不足）、ready 常低（下游反压）、stall 在特定仲裁（饥饿）、cache miss/DRAM 访问长延迟；把 valid/ready/state 枚举画成时间泳道，气泡模式一目了然；
  • 基准对比：RTL 版本间、配置间（开/关某特性、不同时钟计划）做同负载 benchmark，周期数差异直接量化架构决策；
  • 这些指标同时是软件团队的接口：固件可以读同一批计数器，把「硬件周期」与「软件事务」对齐，定位延迟在驱动栈还是 RTL（29）。

五、并发类 bug：原型速度的主场 ​

死锁、活锁、竞态、优先级反转、内存顺序类问题有个共同特征：需要真实并发和长时间运行才暴露，仿真的受控调度反而难以触发。原型策略：

  1. 可复现化：一旦 soak 测试挂起，先保现场（死锁时 trace 触发大 pre-trigger 窗口已经在环形缓冲里，22 Gate 域信号采集 ILA/trace/带宽深度权衡）；记录 build_id、种子、负载 mix、持续时间（21 激励注入与软硬协同 co-model/transactor）；尝试锁步模式+同种子重放提高复现率；
  2. 死锁定位：挂起时 dump 所有相关 FSM 状态、互斥/credit 持有者、队列水位——死锁必然呈现「环等」：A 等 B 的 credit、B 等 C 的响应、C 等 A 的释放；在事务/资源持有图上把环找出来；
  3. 活锁/吞吐塌陷：计数器不停止增长但有效吞吐趋零（不断重试/撤销），用成功率计数和重试计数暴露；
  4. 竞态：偶发数据损坏——用轻量断言（「FIFO 满时不得写入」「同一 ID 不能同时有两个未完成请求」）在片上抓第一次违例并触发，比事后看波形有效；
  5. 压力放大：故意配置极端混合（满队列、最慢对端、错误注入）提升复现概率，这是原型相对硅后调试的最大优势——可以无后果地折磨系统。

六、RTL 侧根因回放 ​

抓到现场后，23 Gate→RTL 数据回映 查表/聚合/SAIF产出的 RTL 层次波形让调试回到设计团队熟悉的形态：

  1. 在 Verdi/DVE 类工具里打开原始 RTL 源码和层次波形（信号名是 RTL 名、状态机是枚举值，23 Gate→RTL 数据回映 查表/聚合/SAIF）；
  2. 与事务日志、固件 print 在公共周期轴上对齐（21 激励注入与软硬协同 co-model/transactor），从异常点向前回溯因果链；
  3. 先判问题归属：RTL 设计缺陷、激励/软件误用、原型适配引入（替换模型语义差异，08 不可综合构造识别与存根替换 模拟IP/时钟门控/11 ASIC→FPGA 等价单元替换 SRAM/时钟/IO/PHY）、还是观测假象（探针扰动、跨片延迟，22 Gate 域信号采集 ILA/trace/带宽深度权衡）——后两类不改 RTL；
  4. 修复后在同一负载、同种子上验证现象消失，并跑回归确认无新增活动异常（23 Gate→RTL 数据回映 查表/聚合/SAIF 的跨版本活动 diff）。

七、反哺下一轮：四类改动与回归基线 ​

每次分析结论转化为具体工程动作：

回归基线：固定一组基准负载（boot、典型业务 mix、长 soak），每版 build 产出标准指标卡：周期数/吞吐、关键延迟桶、活动热点 Top20、覆盖增量、断言计数。基线对比让「改进还是劣化」不再凭感觉；指标突变即使功能 pass 也要解释。

八、与硅前/硅后验证的协同 ​

闭环数据在更大验证图景中的位置（05 原型到硅后衔接 pre/post-silicon 协同/errata）：

  • 仿真负责广度（随机空间、定向 corner、全断言），Emulation 负责深度可观测（全信号追溯，37），原型负责真实度与时长（真实软件、真实接口、小时~天级 soak）；
  • 原型发现的 concurrency bug 应转成仿真/形式验证的定向用例（原型证明确有问题，仿真提供可在 CI 中反复执行的快速检查）；
  • 原型上验证过的 bring-up 脚本、固件初始化序列、调试计数器设计直接沉淀为硅后 bring-up 资产（03 原型平台 bring-up 多片点亮/trace）；
  • 原型阶段记录的「未覆盖区域/已知风险」进入硅后验证计划，形成 pre-silicon 到 post-silicon 的连续证据链。

九、指标体系与基线管理：让「改进」可以被度量 ​

闭环之所以是闭环，靠的不是一次性的热点排序，而是一套能跨版本比较、能回答「这一版到底变好还是变坏」的指标体系。没有稳定基线，性能和活动分析很容易退化成每次都从头解释的快照。

先定义每层的标准指标。 功能层用通过率、断言计数、覆盖率增量（代码/功能/状态机/断言覆盖各自的命中与缺口）；性能层用吞吐（每周期/每秒事务数）、延迟分布（不只平均值，要分桶看长尾和最大延迟）、队列水位与满/空停留时间占比、仲裁等待与反压次数、流水线气泡占比；活动层用按实例/层次聚合的翻转率、时钟门控（ICG enable）占空比、存储端口活动、总线占用率；可靠性层用错误注入后的重试成功率、恢复时间、死锁/超时计数。关键原则是指标尽量归一到「每逻辑周期」或「每事务」这种与 FPGA 频率解耦的单位，这样换一档频率或改一次插桩，数字仍可横向比较。

再固定基准负载（benchmark suite）。 选一组有代表性、可复现的场景作为标准卡：一个最小冒烟负载（快速判断 build 健康）、一个典型业务 mix、一个高峰/最坏 mix、一个长时 soak、若干定向的边界与错误恢复场景。每个负载固定激励种子、配置、时长和预期的功能结果。所有版本在同一组基准上取数，跨版本 diff 才有意义——否则「这个版本吞吐高」可能只是这次的流量更轻。基准负载应和测试用例一样纳入版本管理，任何对负载的改动都显式标注，因为它改变了所有历史指标的可比性。

基线比较要区分噪声与真变化。 活动和性能数字会受布局布线、插桩版本、TDM 配置、甚至随机仲裁影响产生抖动。做法是：对同一 build 重复跑若干次取分布、设定噪声带（例如 ±X% 内视为无变化）、只对超出噪声带的指标变化报警并要求解释；同时在每次取数的结果头里记录 build_id、插桩等级、频率/TDM、种子，保证比较的是同类构建。要特别防止「功能 pass 但指标悄悄劣化」——这正是基线卡的核心价值：吞吐掉 15%、某队列水位从 20% 涨到 90%、一个死模块突然开始疯狂翻转，都可能是架构退化或 bug 的早期信号，即便功能测试全绿也必须给出原因。

把闭环固化进流程而非依赖个人。 每次 RTL 冻结/重编译后自动跑基准卡、出指标卡、和基线 diff，超阈值自动标红；分析结论沉淀为四类工程动作（改 RTL、改激励/补场景、补/调插桩、调分区与约束），并把「动作—预期指标变化—复测结果」记录在案，形成可审计的改进链。覆盖率缺口则反向驱动新场景设计（原型长尾缺口里能在仿真定向补的回灌仿真，需要真实软件/时长的留给下一版原型计划）。到这一步，「采集—回映—分析—改设计—再编译」才真正成为一个被数据驱动、自我收紧的工程闭环，而不是靠调试者手感转动的一次性流程。

十、从原型数据到组织资产：沉淀、反哺与方法论迁移 ​

一次闭环的终点不应是「这个 bug 修好了」，而是「这套发现 bug 的能力变成了组织可复用的东西」。阶段 5~6 产生的数据、脚本和经验，若不主动沉淀，下个项目还会从零踩同样的坑。这一节讨论如何让原型调试成果跨项目沉淀为资产。

第一类资产是可复用的验证内容。 原型上为暴露并发/性能问题而构造的极端 mix、错误注入场景、长软件负载，应回灌成仿真和形式验证的定向用例——把「跑了三千万周期才出现的死锁」在理解根因后压缩成一个几十周期就能复现的小用例，放进回归库永久守护。反过来，原型常驻的片上断言（捕捉竞态第一次违例、状态机非法跳转、协议握手不变量）本身就是可以在仿真/Emulation/原型三端共用的一套属性，统一维护比各写各的检查更可靠。发现一个问题、补一条断言、加一个用例，三者成组提交，是最有价值的沉淀单元。

第二类资产是调试基础设施和 bring-up 剧本。 上一项目为多片对齐写的同步计数器和触发广播、为性能剖视做的 PMU 式计数器、寄存器自环与拓扑枚举、采集汇聚网络，都应抽象成与具体 DUT 无关的 IP/模板随平台版本演进；bring-up 的操作顺序（枚举网络→核版本→自环→配参数→广播启动→快照取状态）则沉淀为带检查点的剧本（runbook），新人照做即可复现老团队的排障效率。每个项目结束时做一次「哪些手工步骤可以自动化、哪些信号应当默认可观测」的复盘，基础设施就会一代比一代厚。

第三类是数据资产和模型校准。 历次项目的活动/性能基线、场景权重画像、原型与仿真对拍的偏差统计、以及最终硅后实测回流，构成校准整套方法论的真值库：这一类模块原型活动通常比实测高/低多少、哪种插桩扰动有多大、哪些场景在原型上代表性不足，都可以从历史数据中量化，让新项目在早期就能给活动率和性能预测标注经验置信区间。硅后偏差按「活动假设错 / 库寄生模型错 / 工况权重错」三桶归因回流，更直接改进下一代芯片的原型规划（哪些模块值得多放观测点、哪些场景必须尽早用真实软件跑）。

更上位的是方法论向其他验证形态的迁移。 原型闭环里成熟起来的思维方式——用常驻计数器代替临时波形、用基准卡和基线 diff 度量变化、用「触发—快照—时间轴归并」处理并发、用覆盖率缺口反向驱动场景设计、用分级可信度对待数据——同样适用于仿真平台和 Emulation 平台的建设。团队一旦形成「任何运行都要可复现、任何结论都要可分级、任何修复都要回归守护」的共识，原型系统就不再是孤立的硬件机柜，而成为整个硅前验证体系中产生真实长场景和并发证据、并持续反哺其他工具的一环。这正是 06~25 系列反复强调「链路」而非「单点技巧」的原因：单个原型平台的价值随项目结束而折旧，而沉淀下来的验证资产和数据纪律会在每一代芯片上复利。

十一、常见分析陷阱：活动数据会怎样把你引向错误结论 ​

活动和性能数据看似客观，但错误的采集口径、错误的分母或错误的比较方式，会让「用数据说话」变成「用数据自欺」。这一节列出阶段 6 分析中最常见的陷阱，它们都不会报错，却会直接导向错误的架构决策。

陷阱一：把翻转率当功耗排序，忽略了负载电容。 活动率高不等于功耗高：一根驱动大负载（长走线、大扇出、宽总线）的线翻转一次的动态功耗，可能顶得上几十根短连线；时钟网络即使翻转规律，其巨大负载也使它常年是功耗大户。正确做法是活动数据必须结合网表电容（在 ASIC 侧完成）再排序，原型侧只能产出「谁在翻转、翻转多少」，不能直接喊「谁最耗电」。把原型上的翻转热点直接当瓦数热点汇报，是跨团队最常见的误用。

陷阱二：把「忙碌」当「有用」。 轮询一个就绪标志的循环会让总线和模块持续高翻转，活动率很漂亮，实际有效吞吐为零；总线被无效 spec 传输占满，占用率百分之百却没搬有效数据。分析时必须区分有效活动与空转活动：用有效事务计数和总周期数算有效占空比，把「忙而无用」识别为软件或仲裁策略问题。反过来，某些低翻转模块（如电源管理、安全监视）活动极低却不可或缺，不能据此当成死代码清理——死模块判定需要结合结构可达性和功能覆盖，单看翻转率会误杀。

陷阱三：错误的时间分母。 TDM 设计里用物理周期数而非有效时槽周期数做分母，活动率被系统性稀释；停钟/锁步区间没从分母扣除，活动率又被稀释；多片计数窗口没对齐就相加，部分窗口重复计数。所有活动率结论都要先回答「分母是什么周期、扣除了哪些区间」，这个口径要随数据头传递，不能在分析阶段凭印象选择。

陷阱四：拿不可比的版本做基线 diff。 插桩等级不同（轻量版和重 ILA 版比较）、时钟频率或 TDM 配置不同、基准负载不同（软件版本变了、种子变了），得到的性能差异可能全部来自测量条件而非设计变化。基线管理必须先核对构建元数据，再比较指标；跨大版本比较时优先用「每事务周期数」这类归一化指标，而不是原始带宽。

陷阱五：被平均值骗了，忽视长尾和并发时刻。 平均延迟达标不代表没有致命长尾；模块级平均活动看不出多个模块在高峰瞬间同时翻转造成的电流尖峰（这恰恰是 IR-drop 的关键）。分析要保留分布（延迟直方图、时间剖片）和同时性视图（哪些模块在同一时间窗活跃），而不是只汇总成几个平均值。

陷阱六：把相关当因果。 观察到「开了特性 A 之后吞吐下降」，可能是 A 带来的额外仲裁、也可能是同期流量 mix 变了。根因分析要回到 RTL 层次波形沿时间轴回溯因果链，必要时用控制变量法重跑（关掉 A、固定其余条件）。数据负责暴露异常和提出假设，因果确认仍需回到设计本身——这正是「分析闭环」最后必须接回 RTL 根因回放、改设计、再回归验证的原因。

把这些陷阱列成分析评审的固定检查项，活动数据才能真正成为架构改进的依据，而不是一份会自我证明的误导材料。

十二、团队协作中的分析闭环：角色、交接物与会议节奏 ​

工具和指标就绪后，闭环能否真正转动取决于人的协作方式。原型分析涉及原型团队、设计团队、验证团队和软件团队，数据在团队之间传递时最容易出现「报告发了但没人用」「问题修了但没人复测」的断点。这一节给出让闭环持续运转的最小协作机制。

先明确角色和各自关心的问题。 原型团队负责平台、采集系统和数据可信度，回答「这个数能不能信」；设计（RTL）团队关心微架构问题——流水线气泡、仲裁饥饿、时钟门控机会、死锁根因，是大部分改 RTL 动作的执行者；验证团队关心覆盖缺口和新场景，把原型发现的长场景问题压回仿真用例；软件团队关心驱动序列、性能调优和「软件怎么用才不触发硬件边界情况」。一份分析报告若不分对象地群发，结果往往是谁都不看；正确做法是按角色拆结论：给设计师的是带波形指针的根因和建议，给验证的是场景描述和复现条件，给软件的是用法约束和寄存器级建议。

定义标准化交接物，让每次交接无需口头解释。 从数据到行动之间至少有三种交接包：一是分析包（哪个版本、哪个基准负载、异常指标、相关波形时间窗、初步假设），二是缺陷包（最小复现条件、锁步重放脚本或种子、期望与实际行为对比、涉及 RTL 层次路径），三是复测包（修复提交标识、需重跑的基准列表、预期恢复的指标值）。每个包都带构建号和数据来源分级，接收方不必追问「这是哪版比特流上看到的」。交接物模板化之后，跨团队沟通成本会从开会解释降到读卡片。

用固定节奏的短会驱动闭环，但让数据而不是进度汇报成为主角。 一种被验证有效的节奏是：每次冻结构建后自动跑基准卡并生成指标卡，召开短会只讨论三件事——相对基线超阈值的指标、未关闭缺陷包的状态、下一轮插桩/场景计划。会上当场给每个异常指定负责人和预期动作类型（改 RTL/补场景/调插桩/查分区），缺陷包当场建或关。避免把这种会开成平台运维汇报：平台健康度（构建成功、链路在线、采集无溢出）用仪表盘自动展示，只有红灯才上会。

保护闭环不被「紧急演示」打断。 原型系统常被各种里程碑演示征用，临时改配置、跑非基准负载会污染基线数据。协作机制上应区分演示构建和分析构建（各自独立的比特流和数据目录），分析团队的基准卡排期要和演示排期共享同一份平台日历；演示后的平台状态（时钟、固件、线缆）要有恢复检查清单，确保下一轮分析跑在已知状态上。

闭环成熟度的最终标志是「无会议的自动转动」。 夜间自动构建→自动跑基准→自动生成 diff 报告→超阈值自动建缺陷包指派到模块 owner→修复合入后自动回归关闭——人只在需要根因判断和架构决策时介入。到这一步，原型活动与性能分析就从专家的手工技艺，变成了团队开发流程中像持续集成一样自然的一环；68 篇描述的「采集—回映—分析—改设计—再编译」闭环，才算真正获得了组织层面的永久动力。

知识脉络 ​

FPGA 原型验证专题 24：原型活动、覆盖率与性能调试闭环——翻转热点、瓶颈定位与 RTL 侧根因回放 示意图（第 2 张）

与系列及现有篇目的衔接 ​

总结 ​

一句话总结：本篇讲阶段 6 数据回流到设计/验证团队的分析闭环——上板→采集→回映→覆盖率/活动/性能并发三条分析线→RTL 根因回放→改 RTL/改激励/补插桩/调分区四类动作→增量重编译→基线回归→再上板；覆盖率上原型不替代仿真而是补长尾：仿真主攻代码/功能覆盖与断言，原型以常驻轻量命中计数器和状态枚举矩阵回收 OS 启动、真实流量、长时 soak 才能触达的错误恢复、罕见仲裁和回绕场景，数据用 RTL ID 对齐汇入统一覆盖库并标明来源；活动分析按实例子树聚合翻转率，产出热点排序（区分有效忙碌与轮询空转）、死模块/冷区三分类（覆盖缺口、正常低功耗、可清理死代码）和时间剖片，但只做相对结构分析，绝对功耗结论归阶段 7；性能剖视靠常驻 PMU 式计数器（吞吐、延迟直方图、队列水位、仲裁等待）和 valid/ready/state 时间泳道做气泡归因，并在版本和配置间量化架构决策；死锁/活锁/竞态/优先级反转等需要真实并发与时长才暴露的问题是原型主场，打法是环形缓冲大 pre-trigger 保现场、种子/负载/build_id 全记录、锁步重放提复现率、资源持有图找死锁环、成功率与重试计数揭活锁、轻量片上断言抓竞态第一次违例、极端 mix 无后果压测；根因回放时在 RTL 层次波形里沿公共周期轴回溯因果，先区分 RTL 缺陷、软件误用、适配模型差异和观测假象再决定是否改 RTL；每次分析沉淀为四类工程动作，受影响模块按结构指纹做增量构建，并以固定基准负载的标准指标卡（周期/吞吐/延迟桶/热点 Top20/覆盖增量/断言计数）做跨版本基线对比，功能 pass 但指标突变也必须解释；在大图中仿真管广度、Emulation 管全信号深度、原型管真实度与时长，原型发现的并发 bug 反哺为仿真/形式定向用例，bring-up 脚本与调试计数器沉淀为硅后资产，未覆盖区域进入硅后计划，形成硅前到硅后的连续证据链。