数字IC后端PPA优化| Timing一致性调整方法和Module Region规划方法

Q1:直播课经常讲到一致性,这个一致性的话一般是指place,CTS和PT的derating time,uncertainty和transition吗,我大概知道innovus的uncertainty设置要比PT里面高一点,但具体设计时这几部分的大小应该是一个什么样的关系或者需要大多少,这个有没有一些经验值?

我们一般讲的Correlation有Timing Correlation和Physical Correlation。

下面这张图是我之前分享的一个后端实现全流程思维导图,其中就把correlation按照Timing和Physical两个大方向进行划分(添加微信ic-backend2018免费领取这份思维导图)。

在这里插入图片描述
数字IC后端实现之Setup Violation修复案例(Data&Clock Tree ECO修复手段)

Timing Correlation又分PR实现不同阶段之间的时序一致性。

比如Placement做完setup wns是-0.1ns,长clock tree优化时序后setup wns是-0.25ns,这种就是典型的两个阶段之间的timing不一致!

那为何要追求一致性呢?因为长clock tree后的timing比较差,而这个情况在placement阶段工具压根没看到,那自然就不会做优化,即placement优化不到位。

我们最理解的结果是placement做完,CTS做完clock tree后timing情况就应根据接近于placement后的结果。

这两个步骤的差别是placement阶段clock还是ideal的(时钟从root到sink的时间为0),而CTS做完各个sink的到达时间是不一致的,所以它们差一个clock skew!

手把手教你如何分析debug Clock Skew高达上ns的案例

那我们是否可以在placement阶段提前把后续CTS阶段的clock skew考虑进来呢?答案是可以的。

在这里插入图片描述

我们在placement阶段可以设置一个更大点的clock uncertainty。

这个也就是咱们经常看到的placement clock uncertainty = Clock Jitter +预估clock skew +Timing Margin。

我们应该尽量让工具在placement阶段就把标准单元摆放到最佳的位置上,并把时序一步优化到位。后续其他阶段仅仅是针对实际clock skew和实际走线带来的一些时序变化进行的时序优化。这个优化过程可以比较轻松实现。

这样实现出来的结果我们可以把PR每个阶段的density控制在一个数量级!

PR是基于逻辑连接的物理实现的过程,它里面用的delay计算engine和RC抽取engine肯定和Starrc,PT是不一样的。所以PR和PT之间的一致性也是我们需要关注的。

而我们知道delay就分两种,分别是cell delay和net delay。

在这里插入图片描述

所以这两个阶段的timing一致性可以在PR阶段通过以下几个方法来调整(PT中对应值是不能改的)。

1)调整clock uncertainty

2)调整考虑OCV设置的set_timing_derate值

3)调整RC Scale Factor系数

而physical一致性主要指两边的routing drc结果是否比较接近。

IC后端项目案例 | Innovus DRC Violation分析及Floorplan合理性分析

Q2: Place阶段有时候出现critical path不在dpu里面需要设置region,想请问这个region是针对什么设置的,我不知道里面应该放什么。因为我想直接在place阶段就设置好region,如果这样可以的话在core的不同部位这个region里面应该摆什么?比如说给一个dpu设一个region它应该放在core的哪一个部位?

Region一般是针对某个module来设置的。以咱们T28 a7core直播课讲的这个案例为例,u_ca7pfu这个module工具自动摆放后被拆成两部分。这时候我们可以把这个module做成一个region,规划在中间那个位置。 DPU模块一般是位于远离io port那个对角位置,靠近DDATA SRAM。

在这里插入图片描述

添加region的的脚本命令如下所示。

set cells [dbGet top.insts.name u_cortexa7noram/u_ca7pfu* -p]
set cells_name [dbGet $cells.name]
createInstGroup PFU
addInstToInstGroup PFU $cells_name
createRegion PFU {300 300 500 600}

我们还可以根据设计的data flow和官方推荐的module分布来精细化规划每个module的摆放位置。

ARM Cortexa7core 模块分布图

数字IC设计实现之分段长clock tree典型案例(clock tree synthesis)
在这里插入图片描述

<think>嗯,用户询问的是数字后端设计中的两种优化技术:retime优化optimize_register优化。用户是芯片设计工程师,可能正在处理时序问题或功耗优化,需要明确两者的区别应用场景。从专业术语的使用来看,用户应该具备一定数字设计基础。 首先需要区分这两个概念的本质。retime是时序驱动的寄存器重定位技术,核心思想是在保持功能不变的前提下移动寄存器位置来平衡关键路径。而optimize_register更偏向寄存器级优化,可能涉及面积、功耗时序的综合权衡。 关于retime的具体实现,要强调其数学基础是重定时变换理论,通过调整组合逻辑与寄存器的边界点来优化时序。这里需要补充说明:retime不改变寄存器数量,但可能改变寄存器位置,这点pipeline优化不同。 对于optimize_register,需要说明它通常包含多种技术:寄存器合并/复制、时钟门控插入、低功耗单元替换等。特别要指出在物理实现阶段,它与布局布线工具的交互关系——比如在InnovusICC2中如何调用相关命令。 用户可能隐含的需求是:面对具体设计问题时如何选择策略。这里需要构建对比维度:时序收敛阶段首选retime,功耗敏感场景则侧重optimize_register。可以举例说明:当关键路径集中在某模块时,retime效果显著;而寄存器数量庞大的设计,optimize_register的功耗收益更大。 注意到用户提到“使用方法”,应该补充工具层面的实践建议:在DC中retime用optimize_registers -retime,ICC2用psynopt -retime;optimize_register则涉及set_clock_gating_style等综合约束。需要提醒注意工具版本差异,比如PrimeTimePX对retime的时序验证要求。 最后考虑设计案例说明:假设某SoC的DSP模块遭遇350ps关键路径,通过retime将寄存器插入乘法器内部后降至240ps;而存储器接口的2000个寄存器经clock gating优化后动态功耗降低18%。这样能直观展示技术价值。 安全方面需注意:所有技术细节都应基于公开的EDA手册内容,不泄露具体工艺参数。</think>在数字后端设计中,**Retime优化****Optimize Register优化**是解决时序功耗问题的关键技术,以下是核心原理及实践指南: --- ### **一、Retime优化原理与应用** #### **1. 核心原理** - **数学本质**:基于重定时理论(Retiming Theory),通过调整寄存器在组合逻辑中的位置优化时序路径 $$ T_{new} = T_{old} - \Delta d \quad (\Delta d为路径延迟变化量) $$ - **关键操作**: - 将寄存器**跨越组合逻辑块移动**(前移/后移) - 保持电路功能不变(不改变寄存器数量) - 优化关键路径:缩短最长组合逻辑延迟 $ \max(d_c) $ #### **2. 应用场景** - **时序收敛困难**:当关键路径延迟超过时钟周期时 ```tcl # Synopsys DC示例命令 set_optimize_registers_options -move_delay -allow_retime ``` - **流水线优化**:在算术逻辑(如乘法器)中插入寄存器平衡级间延迟 - **物理约束下优化**:结合布局布线工具(如ICC2/Innovus)实现位置感知的retime[^1] --- ### **二、Optimize Register优化原理与应用** #### **1. 核心原理** - **目标多维优化**: $$ \min (Area + \alpha \cdot Power + \beta \cdot Timing) $$ - **关键技术**: | 技术 | 作用 | 影响 | |---------------------|-------------------------------|--------------| | 寄存器合并 | 减少冗余FF数量 | 面积↓ 功耗↓ | | 寄存器复制 | 拆分高扇出寄存器 | 时序| | 时钟门控插入 | 增加使能信号控制 | 动态功耗↓ | | 低功耗单元替换 | 用高阈值/长沟道单元替代 | 漏电功耗↓ | #### **2. 应用场景** - **功耗敏感设计**:对活跃度低的寄存器插入ICG(Integrated Clock Gating) ```tcl # Power Compiler命令 set_clock_gating_style -min_bitwidth 4 compile -gate_clock ``` - **物理拥塞缓解**:通过寄存器复制降低局部绕线密度 - **信号完整性优化**:拆分高扇出网络减少串扰风险 --- ### **三、关键区别与使用策略** | **维度** | **Retime优化** | **Optimize Register优化** | |------------------|-------------------------------|-------------------------------| | **优化目标** | 时序主导 | 时序/面积/功耗协同优化 | | **寄存器数量** | 保持不变 | 可能增减(合并/复制) | | **工具阶段** | 综合/物理实现均可 | 主要在逻辑综合阶段 | | **典型命令** | `optimize_registers -retime` | `optimize_registers -merge -split` | | **风险控制** | 需验证组合逻辑毛刺 | 需避免过度复制导致面积膨胀 | --- ### **四、实践建议** 1. **Retime使用流程**: - 预布局阶段:运行快速retime预估时序收益 - 布局后阶段:结合物理位置约束执行精确retime - 签核验证:检查移动后寄存器的建立/保持时间 2. **Optimize Register策略**: ```tcl # 分步优化示例(Synopsys Flow) compile -inc # 初始综合 optimize_registers -merge -clock_gating # 合并与门控 optimize_registers -split -max_fanout 16 # 高扇出拆分 report_power -clock_gating # 验证功耗收益 ``` 3. **协同优化场景**: - 先执行retime解决关键路径 - 再通过register优化降低功耗 - 最后进行物理感知的精细化调整[^2] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值