• 注册
  • 查看作者
  • 数字后端设计实现后期碰到这些问题,如何做ECO?

     

    最近一直在帮同事解决各种问题。由于临近项目后期,所以很多问题的解决方法并不能只是告诉他们调整flow,重新跑flow。有几个问题也是比较常见的问题,大家或多或少可能都遇到过。今天小编挑选几个主题,做一个简单的分享,也算做个简要的归纳,希望对大家能够有所启发。

    Power off模块输出端未设置dont_touch

    大家都知道,对于一个可以powerdown的模块,其输出是不可控的。所以需要在其输出端添加Isolation cell,将其clamp为0或者1,保持一个稳定的状态。

    在数字后端实现时,需要将Isolation cell的输入端与powerdown模块的输出直连,确保中间没有buffer。为了实现这个目的,可以通过将Isolation cell的输入端设置为dont_touch。

    另外,还需要将这类Isolation cell 摆放在port门口。目的是确保powerdown模块的输出端与Isolation输入端的距离足够近,没有transition问题。具体实现方法可以通过magnet placement 来实现。

    这些低功耗设计实现经验,你真的懂了吗?

    那如果碰到比较粗心或者经验不足的数字后端工程师,他们在实现时并没有注意或者遗漏这些问题,导致在powerdown模块的输出端加了buffer(输出端的port有上千个),而且此时已经是项目后期,没有足够时间重新跑flow。那么应该如何解决呢?

    低功耗技术

    解决方法其实很简单,完全不需要重新跑flow,甚至都不需要去挪isolation cell的位置。只需要做一个简单的ECO即可。将power down模块的输出的net断开,和Isolation cell的input pin连接起来,再把Buffer连接到Isolation cell后面即可。

    时钟树重要技能

    小编也是很好奇,为何很多三四年甚至工作年限更长的数字后端工程师,对于复杂时钟结构的时钟树综合仍然摸不着头脑?真的有那么难吗?显然没有。

    数字后端工程师必须掌握的时钟树综合的技能

    理清时钟树结构,并画出时钟结构图。这点小编在公众号分享时钟树综合相关分享时,每次都要提到,可是真正会的人可能并不多。

    编写长时钟树的constraint。有了时钟结构图后,我们就可以写cts constraint,这个constraint是用来引导告诉工具如何长时钟树,即告诉工具某个clock的root点在哪里,sinks是哪些,哪些clock是要做同步的,哪些clock是需要做inter-balance的,各个mode下时钟如何长tree等。

    这个constraint真心不难写 。不外乎就是create_clock  create_generated_clock set_clock_group以及设置一些exception。这些命令估计没有一个人不会的。只要你理清了时钟结构,还是很容易可以写好的。下图为一个复杂时钟结构电路中最简单的一个分支,大家看看应该如何写constraint?

    时钟树综合结构

    其实理清时钟树结构,编写cts constraint这项工作,完全可以说这个是数字后端工程师最核心的一项技能,没有之一。而且也是数字后端实现整个环节中最具技术含量的一项工作。对于一个复杂时钟结构的设计,如果你能够很清楚地写出cts constraint,长出很“漂亮”的clock tree,那么整个数字后端实现还有其他的难点吗?

    深度解析Create_clock与Create_generated_clock的区别

    Route后没short,hold fixing后存在short

    有的数字后端工程师做事情就是不够认真。比如拿route后的数据进行了一轮hold fixing后,发现没有short,以为就万事大吉了,不再做后续的hold fixing了(评估阶段)。等最后拿到final netlist,进行final run后发现hold fixing会引入大量的short。主要原因有以下几点:

    • 前期hold fixing评估所用的corner不全

    前期评估hold所用的corner比较少,所以hold数量偏少。后期将所有corner都考虑进去后,发现hold buffer太多,从而导致route 出现short。

    • Local clock skew偏大,导致hold violation较大。

    Clock skew比较大,说明tree长的不平。虽然setup可能是meet的,但是两个clock tree latency差距比较大的寄存器进行hold check时,很容易出现较大的hold violation。所以在局部区域需要插入特别多的hold buffer,这样就容易出现short。

    • Local cell density太高,出现局部区域density为100%的情况

    这种情况其实还是蛮常见的。虽然局部区域cell density已经达97-100%,但是route和timing都是OK的。所以,很多初级后端工程师误以为这不是潜在的地雷。其实这是非常危险的,如果碰到这种情况,不做特别处理,后期hold fixing和解route问题都是非常棘手和痛苦的一件事。

    所以,小编一直反复强调每个stage都需要查看congestion map,cell density map和pin density map。这绝对不是为了好玩哦。

    数字后端实现时congestion比较严重,你hold得住吗?

    动态IR Drop偏大

    • 在高翻转模块中预先插入decap cell

    通常情况高翻转模块,也是design中timing比较紧的地方。在该区域预先插decap cell可能会导致timing变差。因此,插decap cell的方式就显得尤为重要。主要围绕两个原则,一个是timing所受的影响较小,在可接受范围之内,第二是decap cell要足够多,足以改善IR Drop issue。

    • 减少power switch cell的电阻

    特别是对于需要做power domain的模块,更容易出现IR Drop问题。由于Power switch 本身电阻较大,Global VDD到Power switch就存在一定的压降,这个压降比例值往往能占到1.5%。所以,如果能够定制一款低电阻值的power switch cell,岂不是一种很好的解决方法。

    • 利用高层金属来画power

    高层金属比较宽,比较厚,所以电阻值相对较小。所以通常都是用高层厚金属来打power。

    • 加密power mesh

    对于项目后期发现的动态IR Drop问题,可以从Redhawk结果中分析找出压降比较大的点,然后在该区域局部加密power的密度。

    IR Drop分析之Redhawk分析流程

    小编知识星球简介:

    在这里,目前已经规划并正着手做的事情:

    • ICC/ICC2 lab的编写
    • 基于ARM CPU的后端实现流程(已经发布)
    • 利用ICC中CCD(Concurrent Clock Data)实现高性能模块的设计实现(已经发布)
    • 基于ARM 四核CPU  数字后端Hierarchical Flow 实现教程(准备中)
    • 时钟树结构分析(规划中)
    • 低功耗设计实现(规划中)
    • 定期在星球布置作业题(星球已经支持布置作业功能)

    在这里,各位可以就公众号推文的内容或者实际项目中遇到的难题提问,小编会在24小时内给予解答(也可以发表你对数字后端设计实现中某个知识点的看法,项目中遇到的难点,困惑或者职业发展规划等)。

    反正它是一个缩减版的论坛,增强了大家的互动性。更为重要的是,微信有知识星球的小程序入口。星球二维码如下,可以扫描或者长按识别二维码进入。目前已经有四十五星球成员,感谢这四十五位童鞋的支持!欢迎各位铁杆粉丝加入!终极目标是打造实现本知识星球全员年薪百万的宏伟目标。(星球的门槛将会越来越高,有需求的朋友趁早上车)

     

  • 0
  • 0
  • 0
  • 414
  • 单栏布局 侧栏位置: