In the

storage

macro, there are 2 dual port sram instances of

sram_1rw1r_32_256_8_sky130

. In mpw-1, the

csb1

,

clk1

, and

addr1[7:0]

inputs to the second instance were floating and I believe it was decided that it wouldn't be fixed in the first run. As of

commit 1a73bd5

, the inputs still appear to be floating in the gate level verilog. @User @User Can you verify this? Here are the relevant lines from

verilog/gl/storage.v

sram_1rw1r_32_256_8_sky130 SRAM_1 (.csb0(mgmt_ena[1]),
  .csb1(_00_),
...
  .clk1(_09_),
...
  .addr1({_08_,
  _07_,
  _06_,
  _05_,
  _04_,
  _03_,
  _02_,
  _01_}),

Yes, this is a known bug....

@Mitch Bailey

csb1

clk1

and

addr1[7:0]

are tied to logic zero/one. If you check the wires

_00_

_01_

..., you will find that they are connected to a conb_1 cell

oops! Sorry about the false alarm. @Manar Abdelatty thanks for the heads up. @Tim Edwards I got the storage macro to pass LVS but I had to do the following. 1. remove the dummy devices from the memory cells in both the source and extracted netlist. (may be fixable by making the source match the layout) 2. manually short p_en_bar0 and 31 vdd connections. (possibly a problem with magic extraction routines) 3. swap the bus signal order in the top sram spice file. (may be netgen can be modified to match bus indices between verilog and spice) 4. renamed br0_0 -> br0 and likewise for br1_0, bl0_0, bl1_0 in replica_column and replica_column_0 in the source netlist (fixable by either modifying the layout text or source names)

3. This should already match... I don't understand why they should be swapped?

@Matthew Guthaus Thanks for responding. On further consideration, 2. It looks like magic is not connecting nets that should be connected. 31 vdd connections are floating and p_en_bar0 is split into 2 nets. Looking at the layout, things appear to be connected properly, so I'm assuming magic is having a problem extracting correctly. Shorting the nets in the extracted layout gives a clean LVS run. 3. I believe @Tim Edwards told me how to do this correctly a couple months ago. I need to read the spice file before the verilog to get the pin in the correct order. I'll retry and let you know.

2. Yes, this is the GDS flatten issue I mentioned. I extracted and verified with Calibre for this memory so it didn't have an issue.

@Matthew Guthaus I'm comparing the

storage

layout to the gate level

storage

verilog, both from the caravel/develop branch. For the sram macro source, I'm using the

sram_1rw1r_32_256_8_sky130.sp

spice file from the

sky130_sram_macros

repo.

caravel/develop commit 1a73bd5
sky130_sram_macros/main commit 9df5b8b

From the spice file

.SUBCKT replica_column bl0_0 br0_0 bl1_0 br1_0 wl0_0 wl1_0 wl0_1 wl1_1 ... wl0_130 wl1_130 wl0_131 wl1_131

From the extracted layout

.subckt replica_column bl0 br0 bl1 br1 wl0_1 wl1_1 ... wl0_130 wl1_130

You can notice the difference between the

bl

and

br

nets and also the missing

wl0_0, wl0_1, wl131_0, wl131_1

nets. The subcircuit

replica_column_0

is the same. The unmatched wl* lines are not connected to any devices in the source netlist, so probably not a problem. In the source netlist, I changed

bl0_0 br0_0 bl1_0 br1_0

to

bl0 br0 bl1 br1

respectively. Additionally, the layout's

control_logic_r

block has been flattened, so I flatten the netlist subckt similarly with netgen commands.

You should use the .lvs.sp file. The bl and br names shouldn't matter for correct LVS. LVS is ultimately independent of names, but it can be made faster if hierarchical pin names match. Those disconnected wordlines must also be an extraction error. Yes, I flattened the right control to fix some DRC issues, but you shouldn't need to flatten the netlist for LVS... It will just mismatch until the top level.

@Matthew Guthaus My mistake, I was using the .lvs.sp file. The disconnected wordlines are in the source netlist not the extracted netlist. Maybe they are not intentionally used in the

replica_column

subckts. I'll revert the bl/br names and remove the forced flattening to see if the only problem is with extraction connections. I'm manually ignoring the parasitic devices in the bitcells in both the source and the layout.

Are you sure you don't mean the dummy cells? Those bitlines are definitely disconnected. I'm looking at the replica column now and they are connected in the .lvs.sp.

I'm in Japan. The wordlines

wl0_0, wl1_0, wl0_131_0, wl1_131

are disconnected in replica_column. The bitlines merely have a different name. You are correct in that neither of these cause LVS to fail. Rerunning LVS, I need to do the following to get a match. 1. Remove the parasitic devices from the bitcells of the source and extracted netlist. 2. manually short p_en_bar0 (1 nets) and vdd_uq* (31 connections). (not to each other). (possibly a problem with magic extraction routines. @Tim Edwards I sent you a setup to duplicate the results.) 3. swap the bus signal order in the top sram spice file. This has nothing to do with the extracted layout, but rather with the order that the bus signals are mapped from verilog to spice submodules. The only way I can think of to fix this in all cases, would be to require expanded busses in verilog instantiations of spice subcircuits. However, we might be able to add a verilog stub to the calling verilog file that defines the spice bus index order. 4. Need to explicitly flatten some of the subcells of

control_logic_r

because automatic flattening did not work. Here are the results.

Subcircuit summary:
Circuit 1: control_logic_r         |Circuit 2: control_logic_r
-------------------------------------------|-------------------------------------------
sky130_fd_pr__pfet_01v8 (87)        |sky130_fd_pr__pfet_01v8 (5) **Mismatch**
sky130_fd_pr__nfet_01v8 (87)        |sky130_fd_pr__nfet_01v8 (5) **Mismatch**
(no matching element)           |dff_buf_0 (1)
(no matching element)           |pinv_6 (1)
(no matching element)           |pinv_0 (1)
(no matching element)           |pand2_0 (2)
(no matching element)           |pdriver_2 (1)
(no matching element)           |pand3_0 (1)
(no matching element)           |pinv_20 (45)
(no matching element)           |pnand2_1 (1)
(no matching element)           |pdriver_5 (1)
Number of devices: 174 **Mismatch**    |Number of devices: 64 **Mismatch**
Number of nets: 102 **Mismatch**      |Number of nets: 65 **Mismatch**
---------------------------------------------------------------------------------------
Flattening instances of pinv_0 in cell control_logic_r makes a better match
Flattening instances of pinv_6 in cell control_logic_r makes a better match
Flattening instances of pinv_20 in cell control_logic_r makes a better match
Flattening instances of pnand2_1 in cell control_logic_r makes a better match
Making another compare attempt.

Subcircuit summary:
Circuit 1: control_logic_r         |Circuit 2: control_logic_r
-------------------------------------------|-------------------------------------------
sky130_fd_pr__pfet_01v8 (87)        |sky130_fd_pr__pfet_01v8 (54) **Mismatch**
sky130_fd_pr__nfet_01v8 (87)        |sky130_fd_pr__nfet_01v8 (54) **Mismatch**
(no matching element)           |dff_buf_0 (1)
(no matching element)           |pand2_0 (2)
(no matching element)           |pdriver_2 (1)
(no matching element)           |pand3_0 (1)
(no matching element)           |pdriver_5 (1)
Number of devices: 174 **Mismatch**    |Number of devices: 114 **Mismatch**
Number of nets: 102 **Mismatch**      |Number of nets: 66 **Mismatch**
---------------------------------------------------------------------------------------
NET mismatches: Class fragments follow (with fanout counts):
Circuit 1: control_logic_r         |Circuit 2: control_logic_r

You can see that some of the cells were flattened, but not enough to match. At the top level we get

Subcircuit summary:
Circuit 1: storage             |Circuit 2: storage
-------------------------------------------|-------------------------------------------
...
pand3_0 (2)                |pand3_0 (4) **Mismatch**
pdriver_5 (2)               |pdriver_5 (4) **Mismatch**
pand2_0 (4)                |pand2_0 (8) **Mismatch**
pdriver_2 (2)               |pdriver_2 (4) **Mismatch**
sky130_fd_pr__pfet_01v8 (1262)       |sky130_fd_pr__pfet_01v8 (1196) **Mismatch*
sky130_fd_pr__nfet_01v8 (1262)       |sky130_fd_pr__nfet_01v8 (1196) **Mismatch*

By adding the following to netgen's setup file, I get a clean result.

flatten class dff_buf_array_0 "-circuit2 dff_buf_0"
flatten class pand2_0 "-circuit2 pdriver_0"
flatten class pand3_0 "-circuit2 pdriver_4"

flatten class control_logic_r "-circuit2 dff_buf_array_0"
flatten class control_logic_r "-circuit2 pdriver_6"
flatten class control_logic_r "-circuit2 pinv_0"
flatten class control_logic_r "-circuit2 pand2_0"
flatten class control_logic_r "-circuit2 pdriver_2"
flatten class control_logic_r "-circuit2 pand3_0"
flatten class control_logic_r "-circuit2 delay_chain"
flatten class control_logic_r "-circuit2 pnand2_1"
flatten class control_logic_r "-circuit2 pdriver_5"

In summary, @Matthew Guthaus I think the design is ok even with the net name and hierarchy discrepancies. @Tim Edwards we may need to investigate changes to magic/netgen if we want enable device level LVS for designers using sram macros.

I just looked at the spice and they are connected. Unless we are looking at different spice files.

We might be looking at different files! Can you tell me what instance inside

replica_column

wl0_0

is connected to?

@Matthew Guthaus Can I take a look at your LVS setup? Do you run LVS on the GDS or the mag files? I'm using the GDS. The spice file looks like the same one that I'm using. The first and last instances in replica_column are

Xrbc_1 bl0_0 br0_0 bl1_0 br1_0 wl0_1 wl1_1 vdd gnd sky130_fd_bd_sram__openram_dp_cell_replica
...
Xrbc_130 bl0_0 br0_0 bl1_0 br1_0 wl0_130 wl1_130 vdd gnd sky130_fd_bd_sram__openram_dp_cell_dummy

What I was trying to point out is that the

wl0_0, wl1_0, wl0_131, wl1_131

nets are ports in

replica_column

, but have no connections to any instances inside. Again, this matches the layout, but the layout doesn't extract these nets because there are no connections.

I see. I think you mean the layout doesn't extract the ports? The nets may not be connected to anything in that module but they are outside the module. If the module mismatches, netgen will flatten it and run at the next higher level of hierarchy. Also, I didn't use magic/netgen on this design and the design changed since then. My designs are all here including the scripts to run extraction, DRC, and LVS. https://github.com/efabless/sky130_sram_macros/tree/main/sky130_sram_1kbyte_1rw1r_32x256_8

@Matthew Guthaus Thanks. I think I can modify the scripts to work with the sram modules in caravel.

The lef files should be in open_pdks soon too

@Matthew Guthaus I used the

run_ext.sh

and

run_lvs.sh

scripts in the repo, but wasn't able to get a clean LVS result. Wondering if it's a difference in the technology or program versions. I'm using the

sky130_sram_1kbyte_1rw1r_32x256_8

macro from

sky130_sram_macros

commit 9df5b8b

. If it's not too much trouble, could you help me with the following? What version of magic and netgen are you using? Also can I get the

.magicrc

file and

/home/mrg/openram//technology:/home/mrg/data/sky130_fd_bd_sram/tools/openram/technology

files? The clean

sky130_sram_1kbyte_1rw1r_32x256_8.lvs.report

file would also be helpful.

I'm out until 7/21, please ping me again then

Thanks!

No, that is not the result that I got. I got a match...

@Matthew Guthaus Thanks for the response. The parasitic devices didn't match, so I had to ignore both. Double checking, the only difference in the top level result with ignoring the parasitic devices was the run time. I used the scripts that are in the

sky130_sram_macros

repo. If they have the

read spice

statements in them, then I used them. Is it possible to send me your

sky130_sram_1kbyte_1rw1r_32x256_8.spice

and

sky130_sram_1kbyte_1rw1r_32x256_8.lvs.report

files. That would help me track down where the difference is coming from. The top of my

sky130_sram_1kbyte_1rw1r_32x256_8

subcircuit looks like this (no ports),

.subckt sky130_sram_1kbyte_1rw1r_32x256_8
Xwmask_dff_0 vccd1 data_dff_0/clk wmask_dff_0/dout_0 wmask_dff_0/dout_1 wmask_dff_0/dout_2
+ wmask_dff_0/dout_3 vssd1 wmask0[0] wmask0[1] wmask0[2] wmask0[3] wmask_dff

Maybe the tech files referenced in the

.magicrc

file are different. The cksum of my tech file is

1173017678 141540 /openLANE_flow/pdks/sky130A/libs.tech/magic/sky130A.tech

I believe this is generated from the

open_pdks

repo

commit 804f48b18519aa67b1f822bdc352ecbad1c056cb
Author: Tim Edwards <tim@opencircuitdesign.com>
Date:  Mon Jul 5 13:07:07 2021 -0400

@Mitch Bailey: FYI, if you are not getting ports in the top level, then either it is an issue with not using "cif istyle sky130(vendor)" (which you seem to have done), or you are not using "ext2spice lvs" (which sets a lot of things, but the main one here being "ext2spice subcircuit top on" (or "auto").

I am just returning from vacation today so I'll respond later

@Matthew Guthaus Thanks for all the information. I'll take a look at it today and get back to you.

Make sure you are pointing to the correct setup.tcl file from open_pdks

Definitely important. What commit of open_pdks are you using?

1c74f85cd8dbb6c0cf514316b127d746d35d829b

The setup.tcl file is used for LVS, correct? It may be a difference in the magic output, which I'm thinking is related to the tech file.

Yes. I'm also using the .magicrc from open_pdks

@Matthew Guthaus It looks like the

open_pdks

version is tied to the

skywater-pdk

version. Are you using

commit db2e06709dc3d876aa6b74a5f3893fa5f1bc2a6e

of

skywater-pdk

?

I'm using 00bdbcf4a3aa922cc1f4a0d0cd8b80dbd73149d3 of skywater-pdk

Thanks, that helps a lot.

@Mitch Bailey: The

open_pdks

version should be independent of the

skywater-pdk

version. About a month or two ago I started adding commit numbers from the various repositories to a file

sky130A/.config/nodeinfo.json

which makes it convenient to query the version of any of the libraries that went into an install of

open_pdks

.

@Tim Edwards Thanks for responding. Trying to figure out why I don't get the same LVS results as @Matthew Guthaus on the sram macros. When using the following commits in the openlane

Makefile

and running `make pdk`:

SKYWATER_COMMIT ?= 00bdbcf4a3aa922cc1f4a0d0cd8b80dbd73149d3
OPEN_PDKS_COMMIT ?= 7e29496eecf3ee8e1766f1b7f9441f97204d4735

I abort with the following error messages

... Several similar errors
# Custom: Patch the ngspice models to add the HV diffusion resistor subcircuits
patch -p2 -f -d /mnt/mpw/OpenLane/pdks/open_pdks/sky130/sky130A/libs.tech/ngspice \
	< custom/patches/sky130_fd_pr_5.patch \
	2>&1 | tee -a sky130A_make.log || true
patching file sky130_fd_pr__model__r+c.model.spice
Hunk #1 FAILED at 131.
1 out of 1 hunk FAILED -- saving rejects to file sky130_fd_pr__model__r+c.model.spice.rej
# Fix up the PNP model file before running the next modification
head -15 /mnt/mpw/OpenLane/pdks/open_pdks/sky130/sky130A/libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pnp_05v5_W3p40L3p40.model.spice > /mnt/mpw/OpenLane/pdks/open_pdks/sky130/sky130A/libs.ref/sky130_fd_pr/spice/temp
head: cannot open '/mnt/mpw/OpenLane/pdks/open_pdks/sky130/sky130A/libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pnp_05v5_W3p40L3p40.model.spice' for reading: No such file or directory
make[1]: Leaving directory `/mnt/mpw/OpenLane/pdks/open_pdks/sky130'
make[1]: *** [primitive-a] Error 1
make: *** [all-a] Error 2
make: *** [build-pdk] エラー 2

I was thinking that the patches in

open_pdks

didn't apply to the files from the version of

skywater-pdk

that I was using.

This doesn't use OpenLane...

It may be an issue then with using OpenLane to do the open_pdks installation.

Hm. I think I manually installed open_pdks but I look at the command in OpenLane to do it

@Tim Edwards I wasn't able to

make pdk

with

openlane v0.20

or

v0.15

for the following commits:

SKYWATER_COMMIT ?= 00bdbcf4a3aa922cc1f4a0d0cd8b80dbd73149d3
OPEN_PDKS_COMMIT ?= 7e29496eecf3ee8e1766f1b7f9441f97204d4735

I got the same errors that I reported yesterday. I was able to

make pdk

for the default commits in

openlane v0.15

, but

lvs_ext.sh

in

sky130_sram_macros

still extracts the spice without the top level ports. I can add

cif istyle sky130(vendor)

to the extraction to get ports, but it messes up the connectivity. (I get the unconnected vdd nets, etc. that I previously reported.) @Matthew Guthaus Not really sure what to do next. Do you have someone who could check that the sram macros pass lvs in openlane v0.20 with the current pdk? Unless I can extract a correct spice level netlist, I can't run cvc (erc checks).

Hi Mitch, I'm not sure what to do either. I sent you the technology file that I use so you can see any differences. You know all the tool versions. You have the magicrc and setup.tcl. I'm not sure what other unknowns there are?

The tech file references some other files; maybe one of the those is different. But I'm not sure which one if any could be causing a problem. Do you have someone on your side that could running lvs after a clean install of openlane v0.20?

The tech file does? Or do you mean the magicrc? (I don't think most of the magicrc is relevant). Just try extracting with my tech file which is directly from open_pdks

@Matthew Guthaus Thanks for your help. The paths to magic and netgen are hardcoded in the run_ext.sh and run_lvs.sh scripts in the sky130_sram_macros repos. Previously, you mentioned that the versions you were using were

Magic 8.3 revision 160 - Compiled on Wed Apr 28 23:15:07 UTC 2021.
Netgen 1.5.157 compiled on Fri Apr 16 23:46:21 UTC 2021

Could you double check that these are the versions of

/home/mrg/data/sky130_fd_bd_sram/env/conda/envs/sky130_fd_bd_sram/bin/magic

and

/home/mrg/data/sky130_fd_bd_sram/env/conda/envs/sky130_fd_bd_sram/bin/netgen

I edited those paths to point to my system version. I sent you the version on my system.

Great! I'll look into tech file differences.

I modified the magic tech file in sky130 in open_pdks last week to make

sky130(vendor)

the default, since after using it for a while, there appears to be no drawback in doing so. Existing scripts that set the style will continue to work, and scripts that fail to set the style should work properly after an update of open_pdks.

@Tim Edwards @Matthew Guthaus Still using the older versions of magic/netgen, but when I add

cif istyle

to the extraction setup, I get 29 disconnected vdd nets in

bitcell_array

.

/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3646
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3262
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3326
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2558
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2238
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq1854
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3518
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3582
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3198
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2814
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2878
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2494
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3838
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2110
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3134
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2750
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2430
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2046
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2686
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2302
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq1982
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq4094
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3710
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3390
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3966
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq4030
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3454
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq2366
/Xbank_0/Xreplica_bitcell_array_0/Xbitcell_array_0/vdd_uq3006

Manually editing the netlist to replace these nets with vdd, I again get a match. It looks like adding

cif istyle

causes a problem with sram extraction. I will check again with the latest? programs.

magic 8.3.190
netgen 1.5.196

I'm just going to repeat that I used these versions. I haven't tried those. https://skywater-pdk.slack.com/archives/C01EX4ATEKF/p1626886907289900?thread_ts=1626057809.263700&cid=C01EX4ATEKF

Thanks for clarifying the versions. I'm not using the most recent tech file, but rather the same one as you that passed LVS. I'm trying 4 variations of the

run_ext.sh

script. 1. as is 2. with

cif istyle

3. with

readspice

4. with

cif istyle

and

readspice

My current feeling is that we would want LVS to pass without requiring

readspice

because we would not want to require the users to add that to their extract setup whenever they used/changed an sram instance. However, it appears that

cif istyle

causes an extraction problem in older versions of magic. If I get something that works, I'll try again with the latest technology file(s).

I've never gotten it to pass without readspice and I'm not sure how you could dothat.

@Matthew Guthaus the

run_ext.sh

scripts in

sky130_sram_macros

do not specify

readspice

. Are you saying that those scripts won't work as they are?

@Mitch Bailey sorry, it's been ages since I visited any of this. At the top level, port makeall is sufficient since there are no other labels at the top level

@Matthew Guthaus: The last error reported by @Mitch Bailey is almost certainly something that I introduced recently; I found cases where implicit ports were not output in the subcircuit definition or call. But having added them back in, apparently there's some subset of those cases in which the implicit port ends up in the subcircuit but not the call. Hopefully just a simple counting error.

@Matthew Guthaus I'm open to any suggestions! Currently, I've verified that LVS passes with older versions of magic and netgen and the scripts in the

sky130_sram_macros

, if the

readspice

statement is added. My final goal is to run LVS on the entire chip (or at least the

user_project_wrapper

). What I want to do next is run LVS, using the standard flow, on the

storage

macro, which includes 2 sram instances. The standard flow includes/requires the

cif istyle

statement which unfortunately results in unconnected nets when using older versions of magic. I haven't found a version of magic that will work, so I'm starting at the latest and working backwards. Also the standard flow does not include the

readspice

statement, so if possible, I'd like to find some way to avoid that. I'll check if

port makeall

can be used in place of

readspice

, but I don't think

port makeall

is included in the standard flow, either.

@Tim Edwards perhaps, but this seems to keep circling back to problems that aren't issues in the memory and I keep repeating myself.

@Matthew Guthaus thanks for your attention to something that you may not need to do anything about. I was on branch

main

of `sky130_sram_macros`; I'll try branch

mpw-two

.

@Mitch Bailey: Sorry, I was busy for a week on MPW tape-out issues and a presentation I had to make for a conference in Taiwan (virtual, of course, but still takes time to prepare). I just got around to working out what I did wrong with the attempted fix for the failure to handle implicitly-defined ports. The code was pretty sloppy anyway, making it hard to see what the error was, so I took a different approach, cleaned it up a bit, so it's less likely to generate unexpected output. I have not tested it extensively other than to check that the failing cases I was seeing in the SRAM example you used are no longer failing.

@Tim Edwards Great! Once the changes are merged in the magic repo, I'll try again.

It was 8.3.196. I only spot-checked some routines to make sure that magic was generating the same number of arguments in the subcircuit definition as well as the call. I still have the OpenRAM example, so if you can point me to where you see the output in error, I can check whether I get the same result or not.

Unfortunately, the example I sent doesn't work like I said it would. I forgot to include the .magicrc file, which means that if the run_ext.sh scripts ran, they weren't using the local sky130A.tech file. The run_ext.sh would sort of look like they ran but the output spice files would just be a blackbox. Let me recheck the results and I'll send something on Monday.