试用CCOpt Native三天的心得体会

caesars82

回复 20# Timme


    受兄启发，这三周，用CCOPT评估了一个block，觉得，确实CCOPT很强大，大致分享下心得。
    用来评估的设计如下：80W+ standard cell，无power domain，近100块RAM，无其它IP。

    用CCOPT前，post-route结果如下：utilization 51%(评估用，面积划的大了点，呵呵)。LVT% = 14%。timing能修完。

    一直想把LVT%降下来，但试了很多方法，都无法降下来。受Timme启发，先做一轮到CCOPT fix timing，然后，用脚本抽出所有有violation的endpoint name及violation value。把这些值，返回给RCP，作为clock latency，用N2N的方法，重新优化一版网表。再用该网表及def，从placement开始做，一直跑到post-route opt结束。发现用RCP做N2N重新综合后，timing大大优化。N2N前后，各阶段的数据大致对比如下：pre-cts opt时，N2N前后，timing差别不大，都OK，是+100ps左右。post-cts opt后，差距就很明显了，不用N2N的，WNS/TNS = -290ps/-200ns，N2N+CCOPT后，WNS/TNS = -100ps/-30ns，感觉这个差距非常大，也许既有CCOPT的功劳，也有RCP的功劳，可能RCP的功劳更大。post-route opt时，不用N2N，打开LVT的，WNS/TNS = -30ps/-5ns，且LVT% = 14%。N2N后的，则直接修完，且LVT% = 3%。

    从以上评估，感觉N2N+CCOPT，确实可以大大提高timing。也有以下心得：1. 用CCOPT时，关闭LVT。之前打开LVT用CCOPT，工具会先将SVT换为LVT，看timing OK了，就跳出，CCOPT根本未起作用，所以，做出的效果，和普通CTS几乎一样。关闭LVT后，CCOPT的效果，就完全体现出来了，会有多轮迭代，调skew来修timing。整个过程也不算慢，和CTS+post-cts opt差不多。 2. 用脚本抓出的endpoint violation path，不要作为insertion delay，直接给CCOPT，然后让CCOPT来重新优化，这样做出的结果，还不如什么都不设的好。用脚本抓出了2000+条有violation的path，估计PR工具要考虑的太多，把这2000+条path设给CCOPT后，无法兼顾，所以，优化结果反而更差。应该把这些path给RCP，进行N2N的opt，生成的网表，再重新进行placement及opt，这样得到的QoR，大大提高。应该是综合工具的优化能力，远强于PR工具的原因。3. CCOPT能看到derate，根据这个，来调skew，修timing，结果比CTS+post-cts opt的效果确实要好。普通CTS时，无法看derate，导致CTS时看到的skew还行，但在post-cts时看，就差了一截了，即使再用useful skew，效果也不如CCOPT的边CTS边useful skew opt timing来得有效果。4. 由于对设计不太了解，所以，未划分skew group，只是把CCOPT的所有设置都过了一遍，打开/关闭了一些参数，然后跑的CCOPT，感觉效果还不错。可能用了SG后，效果会更好。

    以上就是大致的心得，以后N2N+CCOPT应该就是我做PR的标准流程了。欢迎Timme跟帖评论，看还有哪些可以进一步改进的。

Timme

回复 21# caesars82


原谅我没有太看懂，你将Violation Value作为Latency反标是何用意？依我的理解，这两个应该没有太直接的关系。

举个简单例子：时钟周期2ns，第一轮CCOpt后RegA的Insertion Delay是2ns，RegB的Insertion Delay是3ns，RegA到RegB的数据路径3.2ns，违规200ps。我们应该将RegA Latency 2ns、RegB Latency 3ns反标给RCP，或者按照相对值，只对RegB反标（3ns-2ns）=1ns的Latency，RegA保持默认的0 Latency也可以（但不推荐）。如果将违规值200ps作为Latency反标给RegB，那RCP看到的结果会完全不一样。

caesars82

回复 22# Timme


   以该例子为例，我是用Setting attribute clock_network_late_latency -200ps，反标到regB的clk端，没有将regA的2ns和regB的3ns反标给RCP。目的是这样：根据CCOPT后的结果，看哪些路径无法修完，还差多少ps，就把这个violation再加紧一点，反标回去(比如-200ps的violation，再加150ps，变成-350ps，反标到regB的clk)，让RCP先看到这段路径上的delay差值，然后预先进行优化。虽然这样看到的结果，确实不是时钟树综合后的真实clk tree长度，但达到了加紧约束的目的，让RCP预先按加紧的值进行优化。更有点类似于手工useful skew，看violation是多少，就把clk tree加紧一点，多优化一点。
    Timme说的方法，我之前还确实没想到过，你的方法，是不是就应该在CCOPT后，把所有reg的clk tree的长度全部抽出来，然后反标给RCP，让RCP按照CTS后的真实结果，来做opt(如果只反标regA和regB的latency，那对于regB到regC的路径，regC的latency还是0ns，就相当于regB到regC的setup太过约束了)？这个方法确实更彻底，能看到所有的violation值。我的方法，可能反标了-350ps的latency后，那条路径在RCP看来，还是正的，所以，还是不会努力去修。

    好，我再按你说的方法试试，抓出所有reg的clk latency值，反标给RCP，opt后，再给PR。也应该是将RCP新生成的netlist和def反馈给PR，然后去掉所有的clock latency，从pre-cts opt阶段开始做吧？

caesars82

回复 22# Timme


   用同一版数据，分别试了反标clock latency给RCP及反标path violation给RCP，结果如下：
反标clock latency给RCP，重新综合后，在PR，直到CCOPT修完post-cts setup & hold，timing summary如下：
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|     Setup mode     |   all   | reg2reg | in2reg  | reg2out | in2out  | clkgate | default |
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|           WNS (ns):| -1.302  | -0.146  |  0.817  | -1.302  | -0.135  | -0.126  |  0.000  |
|           TNS (ns):| -2203.9 |-144.786 |  0.000  | -2059.1 | -1.424  | -5.871  |  0.000  |
|    Violating Paths:|  4741   |  2801   |    0    |  1940   |   16    |   184   |    0    |
|          All Paths:|1.45e+05 |1.34e+05 |  11510  |  1940   |   16    |  9982   |    0    |
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|wc_cworst      | -1.302  | -0.146  |  0.817  | -1.302  | -0.135  | -0.126  |  0.000  |
|                    | -2203.9 |-144.786 |  0.000  | -2059.1 | -1.424  | -5.871  |  0.000  |
|                    |  4741   |  2801   |    0    |  1940   |   16    |   184   |    0    |
|                    |1.45e+05 |1.34e+05 |  11510  |  1940   |   16    |  9982   |    0    |
+--------------------+---------+---------+---------+---------+---------+---------+---------+

+----------------+-------------------------------+------------------+
|                |              Real             |       Total      |
|    DRVs        +------------------+------------+------------------|
|                |  Nr nets(terms)  | Worst Vio  |  Nr nets(terms)  |
+----------------+------------------+------------+------------------+
|   max_cap      |      0 (0)       |   0.000    |      0 (0)       |
|   max_tran     |     17 (59)      |   -0.216   |    222 (2000)    |
|   max_fanout   |    564 (564)     |    -87     |    587 (587)     |
|   max_length   |   4770 (4770)    |   -2306    |   4770 (4770)    |
+----------------+------------------+------------+------------------+

Density: 64.588%



反标path violation再做PR，结果如下：
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|     Setup mode     |   all   | reg2reg | in2reg  | reg2out | in2out  | clkgate | default |
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|           WNS (ns):| -1.165  | -0.039  |  0.791  | -1.165  | -0.167  | -0.030  |  0.000  |
|           TNS (ns):| -1868.0 | -10.727 |  0.000  | -1857.2 | -1.437  | -2.185  |  0.000  |
|    Violating Paths:|  2693   |   753   |    0    |  1940   |   15    |   145   |    0    |
|          All Paths:|1.45e+05 |1.34e+05 |  11510  |  1940   |   16    |  9982   |    0    |
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|wc_cworst      | -1.165  | -0.039  |  0.791  | -1.165  | -0.167  | -0.030  |  0.000  |
|                    | -1868.0 | -10.727 |  0.000  | -1857.2 | -1.437  | -2.185  |  0.000  |
|                    |  2693   |   753   |    0    |  1940   |   15    |   145   |    0    |
|                    |1.45e+05 |1.34e+05 |  11510  |  1940   |   16    |  9982   |    0    |
+--------------------+---------+---------+---------+---------+---------+---------+---------+

+----------------+-------------------------------+------------------+
|                |              Real             |       Total      |
|    DRVs        +------------------+------------+------------------|
|                |  Nr nets(terms)  | Worst Vio  |  Nr nets(terms)  |
+----------------+------------------+------------+------------------+
|   max_cap      |      0 (0)       |   0.000    |      0 (0)       |
|   max_tran     |     11 (66)      |   -0.327   |    203 (1811)    |
|   max_fanout   |    607 (607)     |    -32     |    639 (639)     |
|   max_length   |   5102 (5102)    |   -2525    |   5102 (5102)    |
+----------------+------------------+------------+------------------+

Density: 63.937%


从结果看，反标path violation的，结果要好于反标clock latency的。至少就我目前这个设计来说，是这个结果，不知道算不算个例。对于新的设计，貌似这两种方法，都可以试试，兴许某种会更好。

noel_zhang

这个好贴应该收藏一下，希望还有更好的方案出来继续讨论。

taotao_ic

大家讨论的那么激烈，我也凑个热闹
（1） 关于工具自动产生CTS的spec，这里我也顶Timme一下。一般来前端的人写SDC，基本都是从逻辑和timing的角度来说，对时钟的物理关注得相对少些，比如改从哪里分叉，从哪里断开。所以不太可能写出一个完美的sdc既适合STA有和时钟树很吻合的。
（2） 对于CCopt使用的几个关注点，个人认为有以下3点
        a. initial virtual clock tree的结构，这也就是Timme提到的target_insertion_delay, skew group的控制.
        b. hold time 的控制，ccopt 最大一个risk就是用得过量后，导致hold 无法收敛。这个在multicorner下尤为麻烦。所以不要太贪心。
        c. timing ECO , 原来大家习惯去在clock tree上加减buffer来fix timing的方法，在ccopt过的design上就很难用了。

xiaobobolin

感觉很牛的样子，小白学习

uestccfj

学习中.............

raga21

Thanks, Its nice info...

lightcloud

刚用ccopt,遇到些问题。
1.发现在database里生成了latency.sdc.在postcts优化后，计算timing,会考虑这个latency.
并且有负的latency,这样对吗？
2.ccopt -cts是否会优化skew,还是象传统cts一样只做clock tree?