sky130_fd_sc_hd__fa_4 pin access issue

[antonblanchard]

We are hitting pin access issues with a few cells when using openlane. An example using sky130_fd_sc_hd__fa_4 is attached. Running openlane test.tcl gives:

[ERROR DRT-0073] no ap for _723_/A
terminate called after throwing an instance of 'std::runtime_error'
  what():  DRT-0073

I couldn't make it fail using the OpenROAD flow start to finish, and I narrowed it down to the definiton of sky130_fd_sc_hd__fa_4 in the lef, which is slightly different between the two flows. It looks like open_pdks is picking up the magic version of the lef from the skywater repo, but I'm not 100% sure.

[antonblanchard]

Test case: fa_4-pin-access.tar.gz

[maliberty]

I'm chasing a different skywater issue now but I'll get to this in a while.

[antonblanchard]

I narrowed down the issue to the magic.lef adding an mcon layer to the pins. eg the PIN A differences:

   PIN A
     ANTENNAGATEAREA  0.633000 ;
     DIRECTION INPUT ;
     USE SIGNAL ;
     PORT
       LAYER li1 ;
         RECT 2.080000 0.995000 2.680000 1.275000 ;
         RECT 2.080000 1.275000 2.340000 1.325000 ;
+      LAYER mcon ;
+        RECT 2.450000 1.105000 2.620000 1.275000 ;
     END
     PORT
       LAYER li1 ;
         RECT 3.610000 1.030000 4.000000 1.360000 ;
+      LAYER mcon ;
+        RECT 3.830000 1.105000 4.000000 1.275000 ;
     END
     PORT
       LAYER li1 ;
         RECT 5.645000 0.955000 6.005000 1.275000 ;
+      LAYER mcon ;
+        RECT 5.690000 1.105000 5.860000 1.275000 ;
     END
     PORT
       LAYER li1 ;
         RECT 7.030000 0.995000 7.885000 1.275000 ;
+      LAYER mcon ;
+        RECT 7.070000 1.105000 7.240000 1.275000 ;
     END
     PORT
       LAYER met1 ;
         RECT 2.390000 1.075000 2.680000 1.120000 ;
         RECT 2.390000 1.120000 7.300000 1.260000 ;
         RECT 2.390000 1.260000 2.680000 1.305000 ;
         RECT 3.770000 1.075000 4.060000 1.120000 ;
         RECT 3.770000 1.260000 4.060000 1.305000 ;
         RECT 5.630000 1.075000 5.920000 1.120000 ;
         RECT 5.630000 1.260000 5.920000 1.305000 ;
         RECT 7.010000 1.075000 7.300000 1.120000 ;
         RECT 7.010000 1.260000 7.300000 1.305000 ;
     END
   END A

If I remove the mcon layer from the cell, the original openlane issue goes away

[maliberty]

That lef makes no sense. It implies a bare cut since there is no met1 shape above it. What does the cell actually look like?

At most I think we should add an error on such a lef; I don't think the router should support it.

[maliberty]

Thanks for isolating the problem :)

[antonblanchard]

No problem. I don't understand the differences between the base .lef and the .magic.lef @RTimothyEdwards might be able to help.

[RTimothyEdwards]

The ".lef" files are those that were given to us by the foundry. The ".magic.lef" files were those generated by reading GDS in magic, annotating with the CDL netlist and/or the foundry LEF, and writing out LEF. If you are having to distinguish between files in skywater-pdk, then you're not doing what you should be doing, which is letting open_pdks install the libraries and then using those. That gives you another entire layer of control between what's in the PDK and what the tools see.

[antonblanchard]

@RTimothyEdwards I was just trying to understand why the sky130_fd_sc_hd__fa_4 cell in the merged.lef used in the openlane and openroad flows differs.

The open_pdks install process is placing the magic.lef versions into libs.ref/sky130_fd_sc_hd/lef/sky130_fd_sc_hd.lef, whereas the openroad flow is using the foundry lef.

[maliberty]

@RTimothyEdwards do the gds files have bare cuts in them with no top enclosure?

[ax3ghazy]

@maliberty: The above LEF(s) lists the met1 shapes you're looking for in a separate PORT; it's not a bare-cut pin. I think TritonRoute should be looking to connect through those met1 pins (planarly or with vias dropped from met2) or
planarly on li1. The .magic.lef adds pin shapes for mcon, which, I think, is important so the router knows that it cannot drop mcons on top of some of the li1 shapes, so using the foundry LEFs might result in unexpected spacing issues/shorts that show in the GDS but not the LEF/DEF.

[maliberty]

@ax3ghazy @RTimothyEdwards why are you using multiple PORTS in this case? The pin shapes look strongly connected by met1.

This cell has 5 non-power pins but the image looks like just two. Is this a partial snapshot or am I missing something.

[antonblanchard]

@maliberty it is a partial snapshot. Here is a complete screenshot of the magic derived LEF:

[RTimothyEdwards]

@maliberty : Looks like the last time the files in the PDK were updated was quite a long time ago. Magic does not generate multiple ports there any more; that was a bug that was fixed a while back.