<DC guide ---6>

前面说了怎么 get_*  ,下面就是怎么把 约束加载到指定位置上。

Specifying an Area Constraint

set_area_max   245000

把最大面积约束,自动的施加在current_design上。  一般xxxx的单位,有可能是与非门的个数或者是晶体管数目、或者是mm2、 um2等概念、

这个要看具体的工艺库.DC没有信息能反馈单位,

Specifying Setup-Timing Constraints

我和JANE、JOE一起合作一个项目,我负责中间的那一块电路。理论上像上图一样。 该怎么约束?约束什么?

我们知道了寄存器自己本身有setup_time、holdtime ,即D要提前时钟一些,提前稳定好。 时钟上升沿之后,D应该保持稳定一段,以便正确打入寄存器。

对于我们的小模块来说,都假设从0时刻开始.  假设时钟是100M , 输入信号经过组合逻辑N, 耗时了t1,那么应该保证 t1< 10ns -setup 。即D提前一段时间稳定。

两个寄存器之间的组合逻辑x最大是多少?

假设时钟是100M, 而组合逻辑是 15ns, 当FF2输出一个信号, 需要经过15ns才传回D_FF3, 显然FF3会抓到一个中间状态,这个状态有正在跳转,这个即使综合器也无法

确保,在中间状态维持一段时间稳定.  因此,要把这个组合逻辑x约束在一个Period内.

两个寄存器之间的组合逻辑x最小是多少?

实际应用中,我们经常会中间没有组合逻辑.那为什么要提这个概念呢?

对于两个寄存器来说,在同一节拍, FF2的数据输出,如果马上跳变了,会不会恰好发生在FF3的hold_time时间内呢?如果发生了,显然会引起亚稳态.

所以说: FF2的单bit数据,跳变后,经过一个组合逻辑x, 安全度过FF3的hold_time之后,才最终完成组合逻辑x。这样就能保证FF3的hold_time了。

下面是一个我用与非门答的 寄存器电路,仿真了下 关于setup\hold期间跳变的现象。

未满足setup的情况:

未满足hold的情况:

可以看出,q输出端确实会有震荡的现象。这也是我们为什么要关心这个setup/hold的原因。

怎么才能告诉DC,我所允许组合逻辑x的最大最小值? 我如果是直接告诉DC.那么是不是所有路径都得告诉DC才能?

显然是太啰嗦的,我们只需要告诉DC 时钟的周期.DC自己就能算出来,(工艺库DFF的setup/hold时间固定),

create_clock

Creat_clock –name xxx   -period  20   –waveform  { rise nege}   [get_* ]

先get_*获得某个pin、prot,然后起名xxx,定义它的周期是20,-waveform决定了时钟的相位。 -add选项后面再讲。

当然了这是一个理想的时钟, 绝对的周期,绝对的占空比. 但在现实中是不存在的, 所以我们要尽量的描述的和现实中的一样.

(1) 时钟占空比40%,很难精确.  (2) 时钟信号从0-1-0的跳变不是瞬时完成的,有一个过程。

(3) 时钟到达DFF2和DFF3的时间,有可能受到布线长度等影响,不是严格对齐的。

(4) 时钟存在jilter,比如时钟的上升沿,时而超前、时而滞后的偏移称为时钟抖动

怎么样,把这几个方面也考虑进去,才能说 大致构造一个真实的时钟模型.

Set_clock_uncertainty:   时钟的uncertainty = skew +jitter

时钟skew是表示: 时钟到达每个寄存器的时刻不是严格对齐的,受到布局布线影响,所以我们需要提前把这些因素考虑进来。

时钟Jitter是表示 :  由于物理热运动,时钟的沿跳沿,会时而提前时而滞后的自然现象。

Clock_uncertainty主要考虑的是skew,顺带着把jitter加进来。

仔细看语法:

-rise –fall选项已经废弃了。

-setup :  是说该uncertainty值只用在setup时序分析上。

-hold :   是说该 uncertainty值只用在hold时序分析上。       (后面会说 uncertainty的值到底会怎么影响 setup\hold分析)

上面的例子,就是说:在分析CLK路径 的setup时候,需要考虑unvertainty = 0.65

在分析CLK路径 的hold时候,此时unvertainty = 0.45

-from   CLK1     -to/-rise_to/-fall_to   CLK2

-rise_from   CLK1     -to/-rise_to/-fall_to   CLK2

-fall_from   CLK1     -to/-rise_to/-fall_to   CLK2    还没弄清楚具体什么意思。后面用到了再学习。慢慢来

看一下设置之后的效果:

时钟是2ns,在分析setup时候,因为设置clock_uncertainty setup = 0.14 。即上升沿有可能提前或滞后0.14ns。

如果是滞后0.14,相当于 放松了约束。如果是提前0.14,那么组合逻辑x的最大延迟就变相严谨了。

DC要保证所有情况,故只会考虑提前0.14ns的情况。 2-0.14-0.08-delay(FF1) = max( x )

故而对组合逻辑x的约束更加严厉了。这符合我们的预期目的。

set_clock_latency

时钟从晶体出来,到CLK_Port,耗时称为source_latency.

从CLK_port,再到寄存器,耗时称为 network_latency.

这两个值,都通过set_clock_latency

感觉这个值,对于MY_DESIGN内的综合,没有起到约束作用。但是呢或许是模块键的组合逻辑会有帮助。

set_clock_transition

时钟从来都是,瞬间完成跳变的。当时钟电压值,达到80%时,认识CLK为高。所以综合时,需呀把这个因素考虑进去。

一般可以用set_clock_transition设置最大最小值。比如DFF2最慢变,DFF3最快变,这样setup就又严谨了一丢丢。

通过这几个命令: 我们把理想的idea clock变成了较为真实的时钟。

继续回到MY_DESIGN上:

我们通过creat_clock以及配置波动参数,能够让DC明白,组合逻辑X的最大最小延迟。那对于组合逻辑N,能使用一样的约束吗?

我们通过补全,JANE’s DESIGN,可以把M+N看作一个整体,这样就跟组合逻辑X一样了。但是现实中,我们经常只综合自己的模块,并不知道

组合逻辑M。怎么能虚构一个信息,让它替代FF1_cell + M的时间 ?

set_input_delay :

指定 port_pin,相对于某个信号、某个时钟,延迟多久。

我们一般用:

Set_input_delay    -max 0.6 –clock  [get_clock*]    [get_input *]

set_OUT_delay :

需要理清楚一点:  set_output_delay:  是模拟 JOE模块的。

因为我们告诉DC所有的信息,都是为了让他能计算出组合逻辑S的范围。

set_output_delay 值是  =  端口B---到FF4的时间。

比如 set_output_delay 4 ,意味着  组合逻辑只有 6ns的延迟上限。

为了方便JOE综合她的模块,我们需要提供我们的组合逻辑S的延迟信息。

其实这也是,为什么很多代码风格,要求输出信号全部都是寄存器输出的原因。环境独立,不受其他的模块影响。

纯组合逻辑约束

讨论下这种情况,约束组合逻辑F的时候,需要考虑B的输入delay时间。需要告诉JOE关于D的输出delay

从图上,可以看到寄存器时刻----到输入口B,总共耗时0.4ns。

FF4需要至少提前0.3ns,才能确保setu. 所以组合逻辑的最大延迟为 2-0.4-0.3 = 1.3ns

再考虑一种情况:

这个时候,MY_DESIGN是纯组合电路。我们的set_input_delay、set_output_delay都是相对于时钟上升沿时刻来说的。

这个时候没有时钟做参考怎么办 ?

我们可以自己虚拟一个跟CLK一样的时钟。  creat_clock -name my_clk -period 2 .剩下的事给之前一样处理。

综合以上,如果我们知道input_delay的时间,我们就能够约束 DFF之间的组合逻辑、input----DFF的组合逻辑、DFF--output的组合逻辑、Input---Output的组合逻辑。

这也是我们为什么能够把时序路径划分成  start_point(input\DFF_clk)到endpoint(output\DFF_in)的原因。

假如我们不知道JANE‘的输出延迟信息。我们的input---DFF、Input----Output的组合逻辑块就没有办法保证了。

这种情况下:我们可以去直接问JANE、或者我们进行一个预估。预估的原则是什么?

假设: 三个设计,都做一样的约束处理:  设置set_output_delay   60% of  clk 。那么留给我们组合逻辑S的只有40%时间上限了。

同时 set_input_delay 60% of clk ,对于我们的组合逻辑N而言,只有40%的最大上限。

如果三个模块都这样设计:  第一个的?组合逻辑,只有40%的上限,我们的N也只有40的上限,这样就能确保有20%的冗余时间足够保证设计可靠性。

这个原则适用于所有的 小模块的综合。

现在我们可以说:我们基本能能够约束 DFF之间的组合逻辑、input----DFF的组合逻辑、DFF--output的组合逻辑、Input---Output的组合逻辑。

这也是我们为什么能够把时序路径划分成  start_point(input\DFF_clk)到endpoint(output\DFF_in)的原因。

组合逻辑N、X、S,以及纯组合逻辑Y都能有效的进行约束了。

时间: 2024-10-03 14:45:27

<DC guide ---6>的相关文章

CI框架源码阅读笔记3 全局函数Common.php

从本篇开始,将深入CI框架的内部,一步步去探索这个框架的实现.结构和设计. Common.php文件定义了一系列的全局函数(一般来说,全局函数具有最高的加载优先权,因此大多数的框架中BootStrap引导文件都会最先引入全局函数,以便于之后的处理工作). 打开Common.php中,第一行代码就非常诡异: if ( ! defined('BASEPATH')) exit('No direct script access allowed'); 上一篇(CI框架源码阅读笔记2 一切的入口 index

IOS测试框架之:athrun的InstrumentDriver源码阅读笔记

athrun的InstrumentDriver源码阅读笔记 作者:唯一 athrun是淘宝的开源测试项目,InstrumentDriver是ios端的实现,之前在公司项目中用过这个框架,没有深入了解,现在回来记录下. 官方介绍:http://code.taobao.org/p/athrun/wiki/instrumentDriver/ 优点:这个框架是对UIAutomation的java实现,在代码提示.用例维护方面比UIAutomation强多了,借junit4的光,我们可以通过junit4的

Yii源码阅读笔记 - 日志组件

?使用 Yii框架为开发者提供两个静态方法进行日志记录: Yii::log($message, $level, $category);Yii::trace($message, $category); 两者的区别在于后者依赖于应用开启调试模式,即定义常量YII_DEBUG: defined('YII_DEBUG') or define('YII_DEBUG', true); Yii::log方法的调用需要指定message的level和category.category是格式为“xxx.yyy.z

源码阅读笔记 - 1 MSVC2015中的std::sort

大约寒假开始的时候我就已经把std::sort的源码阅读完毕并理解其中的做法了,到了寒假结尾,姑且把它写出来 这是我的第一篇源码阅读笔记,以后会发更多的,包括算法和库实现,源码会按照我自己的代码风格格式化,去掉或者展开用于条件编译或者debug检查的宏,依重要程度重新排序函数,但是不会改变命名方式(虽然MSVC的STL命名实在是我不能接受的那种),对于代码块的解释会在代码块前(上面)用注释标明. template<class _RanIt, class _Diff, class _Pr> in

CI框架源码阅读笔记5 基准测试 BenchMark.php

上一篇博客(CI框架源码阅读笔记4 引导文件CodeIgniter.php)中,我们已经看到:CI中核心流程的核心功能都是由不同的组件来完成的.这些组件类似于一个一个单独的模块,不同的模块完成不同的功能,各模块之间可以相互调用,共同构成了CI的核心骨架. 从本篇开始,将进一步去分析各组件的实现细节,深入CI核心的黑盒内部(研究之后,其实就应该是白盒了,仅仅对于应用来说,它应该算是黑盒),从而更好的去认识.把握这个框架. 按照惯例,在开始之前,我们贴上CI中不完全的核心组件图: 由于BenchMa

CI框架源码阅读笔记2 一切的入口 index.php

上一节(CI框架源码阅读笔记1 - 环境准备.基本术语和框架流程)中,我们提到了CI框架的基本流程,这里这次贴出流程图,以备参考: 作为CI框架的入口文件,源码阅读,自然由此开始.在源码阅读的过程中,我们并不会逐行进行解释,而只解释核心的功能和实现. 1.       设置应用程序环境 define('ENVIRONMENT', 'development'); 这里的development可以是任何你喜欢的环境名称(比如dev,再如test),相对应的,你要在下面的switch case代码块中

Apache Storm源码阅读笔记

欢迎转载,转载请注明出处. 楔子 自从建了Spark交流的QQ群之后,热情加入的同学不少,大家不仅对Spark很热衷对于Storm也是充满好奇.大家都提到一个问题就是有关storm内部实现机理的资料比较少,理解起来非常费劲. 尽管自己也陆续对storm的源码走读发表了一些博文,当时写的时候比较匆忙,有时候衔接的不是太好,此番做了一些整理,主要是针对TridentTopology部分,修改过的内容采用pdf格式发布,方便打印. 文章中有些内容的理解得益于徐明明和fxjwind两位的指点,非常感谢.

CI框架源码阅读笔记4 引导文件CodeIgniter.php

到了这里,终于进入CI框架的核心了.既然是"引导"文件,那么就是对用户的请求.参数等做相应的导向,让用户请求和数据流按照正确的线路各就各位.例如,用户的请求url: http://you.host.com/usr/reg 经过引导文件,实际上会交给Application中的UsrController控制器的reg方法去处理. 这之中,CodeIgniter.php做了哪些工作?我们一步步来看. 1.    导入预定义常量.框架环境初始化 之前的一篇博客(CI框架源码阅读笔记2 一切的入

jdk源码阅读笔记之java集合框架(二)(ArrayList)

关于ArrayList的分析,会从且仅从其添加(add)与删除(remove)方法入手. ArrayList类定义: p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Monaco } span.s1 { color: #931a68 } public class ArrayList<E> extends AbstractList<E> implements List<E> ArrayList基本属性: /** *

dubbo源码阅读笔记--服务调用时序

上接dubbo源码阅读笔记--暴露服务时序,继续梳理服务调用时序,下图右面红线流程. 整理了调用时序图 分为3步,connect,decode,invoke. 连接 AllChannelHandler.connected(Channel) line: 38 HeartbeatHandler.connected(Channel) line: 47 MultiMessageHandler(AbstractChannelHandlerDelegate).connected(Channel) line: