静态时序分析——On-chip Variation

本文深入探讨了OCV(on-chip variation)在芯片设计中的影响,特别是在时序分析过程中的角色。通过调整derate系数,文章展示了如何在STA中模拟OCV效应,以及它如何改变电路的最小时钟周期。此外,还介绍了CPPR(Clock Path Pessimism Removal)技术,用以消除共同时钟路径的过度悲观预测,进一步优化时序分析。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

OCV(on-chip variation)是指在同一个芯片上, 由于制造工艺和环境等原因导致芯片上各部分特征不能完全一样,从而造成偏差,对时序分析造成影响。这些偏差对互联线和cell的延时都是有影响的。

由于OCV对延时有影响,那么我们在进行时序分析时需要将这些OCV效应考虑进来。在STA中,通过对不同的时序路径添加derate系数,来完成对OCV的建模,将OCV效应纳入分析。

我们以下图电路为例进行说明:

进行setup check时,最差的情况为:launch clock path 和data path由于OCV的原因,延迟增加到最大;于此同时,capture clock path 由于OCV的原因,延迟减小到最小。此时,对建立时间的检查最为严苛。

如过我们不考虑OCV的影响,进行setup check,则情况如下:

arrival time = 1.2+0.8+5.2=7.2ns

required time = 1.2+0.86-0.35+clock_period=1.71+clock_period

那么由于required time-arrival time>=0则clock_period>=5.49,即最小时钟周期为5.49ns。

接下来我们将OCV纳入考虑,为路径和cell设置不同的derate系数。

我们可以通过set_timing_derate来设置derate系数

set_timing_derate -early 0.9
set_timing_derate -late 0.9
set_timing_derate -cell_delay -late 0.9
set_timing_derate -net_delay -late 0.9

长路径延时如setup check 中的launch clock path和data path,hold check中的capture clock path可以使用-late选项来设置

短路径延时如setup check 中的capture clock path,hold check中的launch clock path和data path可以使用-early选项来设置

使用-net_delay和-cell_delay来设置线网和cell的延时

为launch clock path和max data path增加系数1.2,为UFF1增加系数1.1,为capture clock path 增加系数0.9,这样,我们再看看setup check:

arrival time = (1.2+0.8+5.2)*1.2=8.64ns

required time = (1.2+0.86)*0.9-0.35*1.1+clock_period=1.469+clock_period

那么由于required time-arrival time>=0则clock_period>=7.171,即最小时钟周期为7.171ns。可以看到,在加入最差情况的OCV后,电路能运行的时钟频率明显下降了。

        但是在上面的计算中,我们还是可以发现一个问题,即common clock path即属于launch clock path,也属于capture clock path,所以在计算中,我们对其使用了不同的derate系数进行计算:在计算arrival time中,系数为1.2;在计算required time中,系数为0.9,这样会让我们的分析更为悲观,电路性能更差。而在真实的情况中,common clock path的PVT只有一个,不可能同时有两个derate系数,所以我们会进行CPPR操作。

CPPR(Clock Path Pessimism Removal)或者CRPR(Clock Reconvergence Pessimism Removal),中文名“共同路径悲观去除”。它的作用是去除clock path上的相同路径上的悲观计算量,即我们上面提到的问题。我们将common point定义为时钟树上共同部分最后一个cell的output pin。则定义CPP因子为:

CPP=LatestArrivalTime@CommonPoint-EarliestArrivalTime@CommonPoint

我们进行CPPR后再来进行一次计算:

LatestArrivalTime@CommonPoint=1.2*1.2=1.44ns

EarliestArrivalTime@CommonPoint=1.2*0.9=1.08ns

CPP=1.44-1.08=0.36ns

则clock_period=7.171-0.36=6.811ns

可以看到,电路的运行时钟频率变好了一点,但对于未考虑OCV来说,整个运行时钟频率还是降低了。

我们可以来看看时序报告

      

 

说完setup check,我们来看看OCV对hold check的影响。

进行hold check时,最差的情况为:launch clock path 和data path由于OCV的原因,延迟减小到最小;于此同时,capture clock path 由于OCV的原因,延迟增加到最大。此时,对保持时间的检查最为严苛。我们进行同样的分析,可以看到基本相同的结果。

其时序报告如下:

   

参考资源链接:[PrimeTime静态时序分析与Formality形式验证实战指南](https://wenku.csdn.net/doc/8677z69m93?utm_source=wenku_answer2doc_content) 在数字集成电路设计中,静态时序分析和形式验证是确保电路性能的关键步骤。首先,使用PrimeTime进行静态时序分析的步骤大致包括:1. 准备工作,包括编译时序模型、设置查找和链接路径、读入设计文件等;2. 编译设计,确保所有必要的设计信息被加载;3. 设置时序约束,例如定义时钟参数、时钟-门校验等;4. 执行时序分析,包括基础分析和报告生成;5. 根据报告结果进行优化。在PrimeTime中,可以使用Tcl脚本来自动化这些步骤。例如,以下是一个简单的Tcl脚本示例,用于执行基本的时序分析: ```tcl pt_shell> read设计文件名 pt_shell> set_operating_conditions -max -analysis_type on chip variation pt_shell> create_clock -period 10.0 [get_ports clk] pt_shell> report_checks -transition_time -max_paths 10 -max_slack 0.1 -sort_by group ``` 接下来,使用Formality进行形式验证的过程包括:1. 设置形式验证环境,指定参考设计和目标设计;2. 运行比较命令,确认设计的一致性;3. 分析不一致的地方,并进行必要的修改;4. 进行验证,直到设计满足一致性要求。使用fm_shell编写Tcl脚本进行形式验证的示例可能如下: ```tcl fm_shell> read_sdf 延迟文件名 fm_shell> read_reference 设计文件名 fm_shell> read_current 设计文件名 fm_shell> compare fm_shell> report_inconsistency ``` 以上示例展示了如何使用Tcl脚本与PrimeTime和Formality工具进行交互,执行时序分析和形式验证的关键步骤。对于那些希望进一步提升时序分析和形式验证能力的设计者来说,推荐阅读《PrimeTime静态时序分析与Formality形式验证实战指南》一书,它将为读者提供更深入的理论知识和实战技巧。 参考资源链接:[PrimeTime静态时序分析与Formality形式验证实战指南](https://wenku.csdn.net/doc/8677z69m93?utm_source=wenku_answer2doc_content)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

沧海一升

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值