Behavior difference between LEF/DEF DRC and GDSII DRC

[donn]

In the following reproducible, the first variable is MAGIC_EXT_USE_GDS.

When set to 1, DRC passes without a hitch.

When set to 0, DRC fails:

user_project_wrapper
----------------------------------------
Metal2 spacing < 0.14um (met2.2)
----------------------------------------
 1235.420um 402.760um 1235.540um 402.830um
 1235.420um 402.715um 1235.540um 402.760um
 1235.280um 402.760um 1235.400um 402.830um
 1235.280um 402.575um 1235.400um 402.760um
 1235.280um 402.575um 1235.400um 402.715um
 2055.600um 402.080um 2055.720um 402.150um
 2055.600um 402.035um 2055.720um 402.080um
 2055.460um 402.080um 2055.580um 402.150um
 2055.460um 401.895um 2055.580um 402.080um
 2055.460um 401.895um 2055.580um 402.035um
----------------------------------------
Metal2 width < 0.14um (met2.1)
----------------------------------------
 1281.420um 2289.970um 1281.490um 2290.040um
 1611.840um 400.180um 1611.910um 400.250um
 2061.190um 400.860um 2061.260um 400.930um
 2061.120um 400.250um 2061.190um 400.270um
 2074.140um 401.540um 2074.210um 401.610um
----------------------------------------
[INFO] COUNT: 15
[INFO] Should be divided by 3 or 4

From what I can see, it appears that the metal connections at the aforementioned points are somehow not being captured properly in DEF/LEF..? Can you confirm?

repro.tar.gz

[donn]

I've investigated further- one of the nets with the problem is io_oeb[0] and it appears to be properly connected in the DEF file:

 io_oeb[0] ( PIN io_oeb[0] ) ( mprj2 io_oeb[0] ) ( mprj1 io_oeb[0] ) + USE SIGNAL
      + ROUTED met2 ( 1184730 999260 ) ( 1186800 * 0 )
      NEW met2 ( 1183810 1048800 ) ( 1184730 * )
      NEW met2 ( 1184730 999260 ) ( * 1048800 )
      NEW met3 ( 1179900 1599700 ) ( 1183810 * )
      NEW met2 ( 1183810 1048800 ) ( * 1599700 )
      NEW met3 ( 1179900 2286500 ) ( 1185190 * )
      NEW met2 ( 1185190 2286500 ) ( 1186800 * 0 )
      NEW met4 ( 1179900 1599700 ) ( * 2286500 )
      NEW met3 ( 1380 2145740 0 ) ( 1179900 * )
      NEW met3 ( 1179900 2145740 ) M3M4_PR
      NEW met3 ( 1179900 1599700 ) M3M4_PR
      NEW met2 ( 1183810 1599700 ) M2M3_PR
      NEW met3 ( 1179900 2286500 ) M3M4_PR
      NEW met2 ( 1185190 2286500 ) M2M3_PR
      NEW met4 ( 1179900 2145740 ) RECT ( -150 -620 150 0 )  ;

But other than that, I'm at a loss.

[RTimothyEdwards]

@donn : The tarball is decidedly not reproducible as it makes references to GDS and LEF files of the macros in the non-existent directory designs/.

If I had to take a stab at the answer, though: When you don't use MAGIC_EXT_USE_GDS, the script normally (I think) is expecting that magic will find the layout of all the files in .mag format from the PDK. That will work fine for a standard cell layout. If you read in macro cells that are not part of the PDK, and you aren't reading the GDS, then presumably you're reading the LEF views? In that case, you might find discrepancies, depending on how the LEF was generated. But I would need the two LEF and two GDS files to investigate.

[donn]

Argh, sorry about that- the reproducibles are still buggy. Here you go.

To be clear though, I am reading all external cells in both LEF and GDS formats.

repro.tar.gz

[RTimothyEdwards]

The first error in the list, at 235.42um 402.76um 1235.54um 402.83um, shows up as a narrow gap between a contact at the route attached to it, which makes an immediate bend down. This gap is sitting over top a macro pin, so it is not an error as long as the macro is there.

I notice that there is a difference in magic's handling of the GDS file for user_proj_example.gds vs. user_proj_example2.gds which is probably the source of the problem. user_proj_example2.gds has a library name of user_proj_example but a cell name of user_proj_example2. I expect that magic is confusing the GDS library name with the cell name from the other library. Magic often assumes that if a library name is the same as a cell name, then it will automatically load the cell into the current layout window. If not, it won't. I couldn't tell you without investigating what is the behavior if the library name is the same as a cell name in memory but not a cell name in the GDS.

I do know that manually reading each GDS followed by reading the DEF ended up in a hopelessly confused state, with one of the GDS cells getting lost completely, which would explain the DRC error, since the macro has to be there in order for the pin to cover up the gap that otherwise is a DRC error.

[RTimothyEdwards]

FYI, if I do something like running the command load test before loading the GDS, and I use a different name before each GDS read, then everything works okay. I expect that this should be treated as a magic bug, not a "feature", but I have to do some more testing before I can figure out what common-sense interpretation magic might be violating.

[RTimothyEdwards]

I've sort of pinned it down. The user_proj_example library name gets turned into a cell, so that when the actual cell user_proj_example is read, it issues the warning Warning: cell user_proj_example already existed before reading GDS!. I will have to think about how to differentiate this from the use case where the GDS contains only data and no cell, which is when the library name is used as a cell name. Maybe delete the library cell if it has no contents after reading the GDS? I'm sure there's a sensible way of dealing with it.

[RTimothyEdwards]

@donn : The easiest solution is to add to your script gds library true before you read the GDS. Then magic does not try to interpret the library name as a cell name, and just reads the GDS contents into memory.

[donn]

Thanks for the info Tim. Will try when I'm home.

[donn]

Argh- sorry for the confusion: I read GDS cells with DEF reads for KLayout, not Magic. The DEF/LEF read does not actually read cell GDS files. So I'm not entirely sure if gds library true is applicable: the GDS DRC is the one that actually works, not the one that fails.

[RTimothyEdwards]

You would still need to read the GDS into magic to get that specific DRC error report from magic.

If I read just the LEF macros and then the DEF file into magic, I do get DRC errors, but not those specific ones, which are clearly related to a missing cell view underneath the routing. Instead, the DRC errors I see relate to the placement of vias too close to the obstruction layer that defines the area in which to avoid placing routes. Either the router is using a different view for the macro, or else it is not honoring the wide-spacing rules for metal (which is a problem that I thought was fixed a long time ago).