zoukankan      html  css  js  c++  java
  • 为什么异步时钟不要设false path

    白山头 白山头讲IC

    为什么异步时钟不要设false path

    对于初学者,常常认为异步电路应该设false path。甚至很多老手也是这么认为的。
    其实针对于异步电路,是有专门的sdc的命令来完成这项任务的。

    set_clock_groups -asynchronous

    用作用上来看,似乎和false path的效果是一样的。那么为什么还有这么个命令呢。

    设想一下,有两个clock, clka和clkb,属于异步关系,应该怎么设置呢?

    用clock group的方法:

    set_clock_groups -group clka -group clkb 【命令1】

    用false path的方法:

    set_false_path -from [get_clock clka] -to [get_clock clkb]   【命令2】

    set_false_path -from [get_clock clkb] -to [get_clock clka]


    比较下来,似乎clock group的方法更为直观一些, 但是差别也不大。
    那么设计这个异步命令的真正原因是什么?它和false path的作用的根本区别是什么?

    在set_false_path的manual里面,有这么一句话解释了两者的真正区别:

    总结下来就是,异步电路的话,一定要用命令1,同步电路的话,再用命令2. 两者对于crossstalk的计算方法不同。

    笔者就曾经在项目中遇到过这个问题,本来应该设异步的情况下,设置了false path。由于是在timing clean之后发现的这个问题,那么修改之后就很容易比较两者之间的差别。
    结果就是改为命令1的设置之后,timing变差了很多,有些path甚至有几百ps之多。

    如果感兴趣的话,可以用自己的design做个实验,可能有惊喜。

    那么manual里说的的crosstalk分析究竟有什么差别呢?

    如图,在crosstalk分析中,当信号A和信号B跳变发生于同一时刻,那么信号B会因为信号A的影响,产生一个delta delay。而如果信号A的跳变过早或者过晚,那么对于信号B的delay就没有影响。

    那么两条net哪个时aggressor,哪个时victim呢?这取决于我们在分析哪个net。由于我们分析的是信号A对信号B的影响,所以这里的信号A就是aggressor,信号B就是victim。反之亦然。通常实际设计中的对于一个victim,aggressor不止一条,同样,对于一个aggressor,也会有多个victim。

    当进行on-chip-variation mode 分析的时候。每一个aggressor和victim的跳变,都会有个最早到达时间和最晚到达时间。这个最早和最晚到达时间中间的window,就称为timing window。只有当aggressor和victim的timing window有重叠时,delta delay才会产生,也就是说,aggressor才会对victim产生影响。

    如果设set false path,工具会继续按照同步关系计算timing window。

    而我们知道,对于aggressor和victim属于两个具有异步关系的clock的情况,aggressor的跳变可能发生于victim整个时钟周期的任何时刻。而不只是在按照同步clock计算出来的timing windlow中。

    而按照同步关系来计算的话,aggressor对victim的timing window之外的跳变的影响,工具就忽略了。这可能会导致严重的后果,轻则性能下降(setup),重则芯片fail(hold)

    总之,谨慎设置false path,力争芯片一次成功。



  • 相关阅读:
    springMVC整合mybatis框架的项目起始配置
    springMVC解决JSON对象乱码问题
    SpringBoot将redis和spring-cache集成使用
    idea实现右侧预览
    List循环遍历时移出元素
    Mac下IDEA卡顿解决方案
    swagger中@ApiModelProperty中example属性对List的支持
    centos7安装PostgreSQL12
    mongo添加索引及索引相关方法
    Mac下安装Postgresql
  • 原文地址:https://www.cnblogs.com/lelin/p/12698457.html
Copyright © 2011-2022 走看看