Add "Show in..." feature to OpenROAD timing paths

[oharboe]

Description

Select a data path row, then right click and get a menu to "Show in ..."

It would be helpful to go from timing paths elements to other parts of the design(backannotation).

Some ideas for features:

• [ ] Show original source code Verilog/RTL code line corresponding to row
• [ ] Show Yosys schematics for original Verilog/RTL as well as current .odb file
• [ ] Display cone of logic or path full path of logic
• [ ] Corresponding .sdc file

Suggested Solution

Implement in GUI...

Additional Context

No response

[maliberty]

@QuantamHD have you been able to get RTL source lines to work in yosys? I recall you were trying a while ago.

[gadfort]

Logic cone might be relatively easy since that is already supported in the inspector. I think source line annotation would require additional support from OpenSTA to provide that information.

[rovinski]

Showing the original RTL from the timing path seems like a doozy which would probably require a lot of hacking in yosys. OpenROAD starts from a netlist which has no idea what RTL went into it. It would require yosys to annotate the source lines into the generated netlist, and then OpenSTA would have to parse those annotations along with the netlist and then expose them through an API to the GUI.

It sounds like a wonderful feature, but I think that an easier stopgap is to look at the source and destination register names (assuming they are unmangled) and infer the source line from there.

[maliberty]

I think the OR work to support this is tractable if we can get yosys/abc to give us the line numbers.

[QuantamHD]

Yeah I have a mostly finished PR in OpenSTA which reads the src line annotations that yosys adds to the verilog. Our flow at Google usually keeps around a good amount of the src line annotations. I'm not sure why the ORFS doesn't. @maliberty has asked me to look into it, but I just haven't had the time. At minimum the DFF's should have line numbers.

[maliberty]

The fact that we use -noattr on write_verilog in flow/scripts/synth.tcl suppresses the annotations. If I turn that off I see line numbers for the ff and some wires though not for the combinational logic.

[rovinski]

I would be pleasantly surprised if yosys had source line annotation of combinational logic, considering it has to hand off between yosys and ABC.

[QuantamHD]

There's an abc pass that's supposed to help with that, but as of yet I haven't been super successful using it.

[oharboe]

This is a little bit of a non-sequitor, but one of the main motivations of LLVM CIRCT was to be able to add the ability to trace back to original source code after numerous passes have processed the RTL. Verilog is quite limited as a format for representing the RTL code as it goes through transformations: synthesis, technology mapping, etc. LLVM MLIR has richer representation available.

If I google, I can find some people who are interested in using LLVM CIRCT representation for yosys and ABC, though to my knowledge, there is no code yet.

https://discourse.llvm.org/t/integration-with-abc-optimizer/65264

LLVM CIRCT is developing quickly, at least I think so, but it still doesn't read Verilog. If LLVM CIRCT gets a really good Verilog parser and later maybe even a VHDL parser, then I can imagine that Yosys and ABC would be motivated to use LLVM CIRCT on the input end and it would only be natural that yosys and ABC would then use it on the output end too.

I understand the LLVM CIRCT parsers to be mainly motivated by the desire to implement a simulator.

Anyway: I don't expect LLVM CIRCT to get to the stage where it is an obvious solution for these things and more overnight, but it will be interesting to follow it's developments.

For now, I use LLVM CIRCT as an output stage for Chisel, which gives me nicer(more human readable) System Verilog output. The QoR isn't affected.