What does multi-corner support using ORFS entail?

[oharboe]

Today ORFS supports a single corner at the time, but what would it mean to support multiple corners?

I don't think the quality of results would be affected, there is no multi-corner optimization in OpenROAD. A single corner is used to drive the flow, such as for repair timing and timing driven placement.

This leaves reporting and abstract generation?

Does the OpenROAD GUI support any form of multicorner support, such as a dropdown to pick corner in report timing view, slack histogram, clock tree and other relevant views?

In lieu of a drop down, would it be valuable to be able to open the GUI overriding export CORNER?=XXX used in the flow and thus view reporting for a different corner?

If I were to use ORFS unchanged today to set up a flow in bazel-orfs using the instructions from the OpenSTA manual, I would write two small .tcl scriptlets for my design:

1. Write a design specific multi-corner.tcl that generate abstracts the normal way by sourcing generate_abstract.tcl, then read in the non-default corner .lib files and write out .lib files for each corner.
2. Generate the top level design using the default corners
3. Write a small report.tcl script that reads in top level design using default corner, then read innon-default corner .lib files and run report_checks(or whatever I want to extract in terms of information).
4. Write some sort of test using the multicorner reporting. Perhaps check that there's no negative slack.

@dnltz @maliberty Thoughts?

[dnltz]

I might be wrong but isn't the "Timing Analysis with Multiple Process Corners" already implemented in ORFS? It can read multiple liberty for different corners. I also reports checks with worst and best corners.

I rarely use the GUI and that might indeed lack some support for multi corner.

[oharboe]

There are code fragments that are not used in tests, nor documented, which does not meet my definition of "implemented"...

This thread is about clarifying what "implemented" means to different stakeholders.

[maliberty]

sta supports multi-corner analysis. set_wire_rc can also take a -corner. So the infrastructure is there. Timing repair should use the relevant corner (setup=max, hold=min). @precisionmoon can you comment on rsz/cts and corners?

In general corners will affect the result as optimization will see different timing.

[precisionmoon]

CTS uses liberty and timing from the "sta::cmd_corner". If you do "define_corners wc typ bc", the cmd corner is the last corner: bc.
If you want to use a specific liberty not associated with a corner, you can use "clock_tree_synthesis -library liberty_file".

[gadfort]

@precisionmoon any reason to not use the "max" corner instead of the last defined corner (that is surprising to me).

[precisionmoon]

cmd_corner selection is by OpenSTA. Instead of relying on cmd_corner, we can enhance CTS to pick the "fast" corner by default (this is a little tricky though). But we have -library option to override this.

[gadfort]

@precisionmoon can you point to the code that does the corner selection? (-library isn't a corner, so how does that apply?)

[precisionmoon]

Actually, corners are defined as StringSet (see "StringSet.hh"):

typedef Set<const char*, CharPtrLess> StringSet;

So corners are sorted alphabetically and the cmd_corner is simply the first one.
Sorry, my regression had "define_corners ss tt ff", and the cmd_corner was ff so I had assumed it was the last entry.

Is this the best practice? I'm not sure...

[maliberty]

@precisionmoon let's work on a plan to do optimization considering multiple corners at once.