干(mei)货(sha)放(nei)送(rong)！Library Characterization常见的debug方法

点击上面“蓝字”关注我们！

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

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

1

几个共性的原因

使用工具过程中出现了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。

2

几种常见的问题

• 电源相关

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

确保所有的power measurements都正确定义：

power_meas_supplies { }

power_meas_grounds { }

model_exclude_supplies { }

power_meas_map { }

选择正确的power supply modeling format:

liberty_multi_rail_format v1/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起来也比较费时。

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

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

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

3

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的运行情况。

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

等到公众号有1万粉丝（梦想要有的，能不能实现再说吧）的时候考虑要不要写本书，好好把K库这件小事唠唠。现在才几百人。。各位老铁多多转发吧。。谢了！

欢迎加入微信交流群

长按右边二维码

加我微信，拉您入群

长按二维码关注公众号

点一下"在看"再走吧