I'm trying the sky130 support in OpenRAM, using the example config

./compiler/example_configs/riscv_sky130_1kbyte_1rw1r.py

(PS: the 1r1w variants don't work)

magic

segfaults during execution of

run_ext.sh

and therefore no spice file is generated:

Extracting sram_1rw1r0w_32_256_sky130 into sram_1rw1r0w_32_256_sky130.ext:
Total of 5 warnings.
Finished extract
./run_ext.sh: line 38: 21392 Segmentation fault: 11  /usr/local/bin/magic -dnull -noconsole  <<EOF

I'm trying to debug that, but I'm also getting some error messages which I don't know if they should be of any concern or not. For example:

Error:  Asymmetric device with multiple terminals!

What version of magic do you have? Make sure it is very recent. I'm actually working on a docker environment to help with version management.

It's from master

Can you include the .out and .err from your temp directory of the extraction run?

Sure.

It actually looks like netgen seg faulted. That directory doesn't correspond to the previous seg fault..?

What's interesting is that it runs a bit further under debug.

Extracting sram_1rw1r0w_32_256_sky130 into sram_1rw1r0w_32_256_sky130.ext:
Completed 25%
Completed 32%
Completed 39%
Completed 47%
Completed 54%
Completed 61%
Completed 69%
Completed 76%
Completed 84%
Total of 5 warnings.
% Finished extract

I think I found the magic bug!

"under debug"?

oh sorry I might have actually zipped the wrong folder. lemme double check

running magic under lldb/gdb?

yes

There have been recent changes with how it does substrate extraction. I'm using magic 8.3.197

I was finally able to fix the bugs in both magic and netgen. And boy `magic`'s code is pretty scary :)) OpenRAM compiler now concludes and I can see the gds and everything. BUT.. OpenRAM reports DRC errors and LVS mismatches 😕 The report/out/err files are all deleted after the script finishes, so now there's no way for me to know what actually went wrong!

There may be a couple DRC errors in the power routing

Hi @User, I'm working on device level LVS for the mpw-2 designs. I have to flatten some of the openram cells and some substrates aren't extracted correctly. I'd be interested in the changes you made to magic and netgen.

I tried to run the run_*.sh script inside the macro subfolder, but not sure if that's supposed to work or not? From magic I get:

Total DRC errors found: 19

I'm attaching the LVS report. Something is really wrong there. Library setup issue? edit: re-uploaded the attachment below

I'm not sure why @User has to do that as I don't. The most recent errors have been updates to how pins are made in magic and/or compared in netgen

sram_1rw1r0w_32_256_sky130.lvs.report

@User Your issues look similar to the ones I've encountered. Namely, missing substrate connectivity.

Instance: and3_dec_49//pinv_dec_0//nmos_m1 |Instance: and3_decDEC_AND_55/pinv_decpand3 
  (1,3) = (295,2)                          |  (1,3) = (446,2)                          
  2 = 3                                    |  2 = 3                                    
  4 = 1                                    |  4 = 446

This is an nmos with the bulk (4) connected to only 1 net in the layout. Since nmos bulk is the p-substrate, there's no way it's not connected to anything else. Fortunately, the bulk connection of the nmos is a unique node name and I can do a global replace in the extracted netlist. @User I'm using

magic 8.6.225

and

netgen 1.5.208

extracting from the GDS for device level LVS. I haven't looked at the

run_lvs.sh

setup included with openram. On GDS-in, I flatten the

*_nmos_m*

and

*_pmos_m*

cells which may not be strictly necessary, but it makes the extracted netlist more readable. Currently, besides the nmos bulk connection not being extracted, some of the bit_cell's pwell connection is unconnected at higher levels. These bit cells are physically in the same pwell as connected bit cells, so I'm processing it as an extraction problem.

I get tons of these messages when I read gds in magic (before extraction):

Error while reading cell "data_dff" (byte position 9371676): Warning:  Cell data_dff boundary was redefined.

What does this mean and is it related to the issue? Is the gds input broken?

@User those are definitely bleeding edge. I'm not on that new. I'm not at a computer now but posted earlier in this thread what version I had. I'm not sure the effects of flattening those things... You should definitely use my run file.

OK thanks!

I don't remember if I pushed recently. I think I did but I haven't merged stuff yet

Should I be getting it from docker hub? https://hub.docker.com/r/vlsida/openram-ubuntu/tags says not updated in 3 years.

@User I have not released my updates yet.

Thank you! I'll give it a try later.