open-source-silicon.dev

Greetings,
Q1: Is it possible to report the shortest setup path in OpenSTA ? (not to be confused with hold-time check)
I’m thinking of moving from my own (hobby-level) STA engine to the way more professional OpenSTA tool, but I need at least the shortest setup path. Do I miss something in the OpenSTA docs  ?
Q2: Is it possible to display a timing histogram in OpenSTA ?
Thanks a lot in advance.

<https://github.com/The-OpenROAD-Project/OpenSTA/blob/master/doc/OpenSTA.pdf>

Using OpenROAD GUI you can trace the timing path as contain built-in OpenSTA timing engine

<@U0268926L04> Thank you as always. I was aware of the documentation, where I couldn't find an answer to my questions:
Q1: Is it possible to report the shortest setup path in OpenSTA ?
It seems as if the OR GUI does not add features to answer this one:
Q2: Is it possible to display a timing histogram in OpenSTA ?

1 - Do you mean in terms of levels or delay?  How would you use it?
2 - Not yet but see <https://github.com/The-OpenROAD-Project/OpenROAD/issues/2649>

Thank you <@U018LA3KZCJ>
Q1:
In MPW-8 I have a wavepipelined RISC-V, using timing driven buffer insertion on the netlist to achieve a certain minimal length constraint per path. I do STA on the layout as well (shortest setup), but I would love to do a multicorner backend STA with OpenSTA as well, in particular showing the shortest setup path.
Q2:
AAAAAAh, Awesome. Very nice.
Don’t want to be too pedantic, but I would argue that you NOT only need a single path per endpoint for the wall-of-slack. I think OpenSTA might be limited (don't get me wrong, it's already fantastic) in showing “the complete slack distribution per endpoint” and therefore the shortest setup path as well.

You can trace as many paths per endpoint as you wish in osta.  Its mostly a matter of what you want to see.

Shortest setup doesn't make much sense to me as setup is naturally a max delay property.  Why not use hold for this purpose?

Don’t want to bother you, but in my opinion:
The number of paths through a logic can be very, very large. So this kind of analysis can’t be done with reporting. It needs to be part of in the STA implementation philosophy to generate specific reports.
Hold time uses the same clock. Setup the next (or consecutive) clock edges. The results I’m looking for are based on consecutive clock edges and FF setup checks.
If you are interested in wavepipelining, you might want to check out:
<https://www.cs.princeton.edu/courses/archive/fall01/cs597a/wave.pdf>
Okay, it’s an old idea, but still a lot of fun.

I don't think any timer open or proprietary has this sort of check afaik

Synopsys had it 20-23 years ago when I was fooling around with it.