The-OpenROAD-Project
Meta: Top 3 Pain Points of the Toolchain
What are the top three pain points of OpenROAD for chip design?
@antonblanchard @arlpetergadfort @maliberty @proppy
Question is maybe better suited for our chip designers: @kareefardi
Me personally, I have no complaints, just would like a Python interface, which is a monumental effort.
@QuantamHD
- Parasitic extraction, requiring a different tool to jumpstart the PDK bring up
- Yosys/ABC synthesis, generates a netlist that requires a lot of additional work to meet constraints.
I'm sure there are more, but these are the two that stand out the most to me at the moment.
I am not sure what is the state of any of these today but mainly my struggles are:
- automatic macro placement
- signal routing with multiple macros
- (multiple domain) power routing of multiple macros
- System Verilog support in Yosys. The generated netlist doesn't work (probably I am doing something wrong but it isn't an easy flow)
- Power planning and routing
- Timing results are really hard to understand (No hockey stick trend yet)
Lack of timing model generator for hierarchical flows. LEF abstract generator improvements would then follow.
- +1 for "Lack of timing model generator for hierarchical flows". Even a basic (and pessimistic) liberty file generator would be very useful.
- +1 for "ABC/synthesis". We don't pass FFs, manually instantiated standard cells or other black boxed things to ABC, so are missing a lot of optimisations including the ability to do register retiming. I've looked into this but tripped up on what looks like ABC issues.
@msaligane would you elaborate on your last point.
@maliberty This is what I meant by the hokey stick (or knee). Below is the expected timing on a RISC-V core when I push the clock:
This is a reference from [Ketkar, et al ICCAD02] with area instead of power but the two correlates:
So, if I would like to optimize a design, I need to optimize sizing until the knee (sensitivity-based method) and then optimize Vth (out of scope here). I am currently unable to replicate this, but I am not updated on the latest development in yosys/abc.
@msaligane what do you see if you construct a delay/area plot with OR? We do very little with power opt so I don't expect much of an optimal result there.
- lack of packaging and limited surface of the Python API (related to #1424 and #1659)
- lack of machine-readable logs/parameters/metrics export (METRICS2.1?) outside of ORFS (related to #1669)
- cross platform packages w/ gui enabled for OSX / Windows (related to https://github.com/hdl/conda-eda/issues/193)
We wrote a paper on this. See sections 5 & 6: https://dl.acm.org/doi/pdf/10.1145/3400302.3415734
I still believe that most of the QoR gains need to be gained from synthesis (automatic clock gating, physical synthesis - let alone timing-based synthesis). Most of the usability gains need to be from improved documentation, although more automation would be nice too. I'll add another one to the list, which is runtime. I'm actively doing research with this, but a lot of tools could benefit from hardware acceleration and/or algorithm improvement.
To gather issues from the community, and help me understand where I could allocate resources to improve the toolcahin.
People do a lot with the tool, and this thread was helpful to understand the current areas where the tool struggles.
@QuantamHD do you have sufficient input to make that decision and allocate resources?