<@U0506JWMLA1> regarding the padring issues. Pleas...
# ieee-sscs-dc-23
m
@Gabriel Maranhão regarding the padring issues. Please update us here on your simulation. cc @Yukidamayaki
g
@mehdi @Yukidamayaki I have 3 schematics to test some PAD cells, mainly focusing on analog circuits. 1. The first one
analog_leak_pads.sch
is a test to plot the leak current of the ESD (asig5V IO cel) circuit using the extracted view provided to us
gf180mcu_fd_io__asig_5p0_extracted
. That is why we are creating another PAD with lower or without ESD circuits (none of them will connect to gate). 2. The second schematic
inverter_pads_dc.sch
is a DC simulation of a simple inverter. Here I included the
__cor
__asig
__dvdd
__dvss
__fill
cells to test all of them together, and see if they influence on something, since they add a lot of passive components. Here we are not using extracted views. 3. The third schematic
inverter_pads_tran.sch
is a transient simulation of the same inverter. Adding the same IO cells of the previous schematic. I added some text indicating the problem, the transient simulation hardly works with all cells, and with the
__cor
cell it does not work at all. Here we are not using extracted views. Another point: In parallel I'm trying to run PEX on each of the IO cells, and also on the PAD_RING (Michigan) that was provided. I have a script
run_ex.sh
to run PEX on magic that was fixed by @Tim Edwards and I tested it on some simple layouts, made some post-layout simulation. BUT the extraction of the IO cells are not working, neither for the PAD_RING, it seems to me that the extraction is not identifying the PIN/Labels names, and also none resistor is added after PEX, only Caps on "wrong" labels. So we are unable to test our circuits with the extracted view of the PADS, I know that they were manufactured and tested, but it would be good to test them together with our analog blocks, also because we are creating another "new" PAD. Attached to this conversation are the files related to the PEX (PAD_RING, my script and an initial analog pad without ESD).
y
I believe the extraction issue is due to local labels: Sometimes the local label can take higher precedence than the port labels, so it will mess up the netlist. So when I'm extracting, after the flattened version is generated I open the magic file using a text editor and remove all the local labels, and only leave the port labels. I haven't spend much time to figure out how to do it properly, maybe Tim can shed some light on this.
g
@Yukidamayaki Thank you for the response. I manage to set each label individually inside magic, and attempt to make the PEX for the
gf180mcu_fd_io__asig_5p0
so I could compare the results with the one that you provide for us. The PEX "worked", and the
.spice
file created is attached. But, when comparing with the one on the repo (https://github.com/idea-fasoc/openfasoc-tapeouts/tree/main/gf180mcu_padframe/tb) There are a lot of differences, mainly on the number of capacitors extracted. Also, the simulation using each one has big different results.
m
@Gabriel Maranhão The extracted PEX here uses closed tools as a reference. I would work with @Tim Edwards to figure out the discrepancies. Have you checked if metal resistances are similar? Thanks for checking this.
g
@mehdi In my viewpoint the metal resistances are not similar, nor the capacitance's.
Even the leakage current that I previous evaluated has decreased a lot using the PEX made using magic, and I think it is wrong (could be something that I made wrong, but I think I executed the right steps)
t
@Gabriel Maranhão: For the closed-source tools, what metal stackup are you using? What is the thickness of the top metal?
@Gabriel Maranhão, @mehdi: At least at a first glance, the extracted metal resistances appear to be correct.
Copy code
R67708 ASIG5V.n8700 ASIG5V 7.60079
R67709 ASIG5V.n7465 ASIG5V 7.59795
R67710 ASIG5V.n8261 ASIG5V 7.5976
R67711 ASIG5V.n7511 ASIG5V 7.59689
R67712 ASIG5V.n7263 ASIG5V 7.59689
R67713 ASIG5V.n7571 ASIG5V 7.59512
R67714 ASIG5V.n7072 ASIG5V 7.59512
R67715 ASIG5V ASIG5V.n13839 7.59512
These are the 8 metal2 fingers running from the pad to the core; the resistance network has been broken into pieces and these are the unbroken lines running from the last ESD diode connection to the core pin position. The metal 2 lines are 2.5um wide and 215um long. So each one is about 86 squares, and at 90 milliohms per square, that comes to about 7.7 ohms, which agrees with the output above. Beyond that, the signal pad resistance network is broken up into hundreds of contacts and becomes impossible to eyeball. Something has gone completely wonky with the device extraction, though. The output from magic for the moscaps is
Copy code
X35 DVDD.t43 DVSS.t0 cap_nmos_06v0 c_width=75u c_length=75u
There are 36 extracted devices, which is right, but they are being given W and L of 75um when the devices are actually 15um x 15um. Likewise the diodes are output as:
Copy code
D11 DVSS.t37 ASIG5V.t7 diode_nd2ps_06v0 pj=0.53m area=3.75n
Which again is the right number of diodes but the area and perimeter numbers are off. And the amount by which they are off is exactly 5 for length and 25 for area. I did a basic extraction of the
gf180mcu_fd_io__asig_5p0
cell and the device lengths, widths, areas, and perimeters all come out correctly. I am currently running a parasitic extraction of the same file to see how it compares to yours, so I can figure out if it's an issue with annotating the basic extraction with parasitics, or if it is some setup issue on your end. At any rate, I am quite sure that the simulation results are dominated by the diode and moscap devices, not by the metal parasitics.
@Gabriel Maranhão: I have no idea how you end up with a scale factor of 5 in your device dimensions in the extracted netlist. I ran the same extraction and got all the proper dimensions. My extracted file is attached below (it is also 2/3 the size of yours). What version of magic and of the gf180mcu PDK are you using? FYI, while I was running that test, I discovered that magic was getting bogged down in a single routine while running
extresist
. I investigated and found that it was spending all of its time running an area search on a zero-sized area. So I fixed that, and the run-time of
extresist
went from "interminable" (I didn't wait for it to finish, but it had been running several hours) to several seconds. The patched version of magic is 8.3.432.
@Gabriel Maranhão: I should be clearer in stating that there is no mechanism that I know of that would cause the extracted output dimensions to be scaled up by a factor of 5, so I need more information, such as a capture of the output from running the parasitic extraction script.
g
Hi @Tim Edwards, sorry for late response, was able to access my PC on university only today. First, I do not have access to closed-source tools for GF180, only the open-source, these extracted files was provided for us, and I was trying to reproduce it on open-source tools. cc: @Yukidamayaki I noted these differences on W and L for the mos-caps and the diodes late, and I have no idea what I did to created that, but I'm going to tell you all the steps that I made to run PEX on that IO cell. All the files that I'm going to mention here can be found on this repository https://github.com/idea-fasoc/openfasoc-tapeouts/tree/main/gf180mcu_padframe
gf180mcu_fd_io__asig_5p0_extracted.spice
Is the PEX file using closed-source tools First of all I copy the Cell
gf180mcu_fd_io__asig_5p0
from
RING_PAD.gds
to another .gds file to make it the TOP CELL, with the same name as the gds file, so I create the
gf180mcu_fd_io__asig_5p0.gds
with a solo cell:
gf180mcu_fd_io__asig_5p0
. Running my script
run_ex.sh
(uploaded on this thread ) I got errors regarding the labels, probably magic does not recognized those labels as ports and I got a .spice file with a .subckt without any node. After that I placed each PORT manually on magic Edit->Text ... -> Port -> Enable : Type ASIG5V to each 8 metal2 terminals, and also added the DVDD, DVSS, VDD and VSS to the metal5 rail on the top of the cell. With this I continued to run the script (direct on terminal, line by line) and got that final .spice file. magic version: 8.3.424 GF180mcuC _version_: 1341f54f5ce0c4955326297f235e4ace1eb6d419 (2023.08.27) I'm going to update magic, PDK, and repeat the same procedure, with that, I will get the output and send to you, doing this right now. BTW, this error on W and L could be related to grid size differences for klayout and magic ? FYI, I made a schematic that uses both PEX files, closed-tool(repo link) and open-tool (the one that you gave to us). My schematic just get the leakage of the PAD, from a ideal current source that I placed going into the PAD sub-circuit. Attached is the results using each one of the .spice PEX files. Leak current is lower ~5x for open-source tools.
t
@Gabriel Maranhão: Thank you for the complete description. I notice that the closed-source netlist contains parasitic inductors, which magic does not generate; this will not affect a DC simulation, of course. Otherwise, I will need to stare at this a bit more.
g
@Tim Edwards: I manage to redo my extraction (.spice attached), with the correct labels and right grid spacing. Now I got the right diodes and mos_cap, and the simulation (with my .spice and yours), got very similar results, so I think now we are on the same page regarding the open-source extraction for this IO cell. I named it
gf180mcu_fd_io__asig_5p0_gab.spice
so we don't get confused with so many files. Thank you a lot for your assistance on this process. Feel free to request anything.
t
@Gabriel Maranhão: It is of course difficult to make a direct comparison between the two netlists, because they use different algorithms to determine the R-C networks and different algorithms to reduce them. But there are a few definite things: (1) It's a DC analysis, so the inductors and capacitors have no impact whatsoever; (2) I'll assume the MOScaps have essentially no leakage from poly to diffusion so that they have no impact, either. (3) Any resistance from pad and core is just carrying current from the source and only contributes voltage drop. (4) A direct comparison can be made between the extracted diodes in both netlists, and they are exactly the same. Ergo, the difference in current leakage comes entirely from the resistance between the pad signal path and the ESD diodes. Following my back-of-the envelope numbers above, in the commercial-tool-extracted netlist I can also find 8 resistances (apparently) corresponding to the straight-line path from the core to the 1st via network. These appare to be:
Copy code
rASIG5V/141 ASIG5V:3013 ASIG5V:1321 8.9712
rASIG5V/167 ASIG5V:2995 ASIG5V:1305 8.96285
rASIG5V/63 ASIG5V:3067 ASIG5V:1369 9.27884
rASIG5V/89 ASIG5V:3049 ASIG5V:1353 9.41378
rASIG5V/115 ASIG5V:3031 ASIG5V:1337 9.12149
rASIG5V/193 ASIG5V:2977 ASIG5V:1289 9.11067
rASIG5V/219 ASIG5V:2959 ASIG5V:1273 9.39452
rASIG5V/245 ASIG5V:2941 ASIG5V:1257 9.21806
which are a bit bigger than what I calculated (more like 8 ohms) but certainly not 5x off. Following one of those paths in the netlist, the next component is a 0.225 ohm resistor, which matches what I would expect from condensing down the 20-via array (at 4.5 ohms per via) from metal 2 to metal 1. After that it gets much harder to figure out how the extraction has divided up the diffusion contacts under the metal 1. The network extracted from magic is harder to figure out because it is not condensing down the via arrays (normally it would do this but the via rules prohibit magic from merging together the contacts on GDS read, resulting in individual vias, which then get extracted individually). I will spend some time trying to figure out whether magic's extraction of the resistance network down to a diode is sensible or not.
@Gabriel Maranhão: I tried following the path of the resistor network through a contact array (in magic's extraction), and was very puzzled by the results. For an array of vias up to (2 x N), magic's extraction of the network is good and it reduces the entire via array to a single resistance. But as soon as I have an array of (3 x 3) or larger, the reduction algorithm goes off the rails and leaves dangling nodes. I get the impression that it has found multiple loops and cut them very arbitrarily, but I need to investigate. However, when it does this it tends to over-estimate the resistance of the contact array (because many of the contact cuts became dangling resistors and no longer combine in parallel). It is hard to say yet whether that matches the discrepancy in your simulation. In your simulation, the extra current onto the signal node is the difference of the two ESD diode leakage currents, so a much larger resistance through the diode to ground would result in more current on the signal node. Finding where the discrepancy really is requires measuring the current into each diode for both extracted circuits. I have not done that yet. The parasitic extraction and reduction algorithms in magic were written a long time ago (in other words, not my code), so I will have to dig into it to figure out where improper assumptions might have been made, or if there's some other error.
g
@Tim Edwards: The amount of work you are dedicating to this problem is very high, thank you very much for your help. These PADs have a lot of nodes and a high density of metals. For IP/Blocks, the extraction seems to work normally, but it would be interesting if we had access to more extracted views (GF180) made in closed-source tools for comparison. I will do some testing on the extracted view for the digital IO cell also, using both closed and open extraction files. I'm evaluating whether this analog PADs would be harmful to our analog circuits, and that's why I'm creating a PAD without ESD structure for some specific current signals, I'll work on the extracted view for it too, it shouldn't contain many problems since they do not have ESD diodes.
t
@Gabriel Maranhão: Well, I have known that there are some issues in the parasitic extraction routine in magic, and occasionally I sit down and try to resolve some of them, and this example seemed to be pinpointing at least one. I did a deep-dive into the code today, and found two distinct issues, both of which presumably contribute to simulation error: (1) The calculation of the number of contact cuts per contact area was wrong, so the diode contact strips were treated as one contact cut instead of 106, leading to several ohms resistance to the diode when it should have been 100 times smaller. (2) There was an error in the original algorithm that marks loops in the resistor network to prevent infinite recursion when walking the nets, but then later incorrectly eliminates the resistor where the loop was cut. This was causing parallel resistor paths to become dangling resistors, which also makes the resulting resistance much higher than it should be. I have fixed both of these issues (in magic version 8.3.435). I ran the corrected algorithm on a reduced example with via arrays of different sizes, and it seems to work well. I would appreciate it if you could run a test with the corrected version. Currently, the output is very large because the resistors that were previously being eliminated are now in the output. The network cannot be reduced further because the reduction algorithm is a rather simple one that combines devices in parallel, series, and does delta-wye transformations. I added a command option "extresist threshold <value>" (<value> in ohms) to try to force it to reduce the network by eliminating small resistors, but I think it introduces too much error, and still doesn't reduce the network all that much. You might want to look at what effect that has, though. I will need to spend some time researching network reduction algorithms.
@Gabriel Maranhão: I found another issue today that contacts were being double-counted. While I fixed that, I also fixed a known issue that overlapping contacts on adjacent metal layers cause problems. New version is 8.3.436.
g
@Tim Edwards Ok, I'm going to update magic today to 8.3.436. and run some extractions and simulations using the PEX files, including the one for the PADs. I'll bring you more information and some results later today or tomorrow.
t
Thanks!
g
@Tim Edwards: Initial result shows big improvements. I updated magic to 8.3.436 and did extraction procedure for the Analog IO cell (File attached). Leakage simulations using closed-source PEX file shows a leak of around 210pA through the diodes. On the other hand, using magic(8.3.436) PEX files shows a leak of around 254pA. And that is really good, 4.4% "error". I think right now the OpenSource extraction procedure for those IO cells are really good. Again, thank you very much. (Prints attached) Simulation time got little bit longer due to the large .spice file created, but that's not a bit problem. Closed-source PEX file leak simulation time: 2.3 sec magic PEX file leak simulation time: ~17 sec For the next days I will run some tests using the digital IO cell with both closed-source PEX file and magic PEX file.
t
@Gabriel Maranhão: That's good to know! Just bear in mind that we need confirmation of the accuracy of both the capacitance and resistance extraction, and the DC analysis is affected only by the resistance extraction. Hopefully you can run some transient simulations.
g
@Tim Edwards: I did some transient simulations using the magic PEX file and unfortunately, if my simulations are correct, there are some errors. First I'm simulating a simple inverter and applying the output signal to the analog IO cell sub-circuit. There are 3 inverters each one with output to a different IO cell (Closed PEX, Magic PES and schematic), image attached. Input signal is the same for all inverters,
pulse(0 3.3 50p 50p 50p 1u 5u)
. A "Slow" signal to give time to charge the capacitors. Faster signals do not work even for the analog IO cell schematic 1. The schematic results are as expected for a inverter; 2. The closed PEX results are inconclusive, if I add it to the circuit the transient simulation abort (time step too small, tried a lot of things to fix it but did not work); 3. The magic PEX results shows a output signal but it goes from 0V to ~0.7V and not 3.3V. And I thing that this is not a problem regarding the time to charge the capacitors, the high value just sits at ~0.7V (image attached, blue signal).
t
@Gabriel Maranhão: Unless I'm missing something, your posted schematic is using the same cell name
gf180mcu_fd_io__asig_5p0
for both the schematic-extracted and magic layout-extracted cells. Either one of them is a different name, or you have colliding cell names in the netlist. The pin order is different, which probably explains the simulation behavior.
g
@Tim Edwards: Sorry for the delay, was working on a paper submission, it is done. I fixed the cell names, and the transient still do not works on neither closed-pex file and magic-pex file. I tried using only the magic one, only the closed, both at same time, but everytime the transient simulation abort and returns "time step too small" I'm using three different cell names (schematic, closed-PEX, magic-PEX) but I can not find the error.
t
@Gabriel Maranhão: I was able to get magic's extracted netlist to run by adding this to the top of the simulation netlist:
Copy code
.option RELTOL=1e-2
Convergence issues and solving them are a bit of a mystery. I have not (yet) found a set of options that will get the closed-source netlist to simulate. This page: https://efabless.com/kb-articles/overcoming-spice-convergence-issues is something we wrote up at Efabless some years ago for helping users through issues with convergence on ngspice. ngspice is not as good as the commercial tools at automatically solving convergence problems, and the larger the circuit gets, the more likely that some manual intervention will be needed.
g
@Tim Edwards: Thank you! It works, got magic pex file to run. No idea regarding the closed-PEX file. The closed-pex cell has six PIN/PORT while the schematic and magic pex cell has five ( and it is correct, should be five). But I think that now we are able to run our Chipathon circuits with the magic extracted view of the PADS, and see if everything works fine. But I'm going to try a little bit more on the closed-pex file, just to see the resemblance. Tanks for the text about the convergence issues! I'm going to use these options more on transient simulations.
t
@Gabriel Maranhão: I noticed the six ports on the pad extracted from closed-source tools. That extraction is technically more correct because it has separated the PAD connection from the core (ASIG5V) connection. To simulate the pad properly, you would want the connection external to the chip to connect to PAD and the connection internal to the chip to connect to the core signal (ASIG5V). But the netlist for the pad only has the one connection (ASIG5V, and no connection named "PAD"), so it is not clear to me how the closed-source tool determines that PAD becomes an additional pin when doing R-C extraction, or how the closed-source tools reconcile that extra pin with all the other views. The SkyWater PDK has a better way of doing it, which is to draw a thin metal resistor around the pad so that all views of all pad I/O cells have both a pad connection and a core connection on differently-named nets.
Note that because the pad connection doesn't exist in the magic-extracted view, it implies that both internal and external connections are made to the same point (which is at the core, not the pad, since the core side has the "ASIG5V" labels on it), and so the simulated result is missing the effect of the resistance from the pad to the core (which is only about 1 ohm. But still, it is non-zero).