timing path
BeginPoint ：Ａ
EndPoint： B
从path上看从A 到B 的delay 是满足要求的。但是report 总是报告出clock 传播的路径，
这样会导致时序的不满足。少的时候就会放过，最后在STA的时候确认。
但是比较多的时候就麻烦些。
所以请教各位大侠，如何避免这样的情况?
clock展开报的?还是说EDI报的不对，找EDI和PT相同path trace clock的方式是不是不一样，需不需要在EDI对相应的clock追加SDC制约?是这个意思么?
这个A和B应该可能是某个存储体的两个时钟端口、又或者是某一个单元的不同端口?如果是这类路径，就要看实际情况了
对于from A to B 来说，按照EDI 展开的 path 来看， A to B 的delay 比较小，可以满足要求的。
但是由于A端前面带了clock path ，导致报告看起来delay 很大，有比较大的vio。
个人认为不应该带clock path的；但是EDI 又会去report clock 的部分。
不知道这样理解对不对?
这个错误的path 上确实带有SRAM 单元，而且A端就是SRAM的DOUT[X]。
单纯算A 也就是SRAM的output 到B 端的delay 是很小的。
所以这里也请教如何理解此类问题，应怎么应对?谢谢！
这个A 和B 分别对应的SRAM CK and DOUT[X] ，如果单独算A to B 的delay 的话很小，可以met 到timing 的。
但是由于算了clock path ，这样就不满足了。
这里请问改如何单独理解?谢谢！
那个，我还是没太懂
是这样子的report?
startpoint : A
endpoint : B
clk clk_A
PLL/PO
.
.
.
A/CLK
.
.
OUT
data arrival timexxx
clk clk_B
OSC/OUT
.
.
B/CLK
data require timexxx
clock展开的么?
感谢回复！
是下面这样的：
startpoint : A
endpoint : B
clk clk_A
PLL/PO
.
.
.
MROM1/CK
.
.
MROM/OUT[X] <---------------- begin point A
.
.
Port B-----------------> end point B
clock 是展开的。
这里的 endpoint B 是个端口。
A to B delay 3ns，
时钟周期31.25ns
B 端口 output delay 20ns
计算方式如下： arrival time = PLL/PO to B=23.3
reguired time31.25-20-3(uncertainty)=8.15ns
由于arrival time 算了时钟路径，这样就导致有vio
port收数端不带clock么?
如果是和外部连接的，一般可以单独定义clock来对这部分进行验证吧；
或者认为是个别的path，那就另外加约束，把需要的延迟列出来，通过脚本逐个进行判断。
感谢回复！
这个问题可以将外部delay减小可以解决。
但是我的问题是，EDI报告问题的方式是否是正确的?
是不是一定要算clock path?
应该是没有问题的，如果有疑问可以相同的用PT报一下