https://open-source-silicon.dev logo
Join SlackCommunities
Powered by
<@U01819B63HP>: After a round of testing and bug ...
# xschem
t
@Stefan Schippers: After a round of testing and bug fixing, I resolved a number of issues with the continuous sky130 models. It's clear that they work for the most part, but I missed (or my scripts missed) a handful of spectre-to-ngspice conversions. I would like to transition completely from the discrete-binned models to the continuous ones, which requires (1) changing the "ngspice" directory in the PDK path for models to "combined" ("combined" meaning a combination of the new continuous models and the original models that weren't in the set of continuous models provided by SkyWater), (2) running all the device tests to make sure nothing else is broken, (3) fixing anything that is broken, and (4) pushing the updated xschem library. If you or somebody else can run the tests and give me feedback on any errors, I can patch the repositories when/if needed.
🌍 1
s
Ok, @Tim Edwards I will start doing the full open_pdks update and run the tests on the new models. Thank you for this hard work. If I find problems that require some non trivial changes I will notify you before pulling the carpet under someone's feet.😄
👏 1
t
And thank you for volunteering for a non-trivial amount of grunt work.
👏 1
s
@Tim Edwards I am running the simulations with combined models, so far only the diodes testbench does not work (anyway diodes used to simulate in previous ngspice/ (binned) models but giving fancy results). • test_diodes: the models are not found: 
d1 0 k1 sky130_fd_pr__diode_pw2nd_05v5 area=1e12 pj=4e6 could not find a valid modelname
All the other very basic testbenches i have in xschem run fine with correct results, so far I have tested: • mim caps • vpp caps • varactors • bipolar (including npn_05v5_w1p00l2p00) • resistors • nmos and pmos Tomorrow I will go on with the (less trivial) circuit testbenches and investigate a bit the diode problem.
t
@Stefan Schippers: It looks like the problem with the diodes is that in the new set of models, they were given subcircuit wrappers, and now should be called as "X" instead of "D".
👍 1
s
@Tim Edwards adding the 'X' prefix on diodes works. The next problem is that many standard cells (sc_hd) use this transistor: 
X4 a_473_413# a_27_47# a_581_47# VNB sky130_fd_pr__nfet_01v8 w=360000u l=150000u
that is, 
nfet_01v8
, 
W=0.36
and 
L=0.15
. ngspice (with the new continous 'combined' models) tells this is out or range:
Copy code
Error on line:
  m.x2.x2.x7.msky130_fd_pr__nfet_01v8 x2.x2.a_448_47# x2.x2.a_27_47# x2.x2.a_543_47# vss x2.x2.x7.nshort_model x2.x2.x7.l= x2.x2.x7.  1.500000000000000e-01   w=    3.600000000000000e-01     ad=    0.000000000000000e+00     as=    0.000000000000000e+00     pd=    0.000000000000000e+00     ps=    0.000000000000000e+00     nrd=    3.888888888888890e-01     nrs=    3.888888888888890e-01     sa=    0.000000000000000e+00     sb=    0.000000000000000e+00     sd=    0.000000000000000e+00     nf=    1.000000000000000e+00     delvto=    0.000000000000000e+00   
could not find a valid modelname
    Simulation interrupted due to error!
t
@Stefan Schippers: I can fix that. I think there might be a similar problem with a device in the SRAM core, if it carried over from the original models.
👍 1
@Stefan Schippers: It's a bit more complicated than I thought, but it comes down to this: The minimum transistor channel length rule for the "periphery" DRC rule set is 0.42um, which makes all devices in standard cells that are shorter than 0.42um "special" devices that cannot be used outside of a standard cell context (the same sort of reasoning applies to SRAM cells as well). Therefore only the device sizes that exist inside standard cells are valid sizes, and the discrete device models still apply. Fixing it is as "simple" as adding the bins of the discrete models for these devices to the list of models for the continuous devices. The hard part is (1) identifying all of the device types and sizes used in all of the standard cell libraries that are not covered by the continuous model ranges, and (2) making sure that the parameter names are valid and nothing breaks when the discrete model bins are spliced onto the end of the continuous model bins. Fortunately, the SRAM devices are not an issue because they already had special (unique) names for the devices, and so they're already part of the set of discrete devices that was just copied over to make the "combined" set.
s
@Tim Edwards This is the hystogram (# of occurrences for every W L combinations) of NFET (sky130_fd_pr__nfet_01v8) mos transistors used in the 
sky130_fd_sc_hd.spice
file (1st number is # of occurrences, followed by W and L).
Copy code
$ cat sky130_fd_sc_hd.spice|gawk 'NF==8 && $0 ~/^X.*nfet.*w=.*l=/ {split($7, w, "="); split($8, l, "="); sub(/u$/, "", l[2]); sub(/u$/, "", w[2]); print w[2]/1e6,l[2]/1e6}'|sort -n -k 1|uniq -c
    207 0.36 0.15
      2 0.39 0.15
   1127 0.42 0.15
      8 0.42 0.18
      8 0.42 0.5
      8 0.52 0.15
      5 0.54 0.15
      6 0.55 0.15
      2 0.55 0.59
      2 0.55 1.05
      2 0.55 1.97
      2 0.55 2.89
      2 0.55 4.73
      6 0.6 0.15
    160 0.64 0.15
   2618 0.65 0.15
      4 0.65 0.18
      4 0.65 0.25
      4 0.65 0.5
Below the same for PFET (sky130_fd_pr__pfet_01v8_hvt):
Copy code
$ cat sky130_fd_sc_hd.spice|gawk 'NF==8 && $0 ~/^X.*pfet.*w=.*l=/ {split($7, w, "="); split($8, l, "="); sub(/u$/, "", l[2]); sub(/u$/, "", w[2]); print w[2]/1e6,l[2]/1e6}'|sort -n -k 1|uniq -c
      2 0.36 0.15
    690 0.42 0.15
      2 0.42 0.18
      2 0.42 0.5
     34 0.54 0.15
      2 0.55 0.15
     11 0.63 0.15
    425 0.64 0.15
      1 0.7 0.15
     17 0.75 0.15
     31 0.79 0.15
      4 0.82 0.15
      4 0.82 0.18
      4 0.82 0.25
      4 0.82 0.5
    114 0.84 0.15
      2 0.87 0.59
      2 0.87 1.05
      2 0.87 1.97
      2 0.87 2.89
      2 0.87 4.73
     42 0.94 0.15
   2757 1 0.15
      6 1 0.25
.
t
And repeat for the HDLL, HVL, HS, MS, LS, and LP libraries; then remove all entries that are in the wmax/wmin/lmax/lmin range of the continuous devices.
Copy code
Library    Devices used
--------------------------------
HD         nfet_01v8, pfet_01v8_hvt
HDLL       nfet_01v8, pfet_01v8_hvt
HVL        nfet_01v8, nfet_g5v0d10v5,  nfet_05v0_nvt, pfet_01v8_hvt, pfet_g5v0d10v5
HS         nfet_01v8_lvt, pfet_01v8
MS         nfet_01v8_lvt, pfet_01v8
LS         nfet_01v8, pfet_01v8, pfet_01v8_hvt
LP         nfet_01v8, pfet_01v8, pfet_01v8_hvt
Next I'll go look up the continuous model limits for each of these devices. . .
The HVL library is fine, at least; the 3.3V models span the entire range from L=0.5 to L=20 and W=0.42 to W=1000. No devices in the library are outside of this range. The 1.8V devices used in the HVL library are all wide devices. As far as I can tell, the only devices in all the standard cell libraries that are outside the bounds of the continuous models are the ones already seen in the HD library, the 
nfet_01v8
and 
pfet_01v8_hvt
at 
W=0.36
and 
L=0.15
.
I'm inclined to just change Wmin=0.42 to Wmin=0.36 on the two bins, at least as a stop-gap measure.
I'm now attempting to add the FET models for the HD standard cells in a proper manner, which is basically to do them the same was as the SRAM FET models, and rename them to a "special" device which will have its own models covering that W and L range. All of the HD library SPICE and CDL for all standard cells will need to have the device name changed. The discrete models will deal with that by adding a subcircuit for the new device that just instantiates the old device. Any update of open_pdks will do all of the above at once, so the update should be transparent to the user other than that HD library standard cells will properly simulate from extracted SPICE. I have not pushed these changes but am testing them now.
@Stefan Schippers: That was a much deeper rabbit hole than I was expecting. Somehow, making the change uncovered a parameter name collision in the resistor models (which I had not even touched), with ngspice throwing a totally unrelated error in the middle of parsing the testbench. Took me a full day to figure that one out. The finished update touches three different repositories: 
sky130_fd_pr
(containing the additional device models in the combined models), 
sky130_fd_sc_hd
(with the under-width devices being renamed 
sky130_fd_pr__special_nfet_01v8
and 
sky130_fd_pr__special_pfet_01v8_hvt
), and 
open_pdks
(with a modified extraction deck for magic and the new device names added to the netgen setup). But I can now run your "test_stdcells" example in xschem, and can switch between the discrete and the combined models, and it works both ways.
s
@Tim Edwards Awsome! will update. I have also some experiences in the royal PITA of debugging some of ngspice error messages, so I fully understand what you mean. Thank you.
47 Views
Open in Slack
PreviousNext
Powered by