日志
【干货】Library Characterization单元库建库常见的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之后。
还有一种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
/2 
eetop公众号
创芯大讲堂
创芯人才网