Hi there, I have extracted my layout of a constant-gm current source and am trying to perform post-extraction simulations. However, I keep running into this error when I try running the simulation. Any advice would be greatly appreciated. Thank you. Attached are photos of the project wrapper and the testbench itself.

The ngspice output says that the device has W=0 and L=0. Can you check what's in the netlist? How did you do the extraction?

@Tim Edwards We dug through old slack posts and we flattened the design prior to extraction. Here is the extracted netlist.

I also need

user_analog_project_wrapper.sym

. You are matching the pin order in both the extracted layout and the schematic?

@Tim Edwards here's the symbol file.

The port order doesn't match between the symbol and the extracted netlist.

@Tim Edwards is the user_analog_project_wrapper.spice mismatched with the user_analog_project_wrapper.sch's generated spice list?

The schematic symbol will output ports in the order they are given in the symbol file. Magic will output ports according to the way they are numbered.

We're slightly confused. We did the layout in the caravan wrapper and instantiated our constant-gm circuit into this wrapper (aka the pad ring). Do we have to label the pads on the pad rings as ports?

Each extraction tool has to know what order to arrange the ports in. Xschem does this by the order that the signal names appear in the symbol file. Magic does this by port ordering. The original port ordering for the analog project wrapper is in the caravel_user_project_analog repository, in the file

mag/user_analog_project_wrapper.mag

. These two files (the .mag and .sym) have to agree on the port order. If you don't want to redo ~700 lines, there's a simpler way to do it, which is to read the SPICE file from xschem into magic using

File->Import SPICE

the command

readspice <netlist>

while you are editing the layout. That will cause magic to renumber all of the ports to match the SPICE file.

Will importing the spice into Magic override/delete layout? In other words, does this mean we need to restart layout by first importing spice?

No, when reading SPICE into an existing layout, it will only affect the port numbering.

So just to make sure that I understand fully. I take the spice file from the user_analog_project_wrapper.sch file and import that into my MAGIC user_analog_project_wrapper.mag layout?

Yes, if you export the netlist with a subcircuit wrapper. Otherwise, I think you can just load the top level netlist, because it has the subcircuit definition for

user_analog_project_wrapper

.

ok, thank you so much. We will give it a go right now.

I corrected my instructions above.

@Tim Edwards should we flatten the top cell first before reading the spice?

No, you just want to be editing

user_analog_project_wrapper

, because that's the one that needs to be annotated.

@Tim Edwards we followed the steps above but are still not getting any simulations results. Below is the modified Magic-produced spice file.

Well, I'm sure that was an improvement in some sense. I'll take a look at what might still be going on.

Thanks once again @Tim Edwards

Add the line

.option RSHUNT=1E20

to your

extracted_const_gm_test_022523.spice

netlist. There are "singular matrix" warnings that come from magic's tendency to write out capacitors that are floating, which ngspice does not like.

I have another question after reading this. When you said ".mag and .sym have to agree on port order" do you mean to take the symbol net list from and read that into magic or take the netlist of the symbol's underlying schematic?

@Tim Edwards we have added that line to the testbench file. Did that do the trick on your end or was it simply a fix to one of multiple possible issues (since we still don't see any results/waveforms).

@Jon Ho: If I change from an "op" analysis to a "tran" analysis, I get additional singular matrix errors which are not due to floating nodes, so there are probably additional issues to be uncovered.

Noted @Tim Edwards. We included that statement you mentioned and ran the operating point analysis and probed the io_analog[1] voltage, which is the NMOS mirroring node in our current source and are still reading 0.0000e00 V (in simulation, we have it around 0.7-0.8V).

Try running with the simple extracted layout with parasitic capacitances but not parasitic resistances to see if the issue is coming from

extresist

.

I am a bit late here, however spice netlist port ordering of xschem symbols can be defined in three ways: 1. the order the pins are created in the symbol. This order can be changed afterward if needed. 2. pins ordering in the symbol is defined by a

sim_pinnumber

attribute attached to pins. this sim_pinnumber is used as a sort key when producing the netlist (lowest first). 3. In the symbol global attributes explicitly specify the order of pins. Usualy the format attrinute (the netlist rule) is:

format="@name @pinlist @symname"

, however you can use something like: `format="@name @@GND @@TRIG @@OUT @@RESETB @@CTRL @@THRES @@DIS @@VCC @symname`", that is replacing @pinlist with the explicit order of pins. The relevant man page is here.

@Stefan Schippers: How does that work with vectors? We're dealing with nearly 700 pins on the user project wrapper, so I was looking for the solution that doesn't require typing in 700 pin names.

We noticed that too. The read spice command doesn't really work in Magic. We had manually edit the location of VDDA1 and VSSA1.

It has worked reliably in other cases. Can you please post the GDS of the layout (or point me to a repository location) so I can figure out why the annotation fails?

Here's our entire set of files that @Thomas Figura and I have been trying to run post-extraction sims today. @Tim Edwards

@Tim Edwards in xschem vectored ports are named as

DATA[31:0],

which expands as

DATA[31],DATA[30], ...., DATA[0]

, or

DATA[31..0]

expanding to

DATA31,DATA30,...,DATA0

vectored ports in xschem symbols are handled like a single pin. in spice netlist these pins are unrolled to individual bits. This is not necessary for VHDL and Verilog netlist backends.

@Stefan Schippers: So they could do

format=@name @@vector1 @@vector2 @@vector3 ...  @symname

? In that case it might not be too painful for them to just edit the symbol to match what's in the layout port definition.

@Tim Edwards yes, exactly. A valid ordering for above array symbol is:

format="@name @@vss @@LDWL[511:0] @@LDBL[255:0] @symname"

I just did a live test to ensure it does fine.

@Stefan Schippers: That's not a problem here. All of the vector components are contiguous in the layout definition. They only need to be in the right order.

@Tim Edwards indeed, that seems strange. We simply instantiated the user_analog_project_wrapper into our testbench. The symbol was the one provided on the Caravan github page.

@Tim Edwards since a port ordering mismatch is a recurring issue when doing LVS matching, are there some action I can/should take to make designers life easier less frustrating?

I think we need a symbol for the user_analog_project_wrapper that has the pin order explicitly stated and matching what is in the layout.

If you give me the netlist and (if you have it) an existing symbol I will add that to xschem_sky130

The symbol exists in the

caravel_user_project_analog

repository, which is where Jon got it from. Seems to be my fault for not making sure that the pin list of the xschem symbol matches the layout port numbering.

ok, this one. xschem https://raw.githubusercontent.com/efabless/caravel_user_project_analog/main/xschem/user_analog_project_wrapper.sym should the port ordering match with the top level of this netlist? https://github.com/efabless/caravel_user_project_analog/blob/main/netgen/user_analog_project_wrapper.spice

I don't think that can work because of my use of ASCII sort (which I definitely need to fix).

If you are using tcl

lsort

consider the

-dictionary

option to fix numbered vectors

I think that routine is C-coded, though.

@Jon Ho: Use this version of

user_analog_project_wrapper.spice

to annotate the magic layout. Otherwise, do it just like you did before. I found that the pins are ordered differently in the .sch and .sym files, and that seems to produce a different subcircuit port order depending on whether you netlist the project as the top level or the wrapper as the top level. I changed the order of lines in the sym file to match the sch file, and I could then get it to netlist with the same pin order. I will go patch up the repository itself, but I think this should get you going.

Will do! Giving it a shot right now.

You're welcome!

@Tim Edwards was the update for the port ordering pushed to Github? From the git history/actions, I didn't see any updates.

I have not gotten around to it yet, but thanks for the reminder!