• Congestion问题怎么解决?



    参考文章:http://www.52-ic.com/1029.html

    Congestion 问题怎么解决?

    1、RTL阶段

    一般是由大的MUX、大的Crossbar造成的,解决方法是将设计拆分,大模块分成小模块;
    对于大扇入的MUX,可以通过级联MUX优化走线问题;对于大扇出,例如一个FSM驱动多个block,可以通过复制这个FSM来优化走线问题。

    2、PR阶段

    跟Congestion相关的主要包括以下几个部分:宏单元、标准单元、Power Mesh。

    1、宏单元与宏单元之间

    当相邻的两个Macro距离很近时,由其是Memory,多个Memory的数据线和地址线在狭窄的空间内无法找到足够的布线通道,通常会发生Congestion。
    解决办法:
    (a)加大宏单元的间距,可以设置placer_soft_keepout_channel_width,让工具在较小的channel间放置soft blockage
    (b)调整Macro的位置、摆放方向,注意出Pin的方向,为出pin的区域留出足够的空间,避免产生狭窄的通道。
    (c)另外当多个Memory共用相同的数据线或者地址线时,可以调整它们的位置,使它们的Pin对齐,这样连线会比较规整,对Congestion有帮助,即相关的macros进行group。

    2、宏单元与标准单元之间

    (a)标准单元不能离宏单元太近,宏单元周围要放置Placement Blockage。可以设置physopt_hard_keepout_distance在宏单元四周放置hard blockage,或者create_placement_blockage -name -type -bbox
    (b)由其注意Macro出Pin的方向一定要留出channel,否则Macro离std太近不容易出Pin。可以使用命令set_keepout_margin -type hard -outer {10 0 10 0} RAM
    (c)另外要注意之前摆放宏单元的规则,注意尽量靠近角、边,给中间的标准单元一个连续的区域。

    3、标准单元与标准单元之间

    可以分为两种情况:

    3.1局部高密度标准单元引起的congestion

    大量的绕线通过高密度标准单元区域时,有时候会发生局部的较为严重的congestion。

    解决办法:
    (a)为了解决局部congestion,我们通常会借助partialblockage降低局部区域的标准单元密度。Partial blockage是placement blockage的一种,是某一区域设定标准单元的利用率。有时候用partialblockage,并不能有效的解决congestion,这时候可以用blockage array来解决此类congestion。Blockage array是用“blockage阵列”的方式,控制congestion区域的标准单元的在区域内成条状分布:一方面降低了密度,另一方面预留出了布线通道。create_placement_blockage -name -type -bbox
    (b)限制阻塞区域的placement的密度:set_congestion_options -max_util 0.4 -coordinate {x1 y1 x2 y2}

    3.2局部高密度pin cell导致的congestion

    在数字逻辑设计中,如果某些模块用了大量的高密度pin标准单元(如AOI、OAI等),这些标准单元会有很多的互联关系,这样就会导致在有限的空间内,存在大量的绕线,从而发生congestion。
    解决方案:

    1)在逻辑综合中,禁用这些高密度pin的标准单元,这样综合出的网表中就不会有这些单元了,或者用DC的高级功能—DCG来解Congestion;

    2)有针对性的降低此种标准单元的密度,如在ICC里,可以对这些标准单元设置keep_out_margin。通过此种方法,可以有效的削弱congestion;

    3)对于层次性(Hier)设计而言,如果拥塞基本发生在某个模块内部,那么可以单独针对该模块设置Plangroup,并设置它的利用率,可以通过尝试找出既不会有太大Congestion,又不会太浪费面积的参数设置。

    4)当然除了3)之外,某些含有很多AOI、OAI单元的模块而言,也可以用RelativePlacement的方法来解决,因为这些模块大多是datapath,完成某类复杂数学运算的单元,其中大部分的datapath都有规律可循,如果让PR工具自己做Placement,摆放可能比较乱,且利用率也比较低,如果用手工分析摆放的方式,那么利用率甚至可以大于95%,且不会有Congestion,因为单元摆放比较规整,走线也都很规整。不过这种方式比较耗时,手工成分非常高,现在也有一些研究用人工智能、机器学习(ML)方式来自动做Relative Placement的。

    4、Power Mesh与标准单元之间

    数字IC版图设计中如果PowerMesh打的太多,下方还放置的有标准单元,那么在出Pin的地方可能会存在Congestion
    解决方案:
    1、减少power,不要打太多,根据以往经验和IR-drop分析的结果,可以在IR-drop满足的情况下,减少Power Mesh,不用占用太多布线资源。

    2、另外可以在布局之前设置让软件在Power下面不要放太多单元,设置partial blockage,partial density control。如下图所示,可以非常清晰的看到,大部分的拥塞都发生在Power Mesh附近,这可以通过对Power Mesh设置partial blockage来解决。set_pnet_options -partial {metal2 metal3} set_pnet_options -complete {metal2 metal3}

    5、Power Mesh与宏单元之间

    这种情况可能不多见,如果出现了多半也是恰巧在Macro出Pin的地方上方有Strap。这种情况要注意,由于Memory这类Macro外边要做Macro的PGRing,Memory里面的PG网络也非常密集,有如Rail一般,都需要连到Macro的PG Ring上,且如果上方有Strap的话也会连上去。对于出Pin的地方如果有Strap,因为Strap会通过Via一路打到M1或者M2层的Rail上,那么这些地方可以说路都被封死了,Macro当然就很难出Pin了。
    解决方案:

    (1)调整电源地规划方案。
    (2)如果设计中有很大的拥塞,需要赶快解决。在Floorplan阶段也没有必要把设计中的拥塞全部降到0,因为此时软件只是快速做了一个参考布局方案而已,并非实际的布局,所以某些拥塞并没有完全解决,它们可以在后续的布局阶段解决。由于ICC允许可以不沿着格点布线(即Zroute模式),所以在布线阶段也会解决一部分拥塞。

  • 相关阅读:
    第一篇日志
    Spring mvc 4系列教程(三)—— Spring4.X的新特性
    Spring mvc 4系列教程(二)——依赖管理(Dependency Management)和命名规范(Naming Conventions)
    Spring mvc 4系列教程(一)
    【管理心得之三十六】《黄帝内经》中的一句话
    【管理心得之三十五】好习惯也能惹“骂名”
    【管理心得之三十四】“禅宗境界”的员工
    【管理心得之三十三】管理者的“眉头”
    【管理心得之三十二】PMP杂谈---------爱情必胜术
    【管理心得之三十一】我的位置
  • 原文地址:https://www.cnblogs.com/wt-seu/p/12812651.html
Copyright © 2020-2023  润新知