icc pad timing疑问
请问各位：
双向IO，带上拉（可配置）。
PAD已经设了set_drive 0(无限驱动能力)，set_load 0（最小的load）。
另外，lib中PAD本身的cap为5.42.
PAD上有4.12ns的delay，怎么来的?感觉没有道理，怎么去除?
请高手讲解，因为这个delay太大了，PAD到reg的timing不能meet。
谢谢！
pad delay就是4~8ns这么大的，很正常，因为驱动pcb上的电容很大，
可以调整io 约束来达到timing
core到pad 外面的delay很大，反过来，pad进core里面delay很小，在1ns以内，一般
icfb小编大哥，我还有疑问，请帮忙解答。1.我没办法理解这个4.12ns的delay的来源在哪里?从*号判断，这是icc反标上去的，那么它一定是经过计算得到的值，通常应该是根据.lib(.db)来查表得到吧，但是.lib中只是描述了输入时PAD-->C及IE（input en）-->C,输出时I-->PAD及OEN-->PAD的table。那么这个input port（mcu_p20_PAD）到pin(mcu_p20_IO/PAD)之间的delay根据什么计算出来的?从图中只能看出这个PAD本身的cap比较大，但是这个信息量不够啊。
2.项目中类似的PAD有一批，mcu的PAD，你懂的。比如mcu_p21_PAD这个点delay value=4ns,mcu_p10_PAD同样位置的delay value=1.54ns，个个PAD（选了同样的 io libcell）都是不同的。咋理解?
3.咱们论坛以前有人问过类似的问题，有人说双向IO输出可能反馈到输入。跟这个有关系吗?就算是有反馈的情况，也得在.lib中有路径有table才成立吧?如果没有相应的路径和table，反馈就是没有根据的，我不可能disable掉一个根本部存在的路径，对吗?
你看.lib 里面， I到PAD的delay就是这个值， 从pad到C的值就比较小，
非常感谢大侠 的回复，我还得继续追问，请不要嫌弃！
我的路径是报告从PAD-->IO/C-->reg,也就是是input到reg的timing，为什么tool要把输出路径I-->PAD的delay加到我的输入路径上呢?而且加在最前端，相当于是报告I到PAD再到C再到reg的timing了，这个很怪异啊?
求牛哥s继续解答我上面的疑问，谢谢。
发整条路径report，完整的
已经贴了完整的report，这个report在mcu_p20_PAD(port)与mcu_p20_IO/PAD(pin)之间有4.71ns的delay就是我不解的地方。谢谢。
report_timing -input_pins -nets -cap -trans 看下
可能是你set_load 了太大了，那个双向io还要接受cap的影响的
不好意思小编哥，可能你没看清楚我的贴图或者我的贴图有问题你看不到。
1.上面报告的timing就是用你说的这条命令报的，起头部分已经有交代。set_load已经特意设为0了。set_drive也特意设为0了。就是为了找到这个奇怪的delay。
2.实际上我尝试了set_load、set_drive为其他值，都完全部影响上面提到的哪个4.71ns的delay。它怎么弄都不变。
3.我尝试用set_annotated_delay把这个位置设为0，然后报告timing，4.71ns就没了。但是接下来只要我用了place、clockopt、routeopt等任何一个命令，然后再报timing，那个4.71ns就又回来了。这是我非常不解的地方。icc到底根据什么提取出来又反标在这个位置的?（我的其他IO：比如p21、p22用的都是完全相同的lib cell，只是坐标不同，一个挨着一个，他们在这个位置的delay分别是3点几ns，0点几ns，总之每个PAD的delay都是不同的。）
多谢小编哥，请在有空时继续跟踪一下我这个问题。
可能是那个port 不在pad上， 比如哪个port在 die boundary的其他地方，距离那个pad的port位置（通常是pad中心点或出terminal的地方）很远
icc现在有些版本有这个问题， 就是port 不在pad上，就造成了这个问题， 你change_selection [get_ports xxx]看看 ，
你好小编哥，周末没有太及时跟帖回复，不好意思。
我用您说的命令看了，非常确认目前的port位置是在：IOcell对应的那个terminal的正中心位置，不存在偏离或者远离pad的情况。（IO选用库smic55nlld2rp_ov3_v0p5 PBCU4R）