pt 好像无法正确report carry skip adder 中mux delay timing

我记得以前讨论过mux 的delay 存在问题，我们最近设计csa 的adder 好像遇到这个问题。
carry skip 会在最后一级采用mux ，C0 与C4进行选择。
但是pt report 每次都选择C0—>C1>C2>C3>c4 这条路径，完全失去了skip 的意义。
大家遇到过这个问题吗?有解决方案吗?

这里我想说两个问题，
（1） csa不是carry skip 是carry save
（2） 你说的情况是事实存在，最后的进位位是取决与上级进位位和本级求和值的表达式是否为真，如果为真进位位穿越

pt 只是报最worst 的path， 你可以用-through Cxxx -through Cxxx来报告你想要的path，

逻辑上是这样的：
skip 的原理如下：
adder 的P值为1，则C0参越，P值为0，则C4穿越。
P和C4都是先产生的信号，所以此时P值定了，P为0，则CO就等于C4。
P为1，则结果等待C0，C0为后产生信号，C0穿过。
也就是，逻辑上只存在 C0-》CO 和 A0/B0 -》C1->C2->C3->c4 这两种最worst case.
也就是mux 只考虑 I0、I1端的worstcase，没考虑S的出现，使得 I1最worstcase 在逻辑上不存在。

其实表达式就是 CO= C0&P+ C4， PT应该只去看timing arc。存在C0->C1->C2->C3->C4的路径

存在c0>C1>c2>c3>c4 ，但是这个时候不应该存在c0>C1>c2>c3>c4>CO ,这种情况就该 C0->CO直连了。
感觉要检查出这种，需要PT算得更加仔细。
我印象中，PT有一个option ，可以强制计算路径的上升下降，会变慢PT的计算速度。
就不知道谁能记得这个option 了。

这个看来确实如icfbicfb所说，只能-through Cxxx -through Cxxx 来false_path 了。
上千条啊。

这个逻辑是 CO = C0&P + C4&(！P) 。
C4 = xxxx + C0&P