SDF duplicate MUX IOPATH paths with different delays

[cloudxcc]

Description

The S-> X IOPATH of MUXes are duplicated in the SDF file and have different values:

SDF file snipset:

(CELL
(CELLTYPE "sky130_fd_sc_hd__mux2_2")
(INSTANCE 344)
(DELAY
(ABSOLUTE
(IOPATH A0 X (0.159:0.159:0.159) (0.268:0.268:0.268))
(IOPATH A1 X (0.125:0.125:0.125) (0.243:0.243:0.243))
(IOPATH S X (0.233:0.233:0.233) (0.341:0.341:0.341))
(IOPATH S X (0.163:0.163:0.163) (0.279:0.279:0.279)) <--- second arc with > 60 ps difference
)
)
)

This is most likely true for all MUXes, but not for other cells.

Environment

Tested on latest mpw-7a (but seen it before):
OpenLane f9b5781
PDK version 41c0908b47130d5675ff8484255b43f66463a7d6

Reproduction Material

Latest caravel example:
git clone -b mpw-7a https://github.com/efabless/caravel_user_project caravel_example

Expected behavior

Only one entry per arc.

PS: also wondering why bc:nc:wc numbers are identical at many cells.

[jjcherry56]

Those are IOPATHs with different COND expressions that for some reason are not printed in the SDF.
The bc:typ:wc values are the same because there is only one process corner and the no min/max slew spread.
Without an explicit testcase (ie, a tcl command file that produces the SDF) I can't help you any further.

[cloudxcc]

The explicit testcase is given in the text above. Use the actual, mpw-7a, default caravel_example project with all the default scripts that come with it.

git clone -b mpw-7a https://github.com/efabless/caravel_user_project caravel_example

The earliest SDF file I have quick access to is from Dec '21 where I was fooling around with MPW-3. Same problem there, so I guess you can find that issue on any given Openlane SDF file.

[maliberty]

The expectation is that you will package a standalone test case. See https://github.com/The-OpenROAD-Project/OpenLane/blob/master/docs/source/using_or_issue.md

@donn can help if required.

[jjcherry56]

It looks like the issue is the sky130 liberty.
cell sky130_fd_sc_hd__mux2_1 has these timing arcs from S -> X
pin ("X") {
direction : "output";
function : "(A0&!S) | (A1&S)";
timing () {
related_pin : "S";
timing_sense : "positive_unate";
timing_type : "combinational";
}
timing () {
related_pin : "S";
timing_sense : "negative_unate";
timing_type : "combinational";
}
}

They should have sdf_cond attributes to label them for the SDF.

[cloudxcc]

@jjcherry56 Conditions in the SDF file ? Is this possible ?

So I guess that both paths are valid and my STA engine should take the most critical one, right ?

[maliberty]

There is syntax to support it in SDF:

The timing engine will select the right arc. However your SDF is not valid because it lacks the COND statements for the reason Cherry describes above.

[maliberty]

I opened google/skywater-pdk#382 for this issue.

@mithro @QuantumHD please advise if you will fix this in the upstream repo or not

[mithro]

Unlikely to happen in the next few weeks. Best bet is to add something to open_pdks temporarily.

[maliberty]

@RTimothyEdwards @donn I'll leave it to you guys to hack the .lib in open_pdks. This isn't an OR issue.

[donn]

@RTimothyEdwards You're up.