1. 多模式多角STA工程导入

在先进工艺节点下,一颗芯片往往要同时满足多种工作模式与多个工艺角(PVT Corner)的时序要求。例如一颗SoC可能包含高性能模式、低功耗模式、待机模式,而每个模式又要在SS 0.72V 125℃、TT 0.80V 25℃、FF 0.88V -40℃等不同角下签核。如果只做单一模式、单一角的STA,签核结论几乎必然在硅后失效。多模式多角(Multi-Mode Multi-Corner,MMMC)STA工程,就是把"模式×角"的组合空间系统化管理起来,让PrimeTime在正确的约束、正确的库、正确的条件下,对正确的路径给出可信的时序结论。

一、为什么必须做MMMC签核

先看一个直观的对比。假设设计有3种模式、5个角,若只做单模式单角,覆盖率仅为 1/15 ≈ 6.7%;即使做3模式×1角,也只覆盖20%。而真正决定芯片能否工作的,往往是某个特定组合下的关键路径。例如低功耗模式下时钟被分频到1/8,看似时序宽松,但若该模式下电压降到0.72V,单元延迟上升约40%,原本在TT角有0.15ns裕量的路径可能直接违例。这就是MMMC存在的根本原因:时序违例不是"设计"的属性,而是"模式+角"组合的属性。

从工程意义上看,MMMC签核要回答三个问题:第一,每个模式在每个角下是否都满足建立/保持要求;第二,跨模式切换(如DVFS切换、时钟切换)时是否存在亚稳态或时序断裂;第三,哪些组合是真正的签核瓶颈,需要优先优化。PrimeTime通过scenario(场景)机制把"模式+角"封装为一个可独立分析的对象,每个scenario绑定一套SDC约束、一组库文件和一组工作条件,从而把组合空间变成可枚举、可并行、可复现的工程对象。

二、典型场景与PrimeTime的角色

实际项目中,MMMC的典型场景包括:多电压域DVFS、多时钟域(功能时钟/测试时钟/低速调试时钟)、多工艺角签核(WC/BC/TC及温度反转)、以及模式切换路径。以DVFS为例,高性能模式用1.0V/FF角追求频率,低功耗模式用0.72V/SS角追求功耗,两者对同一路径的约束方向可能完全相反——前者要求快,后者要求稳。PrimeTime的角色不是"跑一次STA",而是作为签核引擎,把每个scenario的时序结果汇总成一张覆盖矩阵,供工程判断。

MMMC签核:模式 × 角 组合空间与PrimeTime场景映射 工作模式 Mode 高性能 HP 1.0V / 高频 低功耗 LP 0.72V / 分频 待机 STBY 0.72V / 门控 测试 TEST scan / at-speed 组合空间 Mode × Corner HP × SS 0.72V 125℃ HP × TT 0.80V 25℃ HP × FF 0.88V -40℃ LP × SS 0.72V 125℃ LP × TT 0.80V 25℃ STBY × SS 0.72V 125℃ TEST × FF 0.88V -40℃ … 共 N×M 个组合 PrimeTime Scenario 引擎 每个 Scenario 绑定 SDC约束 + 库文件 + 工作条件 create_scenario / set_active_scenarios 并行分析,独立报告 report_timing -scenario 逐场景 WNS / TNS / 违例路径 覆盖矩阵汇总 识别瓶颈组合,指导优化 签核结论:全组合通过 / 定位违例

三、课程要交付的签核能力

本课程最终要交付的不是"会用PrimeTime命令",而是一套可复现的MMMC签核能力。具体包括四层:

  • 建模层:能正确建立多模式约束,包括模式定义、时钟关系、case analysis、模式间互斥与切换约束。
  • 角管理层:能组织库文件、工作条件、降额(derate)与OCV设置,保证每个角的环境真实可信。
  • 场景执行层:能用scenario机制批量执行,合理使用多线程与分布式,控制运行时间。
  • 结果判读层:能从WNS/TNS、违例路径、跨模式路径中定位真正的签核瓶颈,并给出优化方向。
MMMC不是"多跑几次STA"。它的核心价值在于:把组合空间显式化、把约束与角绑定、把结果矩阵化。只有做到这三点,签核结论才可复现、可审计、可交付。

四、一个最小可运行的场景骨架

为了让后续章节有统一的落点,这里先给出一个最小MMMC场景骨架。假设设计有两种模式(func_fast、func_slow)和两个角(ss_0p72v_125c、ff_0p88v_m40c),在PrimeTime中的组织方式如下:

# 1. 定义角(库 + 工作条件)
create_scenario ss_0p72v_125c
set_operating_conditions -library ss_lib -voltage 0.72 -temperature 125
read_sdc ./sdc/func_fast.sdc

create_scenario ff_0p88v_m40c
set_operating_conditions -library ff_lib -voltage 0.88 -temperature -40
read_sdc ./sdc/func_slow.sdc

# 2. 激活并分析
set_active_scenarios {ss_0p72v_125c ff_0p88v_m40c}
update_timing

# 3. 逐场景报告
report_timing -scenario ss_0p72v_125c -delay max
report_timing -scenario ff_0p88v_m40c -delay max

这段骨架的关键点在于:每个scenario独立绑定SDC与工作条件,互不干扰;set_active_scenarios决定本次分析覆盖哪些组合;report_timing按场景输出,便于横向比较。实际项目中,模式与角的数量会远多于两个,但组织逻辑完全一致——先定义、再激活、后报告。

五、学习路径与判断标准

后续章节将按"约束建模→角管理→场景执行→结果判读→工程优化"的顺序展开。判断自己是否掌握本章内容,可以用三个问题自检:第一,能否说清某个违例路径属于哪个模式、哪个角;第二,能否解释为什么某个组合是瓶颈而另一个不是;第三,能否在不重跑全量的前提下,只针对瓶颈组合做增量分析。如果这三个问题都能回答,说明已经建立了MMMC签核的基本工程思维,可以进入下一阶段的约束建模细节。

常见误区:把MMMC等同于"把所有角都跑一遍"。真正的MMMC工程要求每个场景的约束、库、工作条件三者一致且可追溯。若某个scenario的SDC与库角不匹配,得到的时序结果不仅无用,还会误导优化方向。