The-OpenROAD-Project / OpenSTA

OpenSTA engine
GNU General Public License v3.0
412 stars 174 forks source link

Wire load table support #203

Closed KrzysztofHerman closed 3 months ago

KrzysztofHerman commented 1 year ago

Is it possible to add support for wire_load_table support ? In the IHP130 OpenPDK we provide the liberty views using the following format:

  wire_load_table ("5k") {
    fanout_area (1, 0.36);
    fanout_area (5, 1.82);
    fanout_area (20, 7.29);
    fanout_area (10000, 3643.7);
    fanout_capacitance (1, 0.0003);
    fanout_capacitance (5, 0.0015);
    fanout_capacitance (20, 0.0054);
    fanout_capacitance (10000, 1.782);
    fanout_length (1, 13.44);
    fanout_length (5, 80.62);
    fanout_length (20, 287.1);
    fanout_length (10000, 94920.8);
    fanout_resistance (1, 0.0072);
    fanout_resistance (5, 0.0434);
    fanout_resistance (20, 0.1544);
    fanout_resistance (10000, 51.05);
  }

Since it is not supported we had to reduce the amount of information using wire_load format which seems to be less informative:

wire_load("5k") {
    capacitance: 0.0003;
    resistance: 0.0072;
    area : 0.36; 
    slope: 14.58;  
    fanout_length(1, 13.44);
    fanout_length(5, 80.62);
    fanout_length(20, 287.1);
}
jjcherry56 commented 1 year ago

I "could", but I'm not sure I see the point. Wireload models are so 1990. Nothing in the openroad/openlane flows use them (after placement steiner tree based parasitics are used).

Blebowski commented 11 months ago

Still, if you use OpenSTA as stand-alone tool, and try to do e.g. post-syn (non-topo) STA on dumped netlist. Using matching wireload as the synthesizer makes sense IMHO...

phsauter commented 10 months ago

I "could", but I'm not sure I see the point. Wireload models are so 1990. Nothing in the openroad/openlane flows use them (after placement steiner tree based parasitics are used).

Actually it is used to evaluate restructured logic and repair timings before anything is placed, see: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/0ea230930b57a6fb517521d8c34cb3591815b596/flow/scripts/floorplan.tcl#L86

rovinski commented 10 months ago

Restructure is currently disabled because it makes the netlist monotonically worse. I think we have someone looking at it now but it's been disabled for a while.

phsauter commented 10 months ago

Its actually good to know that restructure is currently not supposed to be used, I was about to test if I can get some improvement out of it.

At least with the OR version I am running you can actually call the command though. If you do so with the IHP PDK then it will complain exactly about not finding the wire-load tables given in the selection (because of the lacking wire_load_table support.
Personally I think supporting wire_load_table may not be the top priority but it should probably still be on the list. At some point restructure will be used and then it is needed.

The only way I can see it not being useful is if you were to do a mock global-placement directly after floorplan. Then restructure and repair, delete the placement (so it can start fresh) and re-run global-placement.
This way you could just use Steiner-tree routing data instead.

rovinski commented 10 months ago

The only way I can see it not being useful is if you were to do a mock global-placement directly after floorplan. Then restructure and repair, delete the placement (so it can start fresh) and re-run global-placement.

This is basically what OpenROAD-flow-scripts currently does, except it does regular resizing and rebuffering instead of restructuring.

maliberty commented 3 months ago

Issues or PRs should be filed with https://github.com/parallaxsw/OpenSTA if still relevant. This is effectively a fork (though not strictly for historical reasons).