<magma talus> reg2out path check result mismatches PT?

[chris_li]

Hi Guys, I found, in default, "data required time" of reg2out path for talus built-in timer does not account for "clock network delay"(terminology of PT). In simple, it calculates "data required time = clock period - output_delay" while PT do in such way: "data required time = clock period + clock network delay - output_delay". Therefore, the slack result mismatches PT. Anyone who know why it is?

Many thanks.

 

[jeevan.life]

Hi Chris

Is your clock path delay computed? Can you please put in a snippet of the timing report? Is your clock propagated?

 

[chris_li]

Hi Chris

Is your clock path delay computed? Can you please put in a snippet of the timing report? Is your clock propagated?

Yes, computed(propagated) mode, after "fix clock"(CTS built) even the same result after "fix wire".

I run at the block-level rather than top-level, I guess talus does not update latency or other reasons.

I assume the entire path should be "reg2out(A block) -> in2reg(B block)", and there is no capture clock latency of "in2reg" and no way to get. In such case, I think either adding a estimated latency in setup computing or just focus on datapath delay of reg2out if met? What do you think about?

 

[chris_li]

Hi Chris

Is your clock path delay computed? Can you please put in a snippet of the timing report? Is your clock propagated?

Hi Jeevan,

Here is the header of report from Talus, pls note clock period is 5000ps while output_delay is 2000ps

Reference arrival time ******************** 0
+ Cycle adjust (clk:R#1 vs clk:R#2) ********5000
- Setup time************************ -2000
------------------------------------------ -------
End-of-path required time (ps) ***********3000


Starting arrival time **********************0
+ Clock path delay *********************1368
+ Data path delay ********************* 2010
------------------------------------------ -------
End-of-path arrival time (ps) ************* 3378

As above, the setup check of reg2out path failed distinctly, but it is not true as clock latency of capture path is not added, I think.

ICC/PT really account for capture path clock latency, thus setup in ICC/PT is met.