在线咨询
eetop公众号 创芯大讲堂 创芯人才网
切换到宽版

EETOP 创芯网论坛 (原名:电子顶级开发网)

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 2473|回复: 0

[原创] 【干货】Library Characterization单元库建库常见的debug方法

[复制链接]
发表于 2020-4-11 21:11:56 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册

x
最近一段时间跟一些朋友交流,大伙儿反映在日常工作中或多或少接触了SiliconSmart,也做了一些相关工作,但经常遇到一些麻烦,流程大致明白,设置也不复杂,但总是跑不下去,出现这样那样的Error和Failure,Log又看不太明白,debug花了相当长的时间。

我在想能不能写点什么,尽量帮助有需要的朋友减少一点debug的时间。我觉得很有必要,但确实很难,因为debug是一个费时费力,又case-by-case的体力活。它建立在具体的问题上,一篇文字很难说的十分清楚,只能是根据自己的经验大致跟大家分享一下,希望能给大伙儿一点小小的启发。

几个共性的原因

使用工具过程中出现了Error,先考虑下面几个共性的原因:

-  License问题
-  Spice问题
-  Setup是否正确
-  服务器的问题

License问题

首先考虑license安装及环境变量配置否正确(如不了解可咨询CAD),其次考虑license是否过期,如需申请license请联系你的Synopsys销售代表。

Spice问题

考虑netlist和spice model是否匹配,这个错误大多数时候都不会犯,但谁都干过智商欠费的事儿,确认一下总不是什么坏事。

SiliconSmart的文件大多数时候是区分大小写的,需要注意configure.tcl和inst文件里面有没有区分大小写。如果netlist里某一个subckt有小写的gnd,改成大写,否则工具会自动在subckt里添加GND,导致仿真错误。

Setup是否正确

Spice model是否正确定义在configure.tcl里了?路径对不对,文件全不全?operating_condition(PVT)是否定义正确?各种命令和参数是否有语法错误?

跳过characterize步骤,仅跑configure和model,确保我们的configure.tcl、.inst和run.tcl文件基本设置正常。然后带上characterize一起,仅跑一些简单的arc,如Cin等。

服务器问题

关注硬盘是否有足够空间(simulation_tmpdir)?操作系统(OS)是否跟当前使用的SiliconSmart以及仿真器版本兼容?如果你用到了compute farm,注意下normal_queue的名称是否正确定义在configure.tcl里,是否有权限登录这个queue丢job。

几种常见的问题

电源相关

确保所有的supplies和grounds都正确定义在了operating conditions里;

确保所有的powermeasurements都正确定义:

power_meas_supplies{ }
power_meas_grounds{ }
model_exclude_supplies{ }
power_meas_map{ }

选择正确的powersupply modeling format:

liberty_multi_rail_formatv1/v2/none

Hidden Energy没有model出来

Hidden energy量测的是input pin翻转的energy,但前提是这个input翻转不会导致output翻转。那么如果hidden energy没有model出来,就可以考虑是否这个input的翻转不可能不导致output翻转,比如,反相器,输入端翻转,输出端就必然翻转,因此,反相器没有hidden energy。

另外,由于SiliconSmart需要判断input对output的影响,因此必须正确定义cell的function,也可以从function这个方向查找原因。

区分大小写

前面也提到,SiliconSmart是区分大小写的,因此netlist里subckt的port的大小写需要跟configure.tcl,.inst和run.tcl里的定义一致。否则经常会出现configure之后的deck不完整,或者某些input_meter not found的错误。

Auto-range相关的问题

跟auto-range相关的arc通常以capload0*打头,如果出现error,建议先关掉auto-range,set autorange_load off,然后自己给定load的值,用这个办法来排除电路设计本身的问题。跟auto-range有关的,经常会调整的参数有largest_slew和max_tout,很有用。

量测不到结果

如果log里出现failed measurement相关的关键词,通常是没有量到结果。这种错误非常非常常见,原因也非常多,debug起来也比较费时。

首先考虑powersupplies以及pintype的定义是否正确,道理很简单,如果power/ground都没给对,cell也不可能有正确的behavior;

其次要查激励是否正确,比较常用的方法是单独仿真某一条arc的deck,用waveview查看input/output的波形,排除电路设计本身的问题;

如果电路的behavior没有问题,考虑cell的function定义是否准确,可以考虑用add_table代替add_function来清楚准确的告诉工具cell的function(工具只能根据你给的function来产生需要量测的arc,如果你给的function不能准确描述电路的行为,工具自然是量测不到的)。

Log在哪里找?

出现了Error和Warning很正常,首先就是去看log,一般来说log提供的信息还是比较详细的(不排除有些还是不够友好,随着工具版本的升级,log已经越做越好了)。

Log有几种,一种是SiliconSmart的log,default(没有设置set_log_file)下,该log放在启动SiliconSmart的路径下,以siliconsmart.log命名,可以通过set_log_file更改名称和路径。之前的推文也提过,如果你不删除老的log,新log会附在老的log之后。

1.png

2.png

还有一种log也经常会去看,仿真器的log(如Hspice的deck.lis等),当我们已经定位到某一条arc的error/warning时,去看这个log,对于我们debug这条arc很有用。

最后,如果你使用CDPL(LSF/SGE/Custom)并行丢job,job_scheduler log也需要重点查看,该log放在$charpoint/runtime/cdpl/目录下,记录job scheduler相关的日志,其中master*.err记录bsub/qsub等提交job命令相关的日志,sis*.log可以看到单个job的运行情况。

关于librarycharacterization的debug,内容多且复杂,一个K库工程师花在debug上的时间可能会占到70%甚至更多。而且debug很影响心情,有些人很享受debug的过程,更多人会陷入到深深的自我怀疑中。我希望这篇文字能给大伙儿带来哪怕一丁点启发,也不枉我码四小时字了。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
更多内容欢迎关注公众号【单元库特征化及建库技术】ID:libchar
无标题.png









您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

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

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

GMT+8, 2024-3-28 17:48 , Processed in 0.017308 second(s), 7 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
快速回复 返回顶部 返回列表