mervin_li的个人空间 https://blog.eetop.cn/1582944 [收藏] [复制] [分享] [RSS]

空间首页 动态 记录 日志 相册 主题 分享 留言板 个人资料

日志

<数字后端项目>clock tree平衡法则笔记--常见debug思路

已有 60 次阅读2023-1-17 16:12 |个人分类:后端项目经验|系统分类:芯片设计

关于CTS的debug过程,还是采取常规的方法--分段定位

  1. 首先明确要分析的问题是什么,明确目标

  2. 按照CTS过程步骤定位到具体step去分析

  3. 采用存中间db,控制变量等方法去复现问题进行debug

第一点,明确目标,比如是要看CTS的做的质量问题,skew?timing?drv?不同的问题,入手的角度和具体技巧都有所不同。以timing为例,基于innovus工具跑完ccopt之后,看到timing report发现timing和预期差异交大,那我们就重点关注timing相关信息。分析report确定是cts阶段tree的质量问题skew过大导致的还是opt阶段修timing有问题。

第二点,分步骤去log分析具体段落是否有异常。比如skew 问题,确认是否开了useful skew,同时就在cts阶段检查每个小的step是否正常,clustering,balance等步骤。如果skew没问题,那就看opt过程中的drv是否修的正常,worst chain是否符合预期结构等。

第三点,按照上一步的分析,分步存db去具体定位,比如cts存一个,opt再存一个;更细的就是可以在clustering存一个,preroute,postcondition route等步骤存相应的db。控制变量则可以采取调整skew mode,drv 约束,甚至clone,merge等更小更具体的工具行为来验证推测。

这三点做完之后,问题基本就可以定位了,甚至有的已经顺便解决掉了。剩下的就是有针对性的采取策略,或控制clock spec来长tree,或调整option控制细微的长tree行为,又或者改变opt的优化策略以及优化力度等等。当让,问题的root cause如果找到了,那么后面的策略就不是难点了。关键还在于debug过程如何高效,这里就涉及到对cts log的学习,熟悉cts的具体步骤是在做些什么。然后在遇到问题进行debug的过程就可以更加高效了。更深一层的理解,如果掌握了工具的算法以及行为,那就事半功倍了。不过在实际的项目当中少有时间去研究工具行为,那么平日的积累便是修炼的重点了。

常见的debug方向就是cts config的setting是否合理,mode是否有出入,避免了人为的错误之后,再检查deisgn的约束,例如dont touch了某些instance或者net导致不能正常长tree或者优化等。尽管问题可能千差万别,但是本质上都逃不过CTS的基本行为规则,是否高效处理问题,更多的也是看积累,然后剋快速反应定位。

大体思路先记录这些,后面详细分解cts的step,从而更好理解长tree的过程。




点赞

评论 (0 个评论)

facelist

您需要登录后才可以评论 登录 | 注册

  • 关注TA
  • 加好友
  • 联系TA
  • 0

    周排名
  • 7

    月排名
  • 0

    总排名
  • 0

    关注
  • 78

    粉丝
  • 46

    好友
  • 47

    获赞
  • 46

    评论
  • 2714

    访问数
关闭

站长推荐 上一条 /1 下一条

小黑屋| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网 ( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2023-1-31 11:52 , Processed in 0.032147 second(s), 8 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
返回顶部