false hold violations and false negatives on setup violations in floorplan due to mixing propagated clock in macros and ideal clock of top level

[oharboe]

Description

In megaboom there are macros that have a non-trivial network clock insertion latency internally. This causes the floorplan with 0 clock network insertion latency at the top level to believe that there are hold violations.

megaboom uses HOLD_SLACK_MARGIN=-300, so no hold cells are inserted in this case.

In the past, I have seen megaboom gnaw on the problem of how to get rid of these hold violations for a very long time.

Doesn't this case false negatives on setup violations too?

Suggested Solution

Unsure. Modify timing to set network clock insertion latency of macros to 0 instead of using a mix of ideal and propagated clock.

Additional Context

No response

[maliberty]

My plan has been to turn off hold fixing in floorplan which should make this moot.

[oharboe]

My plan has been to turn off hold fixing in floorplan which should make this moot.

What about false setup violations?

If the toplevel has 0 clock latency(ideal clock) and the macro has propagated clock and significant clock insertion latency then there can easily be a false setup violation during floorplan timing repair.

[maliberty]

Whether it helps or hurts depends if it is on the launching or capturing end of the path. Its a good question for @tspyrou as to what is the normal sta handling here.

[oharboe]

Whether it helps or hurts depends if it is on the launching or capturing end of the path. Its a good question for @tspyrou as to what is the normal sta handling here.

I see. I didn't think about the case where a signal is captured inside a macro, but yes: there you get false setup non-violations of course.

[tspyrou]

I think turning off propagated clocks until after cts would help with this. Hold fixing could also be delayed until after cts.

[oharboe]

I think turning off propagated clocks until after cts would help with this. Hold fixing could also be delayed until after cts.

But the macros are already past CTS and they have a clock network insertion latency regardless of whether clocks propagation is turned off, no?

Also, you skipped past the question of what about false timing violations in setup due to network insertion latency in macros.

[tspyrou]

I dont think the network insertion delay would be propagated if propagated clocks are off. @precisionmoon can you comment?

[precisionmoon]

Correct, macro insertion delays should not count in idea l clock mode. Is this not what @oharboe is seeing?

[oharboe]

Correct, macro insertion delays should not count in idea l clock mode. Is this not what @oharboe is seeing?

In floorplan, I see that false hold violations are being repaired, which takes "forever", but I dont have an actual example of false setup violations being repaired.

Next step is that someone who understands this better than me creates a PR for floorplan.tcl to disable hold repair and not to propagate the clock and all should be well?

[maliberty]

The clocks are not propagated in floorplan already. I have a PR to disable hold fixing but if you are right the problem could affect setup as well.

If you "see that false hold violations are being repaired" then you should have an example based on what you see.

[oharboe]

Didnt @rovinski say something like: macros dont have clock insertion latency, only setup and hold requirements"?

If that is the case, why does it matter if you propagate the clock or not?

I will create some examples next time I run across them.

[rovinski]

Macros can have clock insertion annotated on them, but they don't have to. All of that info is captured within the setup and hold requirements of the block terms.

[maliberty]

If you simply move the clock delay into setup/hold it doesn't solve the problem at all. It just become part of another component and there is no hope to remove it from those.

[oharboe]

Macros can have clock insertion annotated on them, but they don't have to. All of that info is captured within the setup and hold requirements of the block terms.

If I understand you correctly, the clock insertion delay is, and must per .lib format definition, captured within the setup and hold requirements. The clock insertion delay is just an optional annotation.

[maliberty]

Yes but if you want to adjust timing for ideal clocks it would have to be there.

[maliberty]

I have nothing useful to add here so I'll leave it up to @tspyrou

[tspyrou]

I would like to see the report_checks with full clock details for the false hold violation.

[rovinski]

If I understand you correctly, the clock insertion delay is, and must per .lib format definition, captured within the setup and hold requirements. The clock insertion delay is just an optional annotation.

Setup and hold requirements in the .lib are specified as a timing arc from another pin (i.e. the clock). So for example, if you had a register with 0 clock insertion delay inside a block, the constraints might look like:

Setup time: 4 ps
Hold time: 2 ps

But if you have an internal clock tree with 100 ps of insertion delay, the same constraint would now look like:

setup time: (4 - 100) = -96 ps
hold time: (100 + 2) = 102 ps

These are both specified relative to the clock pin so these constraints are saying

• Setup: the signal must arrive at the signal pin earlier than -96 ps before the clock arrives at the clock pin (earlier than 96 ps after the clock)
• Hold: the signal must remain stable for 102 ps after the clock

So, the effect of the clock insertion delay is completely captured within the setup and hold constraints. They do not need to be annotated separately for proper timing closure, although it can be useful to know. You might be able to roughly approximate the clock insertion latency by taking the midpoint between the negative setup time and hold time, for example,

(-(-96 ps) + 102 ps)/2 = 99 ps

Which is close to the actual insertion delay of 100 ps.