If so, I would need to add a feature to magic to accommodate it. I have a similar thing in magic but it doesn't have a physical representation like that.

I'm extracting from the

chip_io

gds of the caravel repo

40f091a8

. I see 68/15 in the nearby

sky130_fd_io__res250only___small

but neither 68/13 or 68/13 in

sky130_fd_io__signal_5_sym_hv_local_5term

. Could magic be calculating "m1 resistor" or "m1 short" from other layers on gdsin?

@User: According to the tech file, only 68/13 and 68/15 can get interpreted as a metal1 resistor.

@User I just tried my updated netgen in docker and it gets a segfault in the same place as 1.5.205. In the

FlattenUnmatched

function, around

3441	in netcmp.c

(gdb) p ob
$33 = (struct objlist *) 0x31796b732f30715f
(gdb) p *tc
$30 = {
  file = 1, 
  name = 0x19dc5860 "sky130_fd_io__gpiov2_odrvr", 
  number = 1, 
  dumped = 0, 
  flags = 130 '\202', 
  class = 0 '\000', 
  classhash = 15982189494909831418, 
  permutes = 0x0, 
  cell = 0x19dd1410, 
  objdict = {
    hashsize = 42073, 
    hashfirstindex = 0, 
    hashfirstptr = 0x0, 
    hashtab = 0x1a8f3d80
  }, 
  instdict = {
    hashsize = 42073, 
    hashfirstindex = 0, 
    hashfirstptr = 0x0, 
    hashtab = 0x1a946070
  }, 
  propdict = {
    hashsize = 42073, 
    hashfirstindex = 0, 
    hashfirstptr = 0x0, 
    hashtab = 0x1a998360
  }, 
  nodename_cache = 0x19ddf750, 
  nodename_cache_maxnodenum = 16, 
  embedding = 0x0, 
  next = 0x0
}
(gdb) p tcsub
$5 = (struct nlist *) 0x0

I checked the cell pointer list and it appears to end in a NULL, so I'm thinking

ob

must be getting overwritten somewhere.

(gdb) p *(tc->cell->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next)
$35 = {
  name = 0x19dd6720 "sky130_fd_io__com_padbondpad_q0/VGND_IO", 
  type = 2, 
  model = {
    class = 0x19dd66e0 "sky130_fd_io__com_pad", 
    port = 433940192
  }, 
  instance = {
    name = 0x19dd66a0 "sky130_fd_io__com_padbondpad_q0", 
    props = 0x19dd66a0
  }, 
  flags = 0 '\000', 
  node = 16, 
  next = 0x0
}

@User Looks like this is caused by the change I suggested and was incorporated in 1.5.205. Removing the disconnected nets immediately after flattening, invalidates the pointer list in some cases. Here's

FlattenUnmatched

from

netcmp.c

with some debug statements I added

Fprintf(stdout, "DEBUG: FlattenUnmatched recursing\n");
   changed = 1;
   struct objlist * next_ob = tc->cell;
   while (changed) {
      changed = 0;
      for (ob = tc->cell; ob != NULL; ob = ob->next) {
         next_ob = ob->next;
         tcsub = NULL;
         if (ob->type == FIRSTPIN) {
            /* First check if there is a class equivalent */
            tcsub = LookupCellFile(ob->model.class, tc->file);
            if (!tcsub || (tcsub->class != CLASS_SUBCKT)) continue;
            else if (tcsub == tc) continue;
            if (FlattenUnmatched(tcsub, tc->name, stoplevel, loclevel + 1)) {
               changed = 1;
               break;
            }
         }
         if (next_ob != ob->next) {
            Fprintf(stdout, "DEBUG2: %p %p %d\n", (void *) next_ob, (void *) ob->next, ob->type);
            Fprintf(stdout, "DEBUG2: ob overwrite %s\n", ob->model.class);
         }
      }
   }
   Fprintf(stdout, "DEBUG: FlattenUnmatched done %d\n", loclevel);

I added the

DEBUG2

statements to see if the next pointer unexpectedly changed after recursing. Unfortunately, it does. Looking for a solution now.

@User @User Someone correct me if I'm wrong, but I'm thinking that the current default LVS setup in

flow.tcl

or

caravel/Makefile

will only check the top level of the gate level verilog. Undefined cells are treated as blackboxes with only the pins being checked. This may be ok if each level is hardened, verified separately, and placed as a macro, but otherwise how are the sub-hierarchies verified?

Hello all. I tried performing lvs using netgen. I am getting the number of devices and nets same for both the files (layout generated , schematic). But netgen is displaying netlists do not match. I have attached the necessary files here. 123a.spice - Spice file from xschem 123b.spice - Spice file from magic. comp.out - file from Netgen. Thank you in advance. This question is reposted from #magic.

Hello all, I have layed out Mosfets with length L in series to realize a transistor of length L/2 and in schematics i have used a single transistor. How to pass out lvs? Because if I lay out transistors in parallel i was able to use merge command. Is there any such command for this. Thank you in advance.

@User Is there a way to programmatically add

isosub

to layout imported from GDS? Calibre allows you to add layers to individual cells in the rule file, but that's not possible in magic, is it? I'm trying to avoid having to recreate the gds with the

isosub

layer. i was thinking that if the

mag

files were around, one could relatively easily add the

isosub

layers there, but it looks like the extraction script for gds doesn't use/keep

mag

files.

Hello all, I'm trying to correctly run LVS using batch netgen and the SKY130 setup file on a custom-designed cell. The LVS check fails, the number of cells and nets matches and i can't understand the meaning of the error. I'm attaching the netlists, the .mag and the LVS out put, I hope someone here can give me some clues on how to read the comp.out file and solve this issue. I'm using the following command to run netgen: "netgen -batch lvs DFF_v3p1.spice DFF_v3p1_xschem.spice [project_folder]/open_pdks/sky130/sky130A/libs.tech/netgen/sky130A_setup.tcl" p.s.: Since i'm not sure how to run LVS with subck netlists, I commented the magic-generated subcircuit statement manually. I'd really appreciate if anyone could take a look at this!

@User Hopefully, you can clarify some of magic's extraction rules. In the GDS for the

chip_io

block, I'm flattening all the subcells for

sky130_ef_io__vssio_hvc_clamped_pad

with

gds flatglob

before extracting. Looking at the layout, it seems to me that

VSSIO

is shorted to

VSSIO_Q

, but there is no message in the extraction log.

VSSIO_Q

is missing from the spice file. The layout has labels on

met5/label (72/5)

and rectangles and labels on

met5/pin (72/16)

. The

ext

file has both

VSSIO

and

VSSIO_Q

ports that are merged but not directly. There are several intermediate nodes. Is this why there is no warning message? Also, how are the labels and pins extracted? Are labels from both the

pin

and the

label

layers valid? Will a

met5/label

on a

met5/pin

give a valid port?

sky130_ef_io__vssio_hvc_clamped_pad.spice.gz,sky130_ef_io__vssio_hvc_clamped_pad.ext.gz

@User: I happen to have been working on the same cell this morning. The clear issue with LVS here is that the overlay cell shorts VSSIO to VSSIO_Q directly in the cell, and the place where the vias are that short the two pins overlaps the label area, so that without modifying the label areas, there is no place to drop a metal resistor to separate the two pin names so that they can be on independent nets. I am vaguely aware that there are conditions under which the shorted nets don't get reported, but I haven't looked into the specifics, so while your theory about it sounds plausible, I can't confirm it. Magic keeps labels and geometry in completely different records. The handling in GDS is somewhat complicated, but I think the upshot is that the text purpose ends up as the label in magic; the label in magic is associated with a rectangle and a layer type, but that layer type is not actual geometry. It just identifies what layout layer the label is associated with. In the case of VSSIO_Q, the label (one of them) is associated with metal4, but the geometry underneath the label area contains both metal and contact cuts from the overlay cell. Those contacts short VSSIO_Q on metal4 to VSSIO on metal3 directly underneath, and so the two nets cannot be separated unless the VSSIO_Q label is cleanly separated from those contacts. Since the label in question is in the top level cell, I can just modify the layout to keep it from overlapping the overlay cell contacts.

I see an LVS error: devices and pins mismatch. Also, flow failed due to warnings related to power. Attached is the snapshot of the error. Please someone help.

@User I'm trying to get CVC going in openlane using GDS. (

MAGIC_EXT_USE_GDS=1

). I had to make a small fix to openlane so it would read from the gds.spice (vs lef.spice), but I'm now stuck because CVC can't find models for the pfet/nfets. I see some pretty detailed spice modules in the PDK, but CVC doesn't seem to like them (is the CDL format a subset of the spice format?). Also not sure if those models are overkill for this.

@User Does the following line in a magic

ext

file indicate a problem with substrate extraction or is this the default no connection state?

substrate "VSUBS" 0 0 -1073741817 -1073741817 space 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Hi all, is there a way to get Netgen to ignore power pins (so that you can run LVS looking only at logical connections for a layout that doesn’t have power fully routed)?

@User AFAIK, magic doesn't have a way to check for power connections through wells. This can happen when well taps are not connected to the power rails. Would it be possible to modify the extraction rules to ignore well connections, convert the netlists to 3 terminal mosfets, and run LVS. Designs that passed LVS with well connections but didn't pass without well connections would indicate that a well connection existed. 2 terminal devices that had one terminal as a well connection would also need to be removed.

Looks like the above solution works (finds connections through nwell/pwell), at least in some cases. I'll make a repo

sconnect_for_sky130_magic

with all the necessary files and scripts.

The following repo provides a method of detecting connections through nwell or substrate. These connections are not flagged during normal LVS but result in greatly reduced drivability because of the high resistance of wells. This is intended to find errors that would be generated from SCONNECT command in Calibre. It requires magic and netgen but no pdk files (they're included). You should be able to

run_scheck <top_cell> <gds_file>

without any other settings. Feedback is appreciated. https://github.com/d-m-bailey/sconnect_for_sky130_magic

@User I was extracting some of the mpw4 submission and had a question about hierarchical connectivity.

slot-037

is the skull inverter. The inverter input is

A

and has an

li

pin. However, the parent hierarchy does not connect with

li

but rather drops

mcon

directly on the pin. The actual layout should be connected, but the extracted netlist does not appear to be.

.subckt skullfet_inverter Y A VPWR VGND
X0 Y A VPWR VPWR sky130_fd_pr__pfet_01v8 ad=6.2694e+12p pd=2.664e+07u as=4.4307e+12p ps=1.09e+07u w=4.05e+06u l=400000u
X1 VGND A Y VGND sky130_fd_pr__nfet_01v8 ad=4.2687e+12p pd=1.082e+07u as=6.4314e+12p ps=2.672e+07u w=4.05e+06u l=400000u
.ends

.subckt user_analog_project_wrapper gpio_analog[0] gpio_analog[10] gpio_analog[11]
...
Xskullfet_inverter_0 io_analog[1] skullfet_inverter_0/A vdda1_uq1 vssa1_uq1 skullfet_inverter
.ends

@User

@User @User How bad is it if macros are not a multiple of SITE? I see the location of tap cells shifting around this macro. Is this just a bit ugly, or a more critical problem?

I'm using five different macros with different configurations in my digital design. Is it possible to have the same set of GPIO inputs and outputs (io_in[35:0] and io_out[35:0]) for all the macros? Also, the macros are NOT interconnected with each other. Thanks.

@Tim Edwards How can I get magic to extract a cell from a mag view with no devices as a black box? I'm trying to run LVS on a caravel design that has no devices in

user_project_wrapper

and want to check the connections. Currently, magic optimizes out empty cells when netlisting.

@Paul Toth has left the channel

@Matt Liberty has left the channel

@Soumil Jain has left the channel

We’ve added an oeb check to precheck that checks the

io_out

,

io_in

,

io_oeb

, and

analog_io

connections for each gpio. Here are the results for sky130 mpw-3.

The BE verification results for mpw-4 are available here.

@Mohammed Fayiz Ferosh has left the channel