from:
https://my.oschina.net/liyanqing/blog/3147437/print
https://msd.misuland.com/pd/3691885030725916478

library characterization，简称k库，意为特征参数提取，一般用于提取stand cell，io，ip，memory等的timing和power信息，常用工具为cadence家的liberate（以及提取lvf信息的variety，用于memory的liberate_mx），以及synopsys家siliconsmart。

c家的liberate市场占用率更高，以此为例说明。

提升k库速度的关键是提升并行度，liberate提升并行度的主要方法是采用packet_client模式（默认是arc_packet，就是基于arc做任务划分），其模式如下图所示。主的liberate启动后，通过bsub的方式将辅的liberate投递出去，每个辅的liberate可以启动多进程，每个liberate进程会起一个spectre来做仿真，而spectre本身还可以采用多线程提高并行度。

跟仿真并行度相关的设置有：

1. set_var packet_clients <NUM>

2. char_library -thread <NUM>

3. set_var extsim_cmd_option "+mt=<NUM> ***"

简单说明一下这几个参数。

#1， packet_clients指的是起多少个辅的liberate，主的liberate起任务拆分和流程控制的作用，辅的liberate会和主的liberate通讯，完成主的liberate分配的arc仿真任务，然后退出。

#2， char_library中的thread指的是每个辅的liberate（wrapper）起多少个真正的liberate进程（这个地方虽然叫thread，其实指的是进程而非线程），每个真正的liberate会启动一个spectre来做仿真。

#3， extsim_cmd_option用来设定spectre的仿真参数，其中如果设置了"+mt=<NUM>"，可以为spectre开启多线程。

这些参数设置，有一些默认的规则或者限制，比如：

1. packet_clients不能大于350.

2. spectre单线程的情况下，推荐packet_clients*thread=slots，也就是说，根据能提供的资源，让每个真正liberate进程占据一个cpu核，这样的负载是合理的。

3. 提高packet_clients能够提升并行度，但是随着随着client liberate数目的提升，master liberate任务拆分的时间会加长，master-slave通讯开销会增长，单client出错的概率会增加，对总的runtime而言未见的是好事。

4. 提高thread能够提升并行度，但是随着thread的增加，每个thread对runtime降低带来的效益是递减的。

5. packet_clients*thread*10小于总arc的数目，否则会造成部分已分配资源浪费。

那么这些参数怎么设置会更合理呢？需要根据不同的cell类型，不同的需求（速度优先还是性价比优先）来设定，但是我们造一个小case（请注意前提，这是个小case，意味着arc的数目不会太多），测试一下限定条件下相关设置的一些基本规律，供作参考。

 首先我们测试随着packet_clients的变化，case的runtime变化趋势（其他条件不变）。

需要注意的是，这个地方最后增加packet_clients而runtime不再降低的原因，主要是因为arc数目不太多，每个packet_clients分到的arc有限，虽然继续提高并行度能略微降低仿真时间，但是任务拆分的时间花费也会相应提高，从而抵消了仿真时间缩短带来的runtime收益。从这个测试我们得到的经验是：

1. 如果design很大，arc数目足够多，提升packet_clients是能够线性提升运行效率的。

2. 如果design比较小，arc数目不够多，较小的packet_clients就足够了，提升packet_clients需要线性提供更多资源，但是对降低runtime来说起到很小的作用。

 然后我们测试随着liberate thread的变化，case的runtime变化趋势（其他条件不变）。

同packet_clients类似的问题，不多做解释。

理论上我们认为，在合适范围内，在保持packet_clients*thread不变的前提下，case的runtime应该是基本恒定的，packet_clients和thread的此消彼长是可以相互抵消的。由于packet_clients*thread应该和cpu和核数保持一致，所以我们把这个关系简化为cpu资源和runtime的关系测试。

这个测试中，define_arc的数目为300作用（user_arcs_only模式），我们粗略估计总体arc数目应该在一千左右的级别，考虑到每个thread默认跑10个arc，可以看到，当cpu数目大于100时（thread>100），部分thread会出现空跑的现象而造成资源浪费，随着资源总量的增加，能效比开始大幅下滑，runtime趋于稳定。

 此时我们先给出一个简单的结论。

1. 对于大的design，如果确认arc足够多，可以通过提升packet_clients和liberate thread来提高并行度，但是根据经验，packet_clients不要超过300，thread在2-4之间比较合适。

2. 对于小的design，packet_clients*thread的总数不要设的太大，否则很容易造成资源浪费，runtime也不能显著降低。

 此外，我们直接给出spectre设置的推荐建议，如果机器资源充足，将spectre的multi-thread设置为2是合理的。

解释一下原因。liberate启动spectre的方式是这样的，对于每一个仿真（大多数仿真量都很小），liberate会启动spectre，仿真，关闭spectre，然后循环往复。由于大多数仿真时间都很短，导致spectre启动和关闭的时间占比都很长，用很多实例测试，我发现spectre的cpu占用率都达不到50%，这意味着cpu资源被大量浪费了！所以把spectre的multi-thread设置为2能够显著地提高cpu利用率，从而提升运行效率。不精确的粗略估计，spectre的thread从1到2，运行效率可以提升30%。

那么有没有其它的方法能够解决spectre仿真cpu利用率低的问题呢？有的，那就是SKI模式，SKI模式的方法就是，spectre启动以后，一直不退出，它通过一个通讯通道将仿真输入传送到spectre，仿真完毕后吐出结果，然后持续地进行下一轮仿真，我实测过一个小的case，采用SKI后，runtime直接降低到45%！SKI这么好，那为什么它没有被设置为默认方法呢？因为SKI会带来仿真精度损失的副作用。同样是一个小的测试用例，测试时发现，采用SKI模式会造成仅97.5%左右的pass rate，且最大的outlier相对误差达到了60%，因为这个原因，苛求精度的liberate一般较少采用SKI模式，但是做lvf仿真的variety由于运行时间过长，精度要求不高，一般是推荐采用SKI模式的。

总结：

1. 根据总的可提供cpu slots来设置liberate并行度，要求packet_clients*thread=slots即可。

2. spectre开启thread=2可以提升仿真效率。

3. packet_clients最大不要超过350，一般300以内是最好的。

4. liberate thread设置到2-4较好，最大最好不要超过8。

5. SKI模式是大招，对精度要求没有那么高的话欢迎使用，可以大幅缩短仿真时间（尤其是对constraint）。