Can I import yosys netlists in the openroad GUI and examine timing?

[oharboe]

I realize this is an open ended question: How can I import Yosys netlists into OpenROAD and identify any timing concerns in the design?

Is there any documentation, tutorials or examples I can look at?

I think I have seen an ability to select interesting paths and drill down using "select" (yosys command? opensta command?) and filter timing paths, but I don't recall where.

Ideally using ORFS.

This would be more convenient than invoking yosys + open sta directly and interacting with the shell in either.

[maliberty]

You can use 'make gui_floorplan' to open the results after the floorplan step which is pretty quick. We could add an way to directly load the yosys output. In either case you won't see any layout as nothing has been placed but you can use the usual timing path viewer.

You can't use yosys commands in OR as they are different tools.

[oharboe]

I think you showed some commands in openroad gui to examine timing in further detail and to select signals, but I cant find your post.

[maliberty]

In the GUI from Windows->Timing Report you can get the path viewer. When you select items in the path viewer you can see them in the inspector if you need to get more physical/netlist details.

[oharboe]

Thanks!

Are there any examples or docs on how to drill down in these details?

[maliberty]

@vijayank88 are there any tutorials for timing debug?

[dralabeing]

There aren't any yet but we should be able to add this quickly as a video. The visualization part is in the docs here: https://openroad-flow-scripts.readthedocs.io/en/latest/tutorials/FlowTutorial.html#viewing-timing-report. We will plan on making a video for this shortly.

[oharboe]

I think it would also be useful to talk about features that exists in other tools that don't exist in OpenROAD. Either as being on the roadmap or not on the radar. This way users don't have to worry about looking for things that aren't there, or perhaps they can be inspired to work on things which are nearly there.

[oharboe]

I think it would also be useful to talk about features that exists in other tools that don't exist in OpenROAD. Either as being on the roadmap or not on the radar. This way users don't have to worry about looking for things that aren't there, or perhaps they can be inspired to work on things which are nearly there.

[maliberty]

I don't think we can discuss the features of other non-OSS tools. That information is not generally public.

[oharboe]

I see. Yes: obviously not information under NDA, so care has to be taken to only refer to public information: marketing material, youtube videos, etc.

Perhaps use quartus timequest and fpga tools not under NDA as a reference?

I heard about "cone of logic" going into a timing signal. Dont recall where. I understand by this all the sources for combinational logic going into a register, not simply the longest path. This seems like obvious features to anyone skilled in the art would know about.

[maliberty]

Fwiw https://www.youtube.com/watch?v=5lkKp-gL1Ow

[vijayank88]

@oharboe
Only after placement you can trace timing path in OpenROAD gui.
You can refer logs/nangate45/gcd/base/2_1_floorplan.log (gcd example). It is the first OpenSTA timing report post synthesis.

[efis1]

Hi All.
I've requested by @oharboe to comment on some STA analysis requirements vs what currently exist in the ORFS.
I will try to start by dividing this into 3..

1. Currently - Please correct me if i'm wrong, current generated STA reports are related for several steps within the flow, starting from the floorplan, as also @oharboe mentioned, while the debug can be done by the GUI/STA-report per that dedicated implementation step, as I also understand from the Video.
2. Back-End/Physical (starting from floorplan) - It would be great to know if/how we can do/have back-annotation/analysis between different steps of STA violations with help of ORFS/GUI.
3. FrontEnd (Verilog-RTL and Yosys Logical Netlist) - I was able to generate STA reports post Yosys logical synthesis, the issue is that i'm currently lacking flow back-annotation/analysis capabilities/how-to-do between the generated STA reports to the Yosys logical schematic etc., up to the Verilog RTL with correlation to the SDC files. It would be great to know if/how this can be done/mitigated with ORFS/Yosys/OpenSTA.
   It would be also great to know if we can do this analysis bottom up till RTL with help of the OR GUI.

10X a lot for your replies.

[vijayank88]

@efis1
Currently with Automated ORFS, post synthesis we will not do any optimization wrt., timing violations fix.
Only post placement, resizer tool try to optimize and fix timing violations.
@maliberty Can you please add your view, if i missed anything.

[maliberty]

You can really only do back annotation after you reach a fully routed result. There is nothing to back annotate before that. That is already supported in ORFS and the make gui_final will load the parasitics automatically.

You can generate timing report at any step of the flow. Pre-placement you will get wire load models. Later in the flow we use estimate_parasitics with -placement (after CTS) or -global_routing (after global routing). Post-routing we use rcx extracted values.

Yosys 'schematics' are a capability of yosys and have nothing to do with OR. The timing report already contains a list of all the cells/ports/nets so a schematic doesn't add much for a path. In general generating schematics for arbitrary chunks of logic is hard and is essentially another P&R problem itself. Even the proprietary tools aren't great at this beyond a small amount of logic.

[efis1]

Did you mean for "back-annotation-extraction"? such as with parasitic? If so, I didn't mean for that one but for part of the ones which were also presented by @oharboe at issue #3046 ("Add "Show in..." feature to OpenROAD timing paths")

Yosys schematic is indeed currently not part of OR, but everything which yosys produce or even import or may be extended (plugins) can be, right?
Yosys schematic, at least as I've experienced with, may not be connected or annotated with the STA reports or the SDC files.
I think this is where OR GUI may be helpful to load Yosys netlists and create much better schematics which can be annotated initially with STA reports, (all the way up to the RTL/logical-netlists), RTL Source files, later on with power, LEC, etc.

The initial motivations for these are:

1. To handle most of the timing concerns within the RTL/Logic, much earlier than the physical steps.
2. Shorten the STA debug/analysis cycles between the physical and the RTL - find faster STA root cause or correlate it with RTL
3. Having more STA debug capabilities also with the SDC files - debugging the SDC constraints, etc.

[maliberty]

If you have layout you can use the inspector to look at an ITerm and there are buttons to show the fanin and fanout cones

[maliberty]

Here is a tightly package cone on gcd:

[maliberty]

@oharboe is this sufficient info or do you need something more?

[oharboe]

I have been travelling, will follow up next week.

[oharboe]

Will open new more specific questions in the future as needed. This was helpful to improve our understanding meanwhile.