https://open-source-silicon.dev logo
Join Slack
Powered by
<@U017RJAP56E> the models were made available a fe...
# power
y
@User the models were made available a few days ago (check out the analog channel). I don't think they're "released" coz there's some improvements still being made but they're certainly in a state that design can start. In terms of tool flow, that largely depends on peoples preferences. Personally, I've started with xschem/ngspice/klayout + magic for LVS/DRC. No roadblocks yet
a
@yrrapt Thanks for the update. Is there any documentation anywhere about the flow? Just t get a quick start
y
There are some tutorial type documents for xschem here: https://xschem.sourceforge.io/stefan/xschem_man/xschem_man.html Then it's a matter of including the skywater spice files with: .lib sky130_fd_pr/models/sky130.lib.spice tt And selecting the right model names for the symbols.
Unfortunately I don't there is any step by step guide yet, you just need to put together the pieces yourself. I can try and help you with any particular items if you get stuck
p
Where exactly are the spice libs located? I found several sky130.lib that reference all kinds of .cor files that I can't find.
y
p
Thank you. Do you know the significance of the various "corners" such as "tt"? I assume they are for modeling process variations but what is the procedure to actually use them? Rerun sim with every corner manually, or is there a better way?
y
Yeah exactly, they're different extremes of process variation. I think you can use control statements and the 'alter' command in ngspice to automatically change the corner and repeat the simulation. Although I've been leaning more towards scripting this externally with Python. Just using regular expressions to change the netlist parameters each run. Treating the simulator as calculator and doing the coordination and data analysis in Python feels more natural to me. Or maybe I'm just too lazy to learn the ngspice syntax...
p
God, so many new unknown tools, I have no idea what all keeps breaking and why. Since you seem to know what you're doing with xschem/ngspice, could you put a simple tool test project in the repo? I think it would help tremendously to be able to use it as a template to get to the point of actually simulating something instead of just fighting frickin tools.
Like: what model name do you use for an NMOS for instance? They seem to be subcircuits instead of models. Been playing with spiceprefix=X but nothing works.
I'm using X prefix and sky130_fd_pr__nfet_01v8 as model name, but it always gives a "count not find valid modelname" related to m.x1.msky130_fd_pr__nfet_01v8 instance with x1:sky130_fd_pr__nfet_01v8__model model
y
Yeah sure. I'm about to leave for a short holiday for a few days buts can put together an example and upload it on Saturday. I'll drop in here to let you know its up.
Yeah a lot of the primitives are subcircuits. The easiest way to deal with that is rename the refdes. So instead of M1 that automatically gets put down you can just add an X prefix so it becomes XM1.
There's also the fact that the spice model bins are at very unique points so you have to consult the ....bins.csv file to see what valid widths and lengths are. That's probably the problem you're seeing coz it can't find a valid bin
Finally, I think you need to define a ".param temp=27" otherwise the models have missing information. I don't know why they can't just pull the information from the standard (and implicit) ".temp 27" but for now it's easiest just to have the parameter
t
I'm working on putting together a quickstart for simulation but I'm still working through the process myself (just got back from vacation)
you can change the corner you use in your .lib statement and rerun the spice....also, the tests directories in the various cell subdirs have lots of examples
p
None of your suggestions made any difference unfortunately. I've put an exceedingly simple 
tool-test
directory in the repo with my test project in it, the README shows details of my setup and the failure. Could you test it and see if it fails for you? And if so, what's different from your testing? I'm pretty much dead in the water until I can get a minimal circuit to simulate with the PDK models.
Mystery solved. The core of my problem was that I specified transistor length and width with "u" suffix. The library uses a scale=1u option so you're supposed to specify them without "u" suffix, otherwise the size will not be in valid range.
y
@Patrick Van Oosterwijck good to hear you got it all sorted in the end. For what it's worth, I've uploaded a basic example as promised here: https://github.com/yrrapt/amsat_txrx_ic/blob/master/design/mos_characterise/mos_characterise.spice
p
@yrrapt Your model is "mos", are you sure you're testing a sky130 model?
y
@Patrick Van Oosterwijck oh yeah, I have a python script that replaces 'mos' with whichever device I'm characterising. You can also see the save line is also incomplete, the python script fills in the blank there too
p
Oh I see, thanks for the clarification.
2 Views
Open in Slack
PreviousNext
Powered by