brunope
Newbie level 5
Question about post cts encounter negative insertion dealy
Hi all,
I have been doing some ASIC back end flow for some time now, but I am discovering Cadence tools...
I am facing at the moment something that I don't understand with Encounter.
In post cts stages, in the report timings in reg2reg, I see a negative insertion delay for my launch point.
Please see the example below:
I run:
I get the following:
There are aspects about this:
-I don't understand where this -1.950 ns comes from. I would rather expect a positive value.
-It makes my timing massively wrong
since the capture starts at 0ns (giving 1.950ns extra time for the path).
See below the details of
In STA, I see both launch and capture starting at 0 (as I would expect), with the same set of constraints.
And of course, STA reports me violations since PnR constraints where too relaxed by 1.950ns.
Please find below the details of the full_clock timing report(even though I think the problem is more in "where is this -1950ns for the start point coming from).
Thanks all for your help !
- - - Updated - - -
Hi all,
I found something interesting related to it.
If I do a report_cocks, I see my clocks. Playing with all the options of report_clocks, I don't see anything suspicious.
If after the enclosed report above, a do a reset_clock and then I recreate my clock, as propagated, and re-run the report_timing above, the -1.950 is gone.
After this, looking at the same timing report,the -1.950ns is gone.
And I can't find any difference in the report_clocks before and after, that could explain.
For information, I am using the Foundation Flow, and using Encounter 14.20.
Hope it helps converging to an understanding of the situation ...
Hi all,
I have been doing some ASIC back end flow for some time now, but I am discovering Cadence tools...
I am facing at the moment something that I don't understand with Encounter.
In post cts stages, in the report timings in reg2reg, I see a negative insertion delay for my launch point.
Please see the example below:
I run:
Code:
report_timing -from */*/Q* -to */*/D -path_type full_clock -max_paths 1I get the following:
There are aspects about this:
-I don't understand where this -1.950 ns comes from. I would rather expect a positive value.
-It makes my timing massively wrong
since the capture starts at 0ns (giving 1.950ns extra time for the path).
See below the details of
In STA, I see both launch and capture starting at 0 (as I would expect), with the same set of constraints.
And of course, STA reports me violations since PnR constraints where too relaxed by 1.950ns.
Please find below the details of the full_clock timing report(even though I think the problem is more in "where is this -1950ns for the start point coming from).
Thanks all for your help !
- - - Updated - - -
Hi all,
I found something interesting related to it.
If I do a report_cocks, I see my clocks. Playing with all the options of report_clocks, I don't see anything suspicious.
If after the enclosed report above, a do a reset_clock and then I recreate my clock, as propagated, and re-run the report_timing above, the -1.950 is gone.
After this, looking at the same timing report,the -1.950ns is gone.
And I can't find any difference in the report_clocks before and after, that could explain.
For information, I am using the Foundation Flow, and using Encounter 14.20.
Hope it helps converging to an understanding of the situation ...
Last edited by a moderator: