📚 课程目录第2章 PrimeTime启动与设计加载

2. PrimeTime启动与设计加载

PrimeTime 的时序签核流程从“把设计装进工具”开始。所谓启动与设计加载，并不是简单敲几条命令，而是要在 PrimeTime 内部建立起一个自洽的数据库：设计网表、工艺库、寄生参数三者必须相互匹配，任何一处对不上，后续的时序分析都会失真甚至直接报错。本节围绕 set_app_var、read_verilog、link_design、current_design 这几条核心命令，讲清楚它们各自做什么、按什么顺序执行、以及如何判断加载是否成功。

启动阶段：先设定工具行为

PrimeTime 启动后，第一件该做的事往往不是读设计，而是用 set_app_var 设定应用变量，控制工具的行为模式。这些变量决定了后续命令如何解释路径、如何搜索库文件、如何处理未解析的引用。常见的几类包括：

search_path：告诉 PrimeTime 到哪些目录去找库文件和设计文件，相当于给工具一张“地图”。
link_path：链接阶段搜索设计单元和库单元的路径列表，通常包含标准单元库、宏单元库、存储器库等。
target_library：指定映射和时序计算所用的目标工艺库，是时序签核的基准。
link_library：链接时用于解析实例引用的库集合，一般写成 "* $target_library"，其中 * 表示先在内存中已加载的设计里查找。
sh_enable_page_mode、sh_command_abbrev_mode 等：控制 shell 交互行为，属于使用体验层面的设置。

这些变量必须在读设计和链接之前设好，因为 link_design 会直接依赖 link_library 和 link_path 去解析每一个实例。一个典型的启动片段如下：

set_app_var search_path ". ./libs ./rtl ./netlist"
set_app_var link_path "* ./libs/slow.db ./libs/fast.db"
set_app_var target_library "slow.db"
set_app_var link_library "* $target_library"
set_app_var sh_enable_page_mode false

这里 target_library 设为 slow.db，意味着默认按慢速工艺角做时序计算；link_library 中的 * 让工具优先复用内存中已有的设计，避免重复加载。

读入网表：read_verilog 与库文件加载

设计加载通常分两条线：一条是读入设计的门级网表，另一条是读入工艺库。PrimeTime 支持 read_verilog 读取 Verilog 网表，也支持 read_db、read_liberty 读取库文件。对于门级签核，网表一般是综合或布局布线后导出的结构级 Verilog。

read_verilog ./netlist/top_netlist.v
read_db ./libs/slow.db
read_db ./libs/fast.db

需要注意：read_verilog 只是把网表文本解析进内存，此时设计还没有和库单元建立真正的链接关系。网表里出现的 AND2X1、DFFRX2 这些实例，此刻只是名字，PrimeTime 还不知道它们对应哪个库单元、有什么时序弧。这一步的产物是“未链接的设计”。

如果设计包含多个模块或层次，可以一次读入多个文件，也可以使用 read_verilog -container rtl 之类的选项区分容器。对于寄生参数，通常在链接之后用 read_parasitics 读入 SPEF 文件，因为寄生参数需要绑定到具体的网络和引脚上，必须等设计链接完成、网络名确定之后才能正确关联。

链接设计：link_design 的关键作用

link_design 是设计加载中最关键的一步。它把读入的网表与库文件“焊接”起来：遍历设计中每一个实例，在 link_library 指定的库里找到对应的单元定义，建立实例到库单元的引用关系，同时解析端口、时序弧、引脚电容等信息。

link_design top

执行后，PrimeTime 会输出链接结果。如果某些实例在库中找不到，会报 “Unable to resolve reference” 之类的警告或错误。常见原因有三类：库文件没读全、link_library 路径不对、网表里用了库中不存在的单元名。链接不完整会直接导致时序路径断裂，因此必须检查链接报告，确认没有 unresolved reference。

链接完成后，设计才真正具备可分析性。此时可以用 current_design 查看或切换当前设计：

current_design
current_design top

current_design 不带参数时返回当前设计名；带参数时把指定设计设为当前设计。对于多设计会话，切换当前设计会影响后续命令的作用对象，因此每次切换后最好确认一下。

加载寄生参数与设计状态检查

链接完成后，读入寄生参数：

read_parasitics -format spef ./spef/top.spef

SPEF 中的网络名必须与链接后的设计网络名一致，否则寄生参数无法绑定。读入后可以用 report_annotated_parasitics 检查注释覆盖率，确认没有大量网络缺失寄生信息。

整个加载流程可以用下面的信号链来理解：应用变量设定工具行为，网表和库分别读入，link_design 把两者绑定，current_design 确定操作对象，最后寄生参数挂到网络上，形成完整的时序分析数据库。

加载成功的判断依据

设计加载完成后，不能想当然认为一切正常，需要用几条命令确认状态。首先看链接报告，确认没有 unresolved reference；其次用 report_design 或 list_designs 查看当前设计的基本信息，包括实例数、端口数、层次结构；再用 report_annotated_parasitics 检查寄生参数注释率。如果注释率很低，说明 SPEF 与网表网络名不匹配，需要回到读入环节排查。

一个实用的检查顺序是：current_design 确认对象 → report_design 看规模 → report_annotated_parasitics 看寄生覆盖 → 最后再进入约束和时序分析。加载阶段多花几分钟检查，能避免后续分析结果出现难以定位的偏差。

常见错误：link_design 之前没有设置 link_library，导致所有实例都无法解析；或者 target_library 与 link_library 指向不同工艺角，造成时序计算基准不一致。这两类问题在加载阶段就会暴露，务必在链接后立即检查报告。

总结来说，PrimeTime 的设计加载是一条有严格顺序的数据链：set_app_var 先定规则，read_verilog 和库读入提供原料，link_design 完成绑定，current_design 锁定操作对象，read_parasitics 补齐物理信息。每一步都有明确的输入、输出和检查点，只有链条完整，后续的时序签核才有可信的基础。