- 主题:一个cycle内信号跳变多次导致power太大
做一个项目
发现power分析出来结果比预想的大好多
后来看带sdf反标的仿真波形,发现问题是这样:
一个周期的datapath比较长,所以周期也很长
在这个周期内,大多数信号都反复翻转好多次
这样就导致计算power时比我们本来认为的每个周期只翻转一次的行为要大很多
原因:同一个cell来自不同的path的latency不一样,所以同一个cell在信号稳定下来之前,会翻转好多次
解决方案:针对所有的path,set_min_delay为一个周期的长度。
这样所有path的latency都会做到和最长的那条差不多,这样可以降低同一个cell来自不同path latency的差别的大小,从而降低反复翻转的概率
请大牛们给点建议,还有其他更专业的方法吗?
- 来自「最水木 for iPhone14,3」
※ 修改:·Xaoyao 于 Oct 17 00:08:43 2021 修改本文·[FROM: 220.196.194.*]
※ 来源:·最水木 客户端·[FROM: 220.196.194.*]
修改:Xaoyao FROM 220.196.194.*
FROM 220.196.194.*
最大和最小delay都设为1个周期
这样不是所有path都等长了嘛
【 在 awuwu 的大作中提到: 】
: min delay一个周期,你这条是multicycle吗
: 【 在 Xaoyao 的大作中提到: 】
: : 做一个项目
: ....................
- 来自「最水木 for iPhone14,3」
--
FROM 220.196.192.*
有什么问题吗
【 在 awuwu 的大作中提到: 】
: 你对timing是这么理解的吗
: 你这个是不可能满足的约束
: 【 在 Xaoyao 的大作中提到: 】
: ....................
- 来自「最水木 for iPhone14,3」
--
FROM 101.87.109.*
具体说一下?
【 在 androidIOT 的大作中提到: 】
: 他对微观timing有误解。
:
: 【 在 awuwu 的大作中提到: 】
: ....................
- 来自「最水木 for iPhone14,3」
--
FROM 220.196.194.*
具体说一下?
【 在 StrongLeg 的大作中提到: 】
: 听到“等长”、“对齐”这种说法,说明对STA有误解
:
: 【 在 Xaoyao 的大作中提到: 】
: ....................
- 来自「最水木 for iPhone14,3」
--
FROM 220.196.194.*
slight offset是什么意思?
实际min delay会设为一个周期的90%
不会完全和周期一样
【 在 androidIOT 的大作中提到: 】
: 你的min-set和max-set“一个周期”是绝对的一个周期,还是其中一个带slight offset? 如果是绝对的同一个周期,那这个约束条件本身不成立。
:
:
: ....................
- 来自「最水木 for iPhone14,3」
--
FROM 220.196.192.*
现在我就在这样尝试
datapath越长,这个问题就越严重
所以缩短长度是最直接的方法
【 在 eefaquir 的大作中提到: 】
: 感觉很难处理,加入DFF把路径分割下试试?
: 但是这样又引入了DFF的功耗
:
: ....................
- 来自「最水木 for iPhone14,3」
--
FROM 101.87.109.*
一个周期有100级cell
一个周期的datapath是由多个一样的模块(假设称为A)串连多次形成的
现在我单独把这个模块A(纯组合逻辑)单独做综合和PR
最终再把A拼起来
这样可以比较精确的控制它的latency平衡
但DC是不能修min_delay的
所以在ICC里面修min_delay
请教ICC哪个命令是修hold的?
我没搞过后端
只知道place_opt
然后clock_opt -fix_hold
但模块A没有clock,只设了min_delay
所以clock_opt -fix_hold不起作用
【 在 androidIOT 的大作中提到: 】
: 所以你这一个周期具体是多少?如果太大加DFF效果也不会太好,太小的话之前那10% offset约束条件难满足
:
:
: ....................
- 来自「最水木 for iPhone14,3」
--
FROM 101.87.109.*
谢谢,你的思路我大概明白
请问为什么一定有path满足不了呢?
另外你说的手工插入buffer
是插在具体哪个位置?
肯定要插在不影响setup的地方
这个具体分析每一条path了吧?
【 在 shhier 的大作中提到: 】
: 先做一轮set_min_delay/set_max_delay来constrain。但一定有paths满足不了。
: 写一个脚本,report_timing到每个flop的end point,计算得到最大最小path的timing offset。
: 然后对于offset比较大的paths,手动插入don't touch的buffer来balance timing。
- 来自「最水木 for iPhone14,3」
--
FROM 101.87.109.*