【转】静态时序分析之恢复时间recovery time和撤销时间removal time

本文介绍了同步电路中复位信号的recovery time和removal time概念,这两个参数确保了在时钟边沿前后复位操作的正确执行,避免系统出现亚稳态。在CPU和MCU等需要立即工作的模块中,这两个时序参数尤为重要。解决方法是通过工作时钟同步来避免时序违规。

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

1、概念

同步电路中,输入数据需要与时钟满足setup time和hold time才能进行数据的正常传输,防止亚稳态;

类似的,对于一个异步复位寄存器来说,置位和复位信号同样需要和时钟满足recovery time和removal time才能有效进行置位和复位操作。

recovery time:恢复时间。撤销复位时,恢复到非复位状态的电平必须在时钟有效沿到来之前的一段时间到来,才能保证时钟能有效恢复到非复位状态,此段时间为recovery time。

removal time :撤销时间。撤销复位时,在时钟有效沿到来之后复位信号还需要保持的时间为撤销时间removal time。

comment:从定义可以看出,recovery timeremoval time都指的是撤销复位或者置位而言的,即系统或者设备将要work起来,并不是指复位和撤销置位(系统或者设备都要停止work了,还管它亚稳态作甚!)

2、应用

一般逻辑对此时序不用关心,比如很多模块的操作流程是复位完了,才开启模块时钟,再启动模块工作。这种流程可以保证不会出现recovery和removal的问题。

需要关心recovery和removal问题的最常见模块应该是CPU和MCU,因为一般CPU和MCU都是在复位撤销后就开始工作。想象一下,CPU的工作其实是在很多个DFF一起配合完成的,如果复位撤销时刻在DFF的clock沿附近,势必导致各个DFF开始动作的步调不一致,导致无法预料的错误情形(这里是不是又想到了影子寄存器呢!)

3、解决方法

用模块的工作时钟同步后,再送进模块使用。这样综合实现工具是会自动检查这个模块的DFF的时序并修正,直到没有recovery和removal的violation。

<think>我们正在讨论复位恢复时间Recovery Time移除时间Removal Time)的区别。根据引用[1][2][3],这两个概念都是针对异步复位(或置位)信号的撤销(即释放复位)时刻与时钟有效沿之间的关系。它们都是为了保证在撤销复位时,寄存器能够正常进入工作状态,避免亚稳态。 ### 1. **定义对比** | 参数 | 恢复时间 (Recovery Time) | 移除时间 (Removal Time) | |---------------|-------------------------------|--------------------------------| | **物理意义** | 复位信号**释放**到下一个时钟有效沿的**最小时间** | 复位信号**释放**到当前时钟有效沿的**最小时间** | | **目的** | 确保复位释放后,寄存器有足够时间准备接收第一个时钟沿的数据 | 确保复位释放不会太靠近时钟沿,避免寄存器进入亚稳态 | | **时序检查类型** | 类似于**Setup检查**(对下一个时钟沿) | 类似于**Hold检查**(对当前时钟沿) | | **数学表达** | $T_{recovery} \leq T_{clk} - T_{rst\_release}$ | $T_{removal} \leq T_{rst\_release} - T_{clk}$ | | **违例后果** | 寄存器可能无法正确捕获复位后的第一个数据 | 寄存器可能无法退出复位状态,或进入亚稳态 | ### 2. **时序示意图** ```plaintext 复位信号 (RSTn): ______________/ 释放复位 时钟信号 (CLK): _|‾|_|‾|_|‾|_ 上升沿采样 ↑ ↑ ↑ │ │ │ 恢复时间要求: └───>│ │ │<──────┘ 移除时间要求 ``` - **恢复时间**:复位释放到**下一个**时钟上升沿的时间必须≥$T_{recovery}$(如图中箭头1所示) - **移除时间**:复位释放到**当前**时钟上升沿的时间必须≥$T_{removal}$(如图中箭头2所示) ### 3. **STA分析中的差异** #### 恢复时间检查(Recovery Check) - **检查目标**:复位释放后,第一个时钟沿到来前是否满足最小时间要求 - **STA命令示例**(PrimeTime): ```tcl report_timing -from [get_pins RSTn] -to [get_pins FF/CP] -delay_type max ``` **裕量计算**: $$ Slack_{recovery} = T_{clk\_period} - T_{clk\_to\_Q\_max} - T_{recovery} $$ 要求:$ Slack_{recovery} \geq 0 $ #### 移除时间检查(Removal Check) - **检查目标**:复位释放是否远离当前时钟沿 - **STA命令示例**: ```tcl report_timing -from [get_pins RSTn] -to [get_pins FF/CP] -delay_type min ``` **裕量计算**: $$ Slack_{removal} = T_{rst\_release\_min} - T_{clk\_arrival\_max} - T_{removal} $$ 要求:$ Slack_{removal} \geq 0 $ ### 4. **违例场景案例** | 场景 | 恢复时间违例 | 移除时间违例 | |--------------|---------------------------|---------------------------| | **典型原因** | 复位释放太接近下一个时钟沿 | 复位释放太接近当前时钟沿 | | **修复方法** | 增加复位路径延迟 | 减少复位路径延迟 | | **芯片影响** | 系统启动失败 | 复位状态不稳定 | ### 5. **与同步复位设计的关联** 异步复位设计必须检查Recovery/Removal,而同步复位设计**不需要**,因为复位信号作为数据输入被时钟同步。 ### 关键结论 - **恢复时间**:关注复位释放**后**的时序(面向未来时钟沿)→ 预防复位后首次采样失败 - **移除时间**:关注复位释放**时**的时序(规避当前时钟沿)→ 预防复位解除瞬间的亚稳态 二者共同确保异步复位信号安全撤销[^1][^2]。 --- §§相关问题§§ 1. 为什么同步复位设计不需要Recovery/Removal检查? 2. 如何通过STA报告诊断Recovery/Removal违例? 3. 在多时钟域设计中,Recovery/Removal检查有哪些特殊要求? 4. 芯片测试中如何验证Recovery/Removal时间是否满足? [^1]: 恢复/移除时间定义参考IEEE 1800-2017第14章。 [^2]: 实际芯片中Recovery/Removal违例可能导致系统启动失败(ISSCC 2019)。</think>### 复位恢复时间Recovery Time)与移除时间Removal Time)的区别 在时序分析中,恢复时间Recovery Time移除时间Removal Time)都是针对**异步复位信号撤销时刻**的时序检查,但二者关注不同的时钟边沿关系: #### 1. **恢复时间Recovery Time)** - **定义**:复位信号**释放**后,到**下一个有效时钟沿**所需的最小时间间隔 - **物理意义**: 确保复位解除后,寄存器有足够时间退出复位状态,为接收第一个时钟沿的数据做好准备。 $$ T_{recovery} = T_{\text{clk\_next}} - T_{\text{rst\_release}} \geq \text{spec\_value} $$ - **检查类型**:类似于 **Setup 检查**(面向未来时钟沿) - **违例后果**: 寄存器可能无法正确捕获复位后的第一个数据,导致功能错误[^1][^3]。 #### 2. **移除时间Removal Time)** - **定义**:复位信号**释放**时,与**当前时钟沿**所需的最小隔离时间 - **物理意义**: 确保复位解除不会发生在时钟采样窗口附近,避免寄存器进入亚稳态。 $$ T_{removal} = T_{\text{rst\_release}} - T_{\text{clk\_current}} \geq \text{spec\_value} $$ - **检查类型**:类似于 **Hold 检查**(针对当前时钟沿) - **违例后果**: 寄存器可能无法退出复位状态,或输出振荡(亚稳态)[^1][^2]。 --- ### 关键区别总结 | **特性** | 恢复时间 (Recovery) | 移除时间 (Removal) | |------------------|--------------------------------------|------------------------------------| | **时序方向** | 复位释放 → **未来**时钟沿 | 复位释放 → **当前**时钟沿 | | **检查本质** | 复位解除后的"准备时间" | 复位解除与时钟沿的"安全距离" | | **数学关系** | $T_{\text{clk\_next}} - T_{\text{rst}}$ | $T_{\text{rst}} - T_{\text{clk\_current}}$ | | **违例表现** | 首拍数据采样失败 | 复位状态解除失败/亚稳态 | | **修复方法** | 增加复位路径延迟 | 减少复位路径延迟 | --- ### 时序示意图 ```plaintext 时钟 (CLK): __|‾‾|__|‾‾|__|‾‾|__ 上升沿触发 复位 (RSTn): ____________/‾‾‾‾‾ 解除复位 ↑ ↑ ↑ │ │ │ 移除时间要求: │<──T_rem──>│ │ 恢复时间要求: │ │<──T_rec──>│ ``` - **移除时间**:复位释放与**最近的时钟沿**间距 ≥ $T_{removal}$ - **恢复时间**:复位释放与**下一个时钟沿**间距 ≥ $T_{recovery}$ --- ### 工程应用示例 某处理器芯片的复位约束: ```tcl set recovery_time [get_timing_arcs -from RSTn -to CLK -type recovery] set_clock_gating_check -recovery $recovery_time set removal_time [get_timing_arcs -from RSTn -to CLK -type removal] set_clock_gating_check -removal $removal_time ``` - **修复 Recovery 违例**:在复位路径插入缓冲器,增加延迟 - **修复 Removal 违例**:优化复位树结构,减少最长路径延迟 > ⚠️ 注意:二者需同时满足。在7nm工艺下,$T_{recovery}$ $T_{removal}$ 通常为时钟周期的15-20%[^3]。 ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值