CTS时序分析问题

想问下再做完CTS（clkroute 已布）时，clkpath上的net和datapath上net的寄生参数的提取不同在哪?我感觉clkpath上的net已是detailroute,它应该是captable中定义的，而datapath上net还是trailroute,它的寄生参数是不是来源于lib库中的WLM，不是很确信。

怎么没人帮我回答下?

你的理解是正确的
我没有用过encounter，对你说的那些专业名词不是很清楚，不过EDA软件原理都差不多的，做完CTS后，时钟树已经生成，clkbuf,clkint位置已经确定，时钟布线已完成，clock path的物理参数已经确定了，但还没有进行布线，故data path的物理参数还是预估值

我覺得應該都是從cap table來的。但是trialRoute是global route，所以routing pattern尚未確定。比較大的差異應該是此時的extractRC mode是屬於postCTS，而不是detail/signoffmode

encounter里面有2个提取RC的方法，一个是自带的，速度快，精度差，用在detail route之前。
另一个就是QRC，在detail route之后，可以直接调用它。
两个都比WLM强很多，在encounter里面，基本上就没有WLM了
在clock net已经detail route，而signal net还是trial route时，好像用自带的那个

wire load model在后端几乎没用了， 因为后端有virtual route模型，比如elmore delay
awe delay，没有实际的route，但是有globalroute ，trialroute 也能计算的， 不会用到WLM ，
cell delay永远是查找表来计算，根据input slew和output load，这个preroute 前后没有区别，
net delay就很大区别了，route之前是根据elmoredelay，即virtualroute ，global route，trial route来计算， 不是十分精确，比如data path上的delay，因为那时候的RC是不精确的， slew的不精确造成
cell delay的不精确，这个都是互相影响的，
postroute以后，比如cts后， 有了real route，RC的抽取就精确了，net delay和cell delay的计算就更加准确些，

比如route之后的 arnoldi 模型，就是更精确的模型，
elmore -> AWE -> arnoldi,timing的计算是越来越精确的

谢谢小编们的回答，我明白了些，我总结了下，我能不能这样理解，trilroute的RC也来源于captable，只是在抽取时利用了不同的engine（IQRC--TQRC--QRC）,由于engine的不同，导致提取RC时利用的计算模型（elmore -> AWE -> arnoldi）也就不同?另外lib库中wire_load是DC时用，encounter中就用captable?

差不多的，就是engine不太一样，
wire-load 在后端几乎就没有用了

学习了 很好！