The-OpenROAD-Project / OpenSTA

OpenSTA engine
GNU General Public License v3.0
388 stars 168 forks source link

SPEF not being annotated to internal netlist nodes #102

Closed NeilHoward closed 1 year ago

NeilHoward commented 1 year ago

Annotating SPEF onto top-level module ports seems to work OK. (as apparent in generated file results_run1/9_opensta_slack_sta.rpt) However, annotating SPEF onto internal wires results in the warning: Warning: xxx.spef line nn, pin yyy not found. and there is no annotation. This is demonstrated by 'run1'.

'run2' is the same as run1 except that the internal node between the 2 flops, 'net1' has been changed from a wire to a port (inout). This run shows that the warning no longer occurs. There is still no annotation value (results_run2/9_opensta_full_sta.rpt, line 75, column 11) This may not be considered a valid issue as the port is an inout. The sole purpose of run2 is to show that the warning is no longer reported.

20220713.tar.gz

jjcherry56 commented 1 year ago

The testcase should include ALL of the data to run. I is missing sky130_fd_sc_hd__tt_025C_1v80 but I found a copy of it.

The error message is: Warning: run1.spef line 61, pin net1 not found.

and indeed, net1 is not a pin, it is a node. The spef is incorrect. Capacitors are between pins or internal nodes, not nets.

jjcherry56 commented 1 year ago

The correct syntax is:

D_NET 4 5.67e-12

*CAP 0 u1:Q 5.67e-12

*END

Referencing what you think is a "top level net" is really referencing the port which as the same name in the verilog world but is not the same object. Ports have locations, nets are spread out all over.

jjcherry56 commented 1 year ago

If you are just trying to annotate capacitances (that does not look like a spef from a parasitics extractor) you can use the set_load command:

set_load .2 net1

NeilHoward commented 1 year ago

Thanks. What you say makes sense!

However: the SPEF originates from Cadence Quantus(PVS) - a reputable source!

It uses the NAME_MAP to abbreviate names (like VCD does). But all of the names being abbreviated are nets, not pins: [[ NAME_MAP 1 uRW3.Dsi[0] 2 net50 3 n0869 4 net45 *5 uRW3.u_dsi.data[26] ]]

I'm only seeing the ':' notation being used for SPEF generated for coupling between nets rather than lumped to ground... [[ D_NET 13118 3.14632e-15

CAP 0 13118:1 6.49126e-17 1 13118:2 2.94425e-16 2 13118 1.06351e-15 3 13118:2 13107:6402 2.99836e-18 ]] So the last line is a cap between the net abbreviated as 13118 and the net abbreviated as 13107 - which happens to be VDD. It is as if every net is being made into a component. Some 'net components' like VDD have lots of pins - it is connecting onto the 6402nd pin of the VDD component.

Where there is just lumped cap, it is just [[ 0 13118 6.49126e-17 ]] where 13118 is a net.

I don't see how to configure the format to suit. I'll investigate further.

Changing to set_load is made more complicated by the abbreviations but may be the best solution though.

Thanks.

jjcherry56 commented 1 year ago

Nothing in your last response corresponds to the testcase you posted. Your comment "So the last line is a cap between the net abbreviated as 13118 and the net abbreviated as 13107" is not correct. Although 13118 is a net, 13118:6402 is an internal node in the net. A D_NET describes detailed parasitics with resistors and capacitors but this is not even close to detailed. Is there some configuration in the extraction to only end up with capacitances? I would say that this does not match the spef spec.