时钟门锁检查(Clock-Gating Checks)：
pt_shell> set_clock_gating_check -setup 0.5 -hold 0.1 $clock
pt_shell> set_min_pulse_width 2.0 $clock 如果设计被反标过，PrimeTime用SDF的建立和保持时间值，以及时钟脉冲宽度说明。
得到一个时序摘要：
pt_shell>report_design …
pt_shell>report_reference …
检查时序声明和设计的结构：
在进行时序分析之前运行check_timing命令是关键。这个命令能够检查到所有可能的时序问题。
在这个例子中将会出现警告，原因是存在没有约束条件的端口。
运行时序分析
设置端口延时并检查时序：
pt_shell> set_input_delay 0.0 [all_inputs] -clock $clock
pt_shell> set_output_delay 2.0 [get_port INTERRUPT_DRIVER_ENABLE] -clock $clock
pt_shell> set_output_delay 1.25 [get_port MAPPING_ROM_ENABLE] -clock $clock
pt_shell> set_output_delay 0.5 [get_port OVERFLOW] -clock $clock
pt_shell> set_output_delay 1.0 [get_port PIPELINE_ENABLE] -clock $clock pt_shell> set_output_delay 1.0 [get_port Y_OUTPUT] -clock $clock pt_shell> set_driving_cell -lib_cell IV -library pt_lib [all_inputs] pt_shell> set_capacitance 0.5 [all_outputs] pt_shell> check_timing
保存设置：
将所设置的时序信息保存为脚本文件可以确保在接下去的运行中保留一个时序环境的复本。使用write_script命令，这个命令将以下这些信息保存到一个命令文件中：
Clocks Names, waveforms, latency, and uncertainty
Exceptions False and multicycle paths, minimum and maximum
delays, and path groups
Delays Input and output delays, all delay annotations, and
timing checks
Net and port attributes Capacitance, resistance, and fanout
Design environment Wire load model, operation condition, drive, driving cell,
and transition
Design rules Minimum and maximum capacitance, minimum and
maximum fanout, and minimum and maximum transition
write_script命令可以将脚本写成Design Compiler格式(dcsh or dctcl mode)或者PrimeTime格式(ptsh)。
不能用PrimeTime写一个被标注设计的.db文件，因为PrimeTime只能写时序模型的.db文件。以脚本为主要方式是为了和Design Compiler传递数据。
pt_shell> write_script -format dctcl -output AM2910.tcl pt_shell> write_script -format dcsh -output AM2910.dcsh pt_shell> write_script -format ptsh -output AM2910.pt
运行基本的分析：
1． 得到AM2910的约束报告： pt_shell>report_constraint
2. 检查报告中的时序违规(timing violations)和约束违规（constraints violations）
3． 到更多关于违规的信息：
pt_shell> report_constraint -all_violators 4． 检查这份报告：
这里有多少违规的结束点(endpoints)？
报告基于路径的时序信息：
pt_shell>report_timing
设置时序例外情况：
因为PrimeTime直到进行完整的时序升级(timing update)之前才检查时序例外情况的正确性，所以要运行report_exceptions以确定它们的正确性。
声明AM2910的时序例外情况。设置一条两个时钟周期的路径，其中建立时间为2，保持时间为1：
pt_shell> set_false_path -from U3/OUTPUT_reg[*]/CP \\ -to U2/OUTPUT_reg[*]/D
pt_shell> set_multicycle_path -setup 2 -from \\ INSTRUCTION[*] -to U2/OUTPUT_reg[*] pt_shell> set_multicycle_path -hold 1 -from \\ INSTRUCTION[*] -to U2/OUTPUT_reg[*] pt_shell> update_timing pt_shell> report_exceptions
pt_shell> report_exceptions -ignored
评估时序例外情况结果：
1． 得到另外一个约束报告并评估违规情况： pt_shell>report_constraint –all_violators 2． 检查这份约束报告
3． 确信所设置的例外情况是否能够使得设计中的违规显现比以前更少。设计中最
差余量(the worst slack)是什么？ pt_shell>report_timing
4. 检查这份详细的时序报告。
5. 看其它的违规路径。从这份约束报告中选择一个结束点，并键入： pt_shell> report_timing -to endpoint
6. 检查这份报告。
提取一个子设计的边界时序特性信息：
一个子设计的相关时序特性信息的提取是基于它相关的上级设计环境。这些信息有 两个主要用途：
一个主要用途是PrimeTime将这些相关特性信息提供给Design Compiler作为约束信息。这是DC中从芯片级分析到模块级优化主要的纽带，与只是作分析的单点工具相比提供了更佳的整合性。
提取了相关特性信息之后，命令PrimeTime写一个包含子设计或模块时序信息的脚本。
在提取时序特性的同时，要注意：
1． 特性信息提取不能够预计子设计的时序状况；
2． 特性信息提取没有最大或最小这两种工作模式。所以在做这步工作之前要设置
单一的、正确的运作条件。
对于PrimeTime而言，相关时序信息允许作层次化的时序分析，并观察芯片层次的 时序约束；对于Design Compiler而言，相关时序信息允许在综合或逻辑优化时设置时序约束。
在Design Compiler中设置综合或优化约束的步骤是： 1． 在PrimeTime中读入顶层设计 2． 确认需要优化的子设计
3． 提取每一个子设计的特性信息
4． 为每一个子设计生成一个Design Compiler的脚本 5． 将这些子设计读到Design Compiler中 6． 将步骤4中生成的脚本引入进来 7． 进行模块级的优化
仅将需要优化的子设计读入到DC中去，这样DC运行起来可以效率高一些。优化完这 些模块之后，再将它们读入到PrimeTime中去作新一轮的时序分析。
在这个例子中，从时序报告中可以看出模块U3(REGCNT)和U2(UPC)可以进一步优化，也许能消除一些违规情况。
因为要纠正建立时序违规，所以要配置最差情况的运行条件。 pt_shell> set_operating_conditions -library pt_lib WCCOM pt_shell> characterize_context {U2 U3}
pt_shell> write_context U2 -output UPC.char.dcsh \\ -format dcsh
pt_shell> write_context U3 -output REGCNT.char.dcsh \\ -format dcsh
pt_shell> write_script -format ptsh -output AM2910.new.pt
% dc_shell
dc_shell> include optimize.dcsh ...
dc_shell> quit
pt_shell> read_db {REGCNT.opt.db UPC.opt.db} pt_shell> current_design AM2910
pt_shell> swap_cell U3 {REGCNT.opt.db:REGCNT} pt_shell> swap_cell U2 {UPC.opt.db:UPC} pt_shell> source AM2910.new.pt pt_shell> check_timing
pt_shell> report_constraint -all_violators
pt_shell> report_constraint -all_violators –verbose 看新生成的报告，违规情况是不是比原来少了？
高级分析 情形分析(Case Analysis)：
PrimeTime允许将设计中的端口设置成逻辑1或逻辑0，并使其像实际中那样生效，恰当地使时序弧有效或无效。这叫做情形分析(case analysis)或常量传播(constant propagation)。
情形分析能沿着电路正向地使所指定的逻辑常量生效，但是逆向不行。PrimeTime可以这样做是因为它知道门的逻辑功能。PrimeTime不能使逻辑常量通过RAMs或其他黑箱单元传播。黑箱单元是没有定义功能的单元。
可以使用标记时序模型有条件地定义被情形分析影响到的时序弧。使用情形分析，可以在不同的条件下进行时序分析，例如，测试模式的开或关。
PrimeTime自动使一直高或一直低的信号生效。如图所示使用情形分析时的常量传播。
如果将Sel端口设置成逻辑0，PrimeTime只跟踪INa到U3的路径； 如果将Sel端口设置成逻辑1，PrimeTime只跟踪INb到U3的路径；
如果将U2的B引脚设置成逻辑0，PrimeTime将不跟踪到U3/Ten的路径。 作为情形分析的范例，完成以下一些步骤：
1． 在设计中的一个端口上设置一个情形分析逻辑常量，观察时序弧受到的影响 pt_shell> set_case_analysis 0 [get_ports CONDITION_CODE] pt_shell> report_case_analysis pt_shell> report_disable_timing
report_disable_timing命令显示所有因为情形分析而无效的时序弧。 2． 看时序的改变
pt_shell> report_constraint pt_shell> report_timing 3． 检查报告
在这种情况下，将CONDITION_CODE端口设置成0改变了时序，所以关键路径也不一样了。
4． 将CONDITION_CODE设置成1，观察结果 5． 去除刚才所设置的逻辑常量
pt_shell> remove_case_analysis [get_ports CONDITION_CODE]