Very nice

Is the glue you used @User open source?

I poked the cocotb chat channel about Xyce support now, we will see if anyone in there has any ideas if there are noteworthy projects / patches

Unfortunately not, but it's not much beyond what I just described so it wouldn't hard to replicate and improve. Maybe Xyce are willing to share their code from that paper too

CocoTB does have the notion of ReadWrite/ReadOnly cycles and such so it would be a different kind of simulator I than what they usually support, but hopefully close enough that they'd like it.

Oh, Xyce has VPI even

https://github.com/Xyce/Xyce/issues/2 might have some information

Does that mean it could hook up to Verilator as well through VPI??

@User https://xyce.sandia.gov/downloads/_assets/documents/AppNote-MixedSignal.pdf see page 34

"Xyce VPI interface to Icarus"

Also FYI, https://docs.cocotb.org/en/latest/examples.html#mixed-signal-analog-digital seems cocotb has some existing AMS support albeit commercial only it seems

Cocotb doesn't know anything about the analog part, it just uses a HDL module that knows how to get analog values as real numbers (using proprietary functions)

Xyce+Sky130 is a ways out for reasons Tim Edwards discussed on another thread. Someone might be able to speed that up by adding a scale command to Xyce but Sandia would probably reject that on legitimate user interface grounds - it’s hard enough to ground the truth of what you are simulating and get the units right as it is. I started out with Xyce because it built cleanly and I had trouble with my Mac build of ngspice. I got that largely sorted but I have mysterious fails with no error messages and no outputs about 2/3 runs with ngspice sky130 models. I will persist with ngspice for a while to leverage xpsice but in the long run I would like to see Google or Amazon or another cloud service company wrap these tools into a service. It’s a good fit - small amount of data in both directions and lots of efficiency and practical reasons to have it in the cloud. The service could preload/compile in all the sky130 models and any fixes and improvements in those models would be available without wrangling the whole repo. This could become especially useful for large post-layout simulations or for when optimizing designs by iterating through large parameter spaces.

I downloaded https://github.com/Isotel/mixedsim and had a go at it, and it actually works for me. I was a bit surprised to find that the way it works is that it synths to X subcircuits, and includes a wrapper with the A XSPICE models. This has two reasons. One is that Yosys write_spice writes modules as X, the other is that they use this to sub in a CMOS implementation for slow analog sim. I think two interesting things could be explored: 1. expand the Yosys spice backend to write A XSPICE primitives directly. This would make it more easy to expand support for more of the supported cells. It can even do state machines and memory it appears 2. generate XSPICE implementations of Sky130 standard cells. This would allow the same kind of "retargeting" that isotel is doing, but specifically for simulating Sky130 mixed signal designs.

@User: A few years back I added general-purpose LUT devices to XSPICE that allow any standard cell library to be implemented in ngspice; you just need the truth tables. I have scripts in qflow that use a liberty file to look up the function for each cell and generate the corresponding truth table, and writes the corresponding XSPICE circuit using the LUT devices. The script is "spi2xspice" and as long as you have a valid SPICE netlist with the standard cells in it, it will generate a valid XSPICE netlist from it.

I came across this (very old) paper https://ieeexplore.ieee.org/document/1050943 "High Density CMOS ROM Arrays" which, although very much out of date, gives a design of a CMOS ROM which seems reasonable to me. The thing I like the most is it uses dummy bit lines to determine the length of the precharge cycle, and is essentially asynchronous, i.e. a precharge cycle is initiated when an address line changes. I wonder if any one could tell me if there are newer design methods that are more suited to modern processes? I have access to journal papers and e-books through my work, although my searches only turned up this paper. Can anyone recommend any other resources (i.e. text books, papers?)

Has anyone tried to go through the models and extract some basic values for hand calculations? I am looking at the files and the models are pretty complicated and not really matching up with the documentation on spice models I am reading.

or because of the different aspect ratios would it just be best to plot curves and then manually extract values?

What dimensions for the nmos and pmos would be suitable for a weak inverter for sky130, for use in a latch consisting of two inverters? Or is there a standard cell that could be used?

I got an analog design simulated! It needs some tweaking, but it seems to work. I am going to design a bias circuit so its self contained and then try to lay it out. Right now I am using ltspice for waveform viewing, it can open the .RAW files from ngspice directly. Gaw is pretty bad.

@User you can follow the instructions to create a xshemrc and you should be ok

I'd love to know what features you are missing from Gaw!

I did and then it could not find any libraries at all. I saw no urgent need to use the new symbols so I did not investigate much

Gaw cant do magnitude / phase plots

are you the author of Gaw? 😶

I think it might be possible to hack it to do it but I think it's a very fair point. Gaw is more setup for transient type plotting and not really arbitrary XY plotting. There has been some discussion about forking it and making some much needed improvements. That seems like a pretty good improvement although not necessarily quick and easy

there is of course a desire to have everything be FOSS, but ltspice does a great job of reading the raw files and is free (but not open source) and runs on wandows, linux, and osx

I've heard there's some clauses in the terms and conditions that you can't use ltspice for IC design. I don't know how true that it is or how much that applies to an open source project but it's worth bearing in mind

huh, I will have to investigate that 😶

If it is true its almost certainly meant for companies rather than individuals so it probably doesn't matter but I'm not a lawyer