https://open-source-silicon.dev logo
Join Slack
Powered by
Hi all. Im trying to run MC analysis across proces...
# sky130
d
Hi all. Im trying to run MC analysis across process. It is my understanding from reading the sky130.lib.spice that the "mm" corner does this. However, I dont see this in my results. For example, the below measures vth of a PMOS using the "tt_mm" / "ss_mm" / "ff_mm" / "sf_mm" / "fs_mm" and most importantly the "mm" corners. I get standard deviations of ~ 4mV for all corners apart from "mm" which gives me 0.3mV. I didnt expect this as when I group together the data from all corners (apart from "mm" corner data) and plot, I get 5 distributions as one would expect (as shown). In addition, I get a standard deviation of 33mV which again one would expect since that includes mismatch across process corners. From this I would have expected the "mm" corner to give a standard deviation of ~ 33mV. Am I missing something here or does the sky130.lib.spice file need to be updated? I see the "mm" corner settings in it are: .param MC_MM_SWITCH=0 .param MC_PR_SWITCH=1 MC_MM_SWITCH = 1 and MC_PR_SWITCH=0 for all corners apart from "mm" which makes sense since they dont want to model mismatch across process. Setting MC_MM_SWITCH = 0 and MC_PR_SWITCH=1 thus models process spread. Should we not have a corner with MC_MM_SWITCH = 1 and MC_PR_SWITCH=1 setting to model mismatch across process?
Just want to correct my question - the 30mV stdev expectation is of course nonsense so please ignore. The question is simply - does the SKY pdk offer a global MC corner i.e. one that root sums process spread with local mismatch? Typically this is offered by commercial pdks. Clearly the "mc" doesnt give this. In fact Im not sure what the stdev = 0.3mV from it represents (since I get stdev = 4mV from local mismatch and +/-45mV process spread). If there is no global MC corner I can just use the fs_mm/sf_mm/etc corners. However these are overly pessimistic since they linearly sum local mismatch with process spread, instead of root summing them. That said, overly pessimistic means overly conservative which is not always a bad thing! @Tim Edwards: Would love to hear your opinion on this. Txs.
t
Historically, there was an issue with ngspice at the time that the sky130 open PDK was originally created in which it was reading every file for every corner in the 
sky130.lib.spice
file, and coupled with the large number of bins for each device, it was taking ngspice upwards of 30 minutes or more just to start. All of those issues have since been resolved. However, the choice of corner types in the 
sky130.lib.spice
file still reflects an attempt to keep the total number of corner definitions to a minimum. Yes, it would be useful to have a corner type with both MM and PR switches enabled, as well as lots of corner definitions that include all the combinations of transistor fast/slow corners and resistor and capacitor high/low corners. Since any simulation just uses the line 
.lib /_path_/_to_/sky130A/libs.tech/combined/sky130.lib.spice
, if you want to simulate with an undefined corner, just copy the 
sky130.lib.spice
locally and modify it to define the corner(s) that you need, and then pass that file to the simulation.
It's clear that for sky130, the mismatch is defined separately at slow/nominal/fast/high/low corners, which are as you note more pessimistic than using a monte carlo distribution for process. What you are looking for, I suppose, is a 
mc_mm
corner, but that would require an additional an independent set of parameter files that doesn't exist. I think your only choice is to do the corner analyses and take the pessimistic result.
d
Thanks @Tim Edwards. Good to confirm this. I don't have an issue going with the overly pessimistic (linear sum) approach since it adds margin. In fact this is the approach typically used in the lower technology nodes (16nm and below) when the models are still being developed (pre version 1.x). Cheers
14 Views
Open in Slack
PreviousNext
Powered by