https://open-source-silicon.dev logo
Join Slack
Powered by
something is wrong with my diode models
# analog-design
a
something is wrong with my diode models
hi @Tim Edwards, reverse engineering the ESD protection circuit you shared so kindly, we've created the schematic cell/symbol pair to complete the schematic view of the design (screenshot attached). However, 
ngspice
complains and it won't do a reasonable simulation:
Copy code
Warning: Model issue on line 46 :
  .model sky130_fd_pr__diode_pw2nd_05v5 d level=3.0 tlevc=1.0 area=1.0e+12 ...
unrecognized parameter (vb) - ignored
unrecognized parameter (gap1) - ignored
unrecognized parameter (gap2) - ignored
unrecognized parameter (xw) - ignored

Doing analysis at TEMP = 27.000000 and TNOM = 27.000000

Warning: IKK too small - model effect disabled!
That leaves us with the situation where we have, say, a sine of +/- 20 V at the input - and at the output, the very same thing. Obviously, we do have the path to models included (since ngspice actually does demonstrate it finds the model clearly), so model is there - hence, what else is wrong here? ngspice is version 41. Here is the complete netlist, as well:
Copy code
**.subckt tb_esd_cell_tran
x1 net1 pad gate GND esd_cell
V1 net1 GND 3.3
V2 pad GND sine(0 1k 1k 0 0 0)
R1 gate GND 100MEG m=1
**** begin user architecture code


.lib "/usr/share/pdk/sky130A/libs.tech/ngspice/sky130.lib.spice" tt
.param mc_mm_switch=0
.param mc_pr_switch=0
*** ANALYSIS TO DO

.tran 10u 5m
.save pad gate

.control
set wr_vecnames
set wr_singlescale

run
******** results filename  ************ nodes to write
wrdata $DEV_PATH/res/tb_esd_cell_tran.res pad gate
.endc


**** end user architecture code
**.ends

* expanding   symbol:  esd_cell.sym # of pins=4
* sym_path: /opt/uniccass/dev/esd_cell/tb/esd_cell.sym
* sch_path: /opt/uniccass/dev/esd_cell/tb/esd_cell.sch
.subckt esd_cell  vsup pad gate vgnd
*.iopin vsup
*.iopin pad
*.iopin vgnd
*.iopin gate
D1 pad vsup sky130_fd_pr__diode_pd2nw_11v0 area=10
D2 vgnd pad sky130_fd_pr__diode_pw2nd_11v0 area=10
D3 gate vsup sky130_fd_pr__diode_pd2nw_05v5 area=0.203
D4 vgnd gate sky130_fd_pr__diode_pw2nd_05v5 area=0.203
XR1 gate pad vgnd sky130_fd_pr__res_high_po W=0.35 L=10 mult=1 m=1
D5 pad vsup sky130_fd_pr__diode_pd2nw_11v0 area=10
D6 pad vsup sky130_fd_pr__diode_pd2nw_11v0 area=10
D7 pad vsup sky130_fd_pr__diode_pd2nw_11v0 area=10
D8 pad vsup sky130_fd_pr__diode_pd2nw_11v0 area=10
D9 vgnd pad sky130_fd_pr__diode_pw2nd_11v0 area=10
D10 vgnd pad sky130_fd_pr__diode_pw2nd_11v0 area=10
D11 vgnd pad sky130_fd_pr__diode_pw2nd_11v0 area=10
D12 vgnd pad sky130_fd_pr__diode_pw2nd_11v0 area=10
.ends

.GLOBAL GND
** flattened .save nodes
.save pad gate
.end
hi @Stefan Schippers , since I get the same strange behavior with the test case provided by default for the diodes, I hope you can take a look as well - sorry to bother you. Do you have any idea why is this happening?
While at that, do note that the 
test_nmos
works fine:
s
@Aleksandar Pajkanovic This is a known issue, for some obscure reason the simplest devices (diodes) are described incorrectly. Xyce does not accept these at all, ngspice does not produce reasonable data. Seems these behave as open circuits. Nobody knows what are the units for Area and pj. It is really a skywater pdk problem, some guys of the TCAD group must come up with some decent model. These are just diodes, I can't believe why we are having this trouble for years.
a
Thanks @Stefan Schippers, So, do we have a workaround of some sort?
m
Here’s a sample extracted diode
Copy code
D0 VNB DIODE sky130_fd_pr__diode_pw2nd_05v5 pj=2.64e+06 area=4.347e+11
As you can see, the parameters are in unexpected units (pm?). Will simulation work if you scale the diode parameters accordingly? For more detailed discussions, search for 
diode parameters
in slack.
👍 1
a
Ok, I got the negative side problem solved - 10e+12 reamind on the small diode in the secondary protection circuit. When that got to 
area=10e+18
everything seems in order - simulation results attached
So, only the main question remains - is what the train of thought described above correct enough to follow through the tapeout?
image.png
s
@Aleksandar Pajkanovic The 
diode.sym
and 
lvsdiode.sym
already have a default area of 
AREA=1e12
(and perimeter 
PJ=4e6
). If you place a new diode in a schematic these will be the instance values (you can of course change these). I also came some time ago to the same conclusion that AREA=1e12 gives a reasonable I-V DC characteristic for -maybe- a 1um x 1um diode. ---HOWEVER--- Simulate this same diode in transient analysis and it behaves as an open circuit. Applying a transient current waveform of +/-10uA leads the cathode voltage to +/-10GV. This means there is only the simulator default GMIN (1e-12 mho) across the diode terminals.
m
@Aleksandar Pajkanovic Congratulations! magic should extract the diode values that are simulatable. Are you using a recent version of magic and the pdk?
a
Hi @Stefan Schippers and @Mitch Bailey, thanks for the insights and especially thanks for the encorugement. Magic is at the latest version, but pdk is a bit outdated - I don't dare changing anything right now as the tape out is November 6th. So, we'll just live with the manual configuration and then in November I'll update the repo. Hopefully, we don't face any other issue like this 🙂
s
@Aleksandar Pajkanovic I am still convinced that these models just do not work. Please see short clip. [Cc @Tim Edwards @Mitch Bailey ] I think you better keep default values (1e12 ?) for diode areas and avoid simulating ESD. (it should work on the silicon, not in simulation). Such insanely high AREA values might cause side effects (for example affect power consumption simulations).
output.mp4
👍 1
t
@Stefan Schippers: My tentative conclusion about this from the last time we had a discussion about it is that SkyWater (or more accurately, Cypress) generated coefficients for the diode models that assume very unusual units for the length values. I believe that is all internally consistent and that as long as the area and perimeter values produce the right I-V curve, then there will be no unexpected side effects. That's just an opinion. I have not investigated it.
👍 1
s
To see a more realistic example I tried the Human body discharge model (100pF @ 8kV, 1500 Ohm discharge resistance) the results are somewhat better. 👍
👍 1
I see that forcing a steady (or quasi-steady, low frequency) 50V on PAD causes kiloampere of currents in the diodes. This is so huge that it alters the simulator criteria for residual numerical error estimation and all the other calculated variables are inaccurate.
Another thing to be careful about is the resulting pad capacitance. With the given ESD circuit it is 70nF. It is probably too big if you plan to do any simulation using the ESD protection on the pad input.
a
Ok, so I guess the conclusion is that there is no purpose to simulating the diodes in the ESD cell. However, we can still have them fabricated within our design. I think we can be satisfied with this conclusion, because the circuit we are working on is a students' project not intended for high currents or high frequencies, so the diodes should not influence our performance at all. Therefore, we are safe to place them in layout and simply skip simulating them in the schematic. Or post-layout 🙂 Thank you @Stefan Schippers for being so careful to investigate these details that I did not pay attention to - I was just to happy to see the expected behavior that I forgot caution. Thanks @Tim Edwards for providing a working design for our layout (we did DRC and LVS with the schematic we've drawn <== those are fine).
One thing @Stefan Schippers - would you mind sharing the Xschem file you demonstrated in the video?
s
ESD circuits are a must-have for your IC life so whether or not simulation is OK always have it on board. Here my test schematic. I have set a launcher. If you ctrl-click on it it switches from RC charge to HBM discharge simulation. If your xschem installation s very old and has problems with the first schematic use the second one.
test_esd2.schtest_esd.sch
👍 1
a
Thanks @Stefan Schippers. Yes, the xschem installation is a bit outdated, but I don't dare changing a thing before November 6th. I'll be updating both the PDK and xschem right after that. I need to do it for the new schoolyear anyway. Thanks again for your vigilance!
h
ngspice expects the length and area data in m and m². So typically you will have length in µm (1e-6) and area in pm² (1e-12).
Now Skywater has a general setting
option SCALE= 1e-06
We probably have to check if the areas are calculated correctly (given: 2, calculated 2e-12).
a
Thanks @Holger Vogt, Such an honor to have you involved. Hopefully, in a week, after the tape-out, I'll report back, after I update the pdk.
30 Views
Open in Slack
PreviousNext
Powered by