转EDI时钟树人工干预的方法

Posted 2020-12-08 learnsure

 

 

****************时钟树的约束格式***************** 原来的CTS用ctstch文件作为约束，而CCOpt Native直接用命令进行约束，命令基本都能跟ctstch对应上。比如原来的AutoCTSRootPin对应create_ccopt_clock_tree，等等。 无论是原来的CTS还是CCOpt Native，Encounter都提供了sdc转时钟树约束的功能，不过用它做出来的时钟树质量基本是娱乐级的...还是自己重新写一套约束比较好。 *********对需要减小insertion delay寄存器的约束********* 对某些关键路径的寄存器，或是为了优化reg2out，或是为了减小OCV冲击，我们会希望它们的insertion delay尽可能小。在原来的CTS中，我们会通过定义正的MacroModel来将这些寄存器提前，但定义的值很难把握，稍有不慎就会使主时钟树被额外地推后。在CCOpt Native中，可以对这些寄存器创建一个Skew Group，把这个Skew Group的target_insertion_delay设为一个很小的值，工具会自动把这些寄存器提到最前。 *********对需要增加insertion delay寄存器的约束********* 在原来的CTS中，我们会定义负的MacroModel来将这些寄存器推后。在CCOpt Native中，同样是对这些寄存器创建一个Skew Group，把这个Skew Group的target_insertion_delay设为你期望的推后值即可。 与原先相比的改进是，CCOpt Native中可以定义Delay Cell用来推后时钟（当然， 需要库里有上下沿平衡的Delay Cell），以节省面积和功耗。原来的CTS中要想工具自动调用Delay Cell是很困难的。 **************隔离非关键寄存器的约束*************** 在原来的CTS中，我们会把非关键寄存器丢到LeafPinGroup中，并通过一个小的ExcludeBuffer进行隔离，以防止对非关键寄存器的平衡降低主时钟树的性能。但有个局限是，一个设计中的寄存器通常并不能非黑即白地划分为“关键”和“非关键”，还有一些“次关键”寄存器，我们既不希望它们拖慢主时钟树，又不希望这些寄存器被太小的ExcludeBuffer过多地推后。问题是，ExcludeBuffer只能定义一个Cell，而且一旦被丢进LeafPinGroup，各项优化的优先级都会被降到最低。 在CCOpt Native中，只需对关键/次关键/非关键寄存器创建各自的Skew Group，设置好期望的insertion delay值即可。当开启advanced_insertion_delay_optimization和recluster_to_reduce_power两个变量后，工具会自动对“次关键”寄存器用大Buffer/Inverter隔离，“非关键”寄存器用小Buffer/Inverter隔离，非常智能。 *********手动设置target insertion delay的意义********** CCOpt Native在智能度大大改善的同时，还提供了相当多的手工约束命令，乍一看甚是吓人...为什么工具可以全自动完成，还要手动设置insertion delay，这要从CCOpt Native的流程来看。CCOpt Native的流程大致可描述为initial cluster -> optDesign -> adjust skew -> optDesign -> adjust skew...（循环）。如果不手动设置target insertion delay，那工具在initial cluster时会把时钟做成完全平衡的，这时跑optDesign会把datapath往错误的方向优化，很可能后面就回不来了...手动设置target insertion delay后，initial cluster就会把时钟做成你设置的skew值，第二步的optDesign就会收敛得非常快了。 手动设置的target insertion delay不需要特别精确，因为后面的adjust skew步骤里工具会自动帮你Fine Tune。 ***************对Debug的一点Tips***************** 如果你刚刚接触CCOpt Native，那么建议打开ccopt_worst_chAIn_report_timing_too变量，在每一轮optDesign之后都会报一个timeDesign出来，这时候就可以进行Debug了，而不必等到整个CCOpt Native跑完。 ******************QoR的改变******************** 在以前CTS的流程中，preCTS的时序约束通常需要比postCTS更紧，收紧的值约等于时钟树skew值，因为skew可能会劣化Timing。 在CCOpt Native中，postCTS的约束甚至可以比preCTS再紧一点，因为所有的skew都是有益的。这确实是非常令人惊讶的QoR提升... （以preCTS时序约束中Clock Latency已反标为前提） *****************一点改进建议******************** CCOpt Native这种针对Critical Chain的优化，是不能应用于同步链的（如果同步链的skew被借出去就会损MTBF，虽然Timing看起来是Clean的）。希望后续有方便点的方法来照顾同步链...