what all analog ips would caravel test harness support?

@User: What do you mean by "support"? You mean what is already on the test harness? Essentially nothing. We got no analog IP from SkyWater, so we will have to create it all from scratch. I created a simple power-on-reset circuit for caravel for the first tape-out, and that's all on the management SoC side of the chip. There are a number of analog IP blocks among the 40 user submissions for the first tape-out, including (I haven't counted them) one or more bandgaps, ADCs, LVDS drivers, op-amps, PLLs, and LDOs. Once we are able to get results from the users testing their chips, I will be adding them to the harness in support of the management SoC (e.g., 1.8V LDO for driving the digital cores, PLL for the clock, LVDS driver option for high-speed I/Os).

is there anyway to size mosfets for a current mirror like,i know w/l ratio i want but how should i chose W and L values,is there any systematic way

what specifications do a current mirror should have

it is a simple bandgap reference schematic with VBGR plot for VDD sweep and temp sweep,like can anyone give some inputs here

Temperature dependence curve looks good. Depends on your application. If you want less VDD dependence then you probably want to use an opamp rather than a floating mirror which will also improve your headroom if designed properly. If you want to stick with the floating mirror try increasing gm, that should reduce the voltage difference between the branches

@User Do we have a PEX extraction tool? are netgen or magic able to do that?

@User: Magic does parasitic capacitance extraction (a bit limited, as you know; the equations are about halfway between the simple-stupid equations used in LEF and the completely open-ended format used by Calibre). Magic "sort of" does full parasitic resistance extraction, but there is currently a limitation that it does not understand the substrate. So if all transistor bulk terminals are tied to the power rails, then you can work around the issue by substituting into the output netlist. Fixing this is high on my to-do list for things to get done before the next shuttle run.

@User Thanks, substrate currents and well diode are important in PEX simulations. So thanks for planning on working on that. Do you know if the current PEX netlist could be simulated using commercial tools? -- just for comparison purposes

A full R-C extraction is not simulatable until you replace the "error" nodes in the netlist with the appropriate power or ground net. Long ago, magic didn't extract 4th terminals of devices and used global power and ground net names. I fixed that in the extraction, but the full R-C parasitic extraction code was never rewritten to take advantage of that; it unfortunately wants to write connectivity information and read it back in via the ".sim" file format, which is for a switch-level simulator (IRSIM) that does not even care about substrates and wells, and so just represents all transistors as 3-terminal devices. So the well and substrate nodes get completely obliterated. I need to get it to stop using the ".sim" format and just pull all information from the ".ext" format files, which have everything needed for the parasitic extraction to understand the circuit connectivity without losing information about the wells and substrate.

Well, let me know if you need a tester when you have that ready. My temp sensor is mostly done now, just working through clean-ups and update to the latest libraries (still on s8 because of PEX)

Whats/where are the best instructions for setting up the ngspice + magic toolchain right now?

@User: There are several different potential flows there, depending on whether you are starting with a schematic or just want to extract and simulate a layout. There are additional options if the layout has digital blocks in it. Can you describe the flow you are looking for?

Hello All, I was wondering if anyone had any suggestions on where to look for doing Analog Behavioral Simulations with open source tools. I would ideally be running Verilog-A along side spice models however my understanding is that this is not currently possible using open source tools. Another option would be to build what would be the Verilog-A model using only spice with Xschem, in this case does Xschem support creating an equation controlled source and does NGSpice support simulating one? I would also be interested in trying Xyce if NGSpice doesn't support this, but I have not had good luck with Xyce and sky130 in general. Something like the BI and BV functions in LTSpice? Thank you all for any help you can provide!

I was interested in creating some analog cells that could be automatically placed and routed. Is there some standard for analog cell size / has anyone proposed a standard size?

I have yet to start layout for anything, but given that things would possibly be placed along side sky130_fd_sc_hvl cells, that might work?

That cell size is possibly a bit small for analog stuff though. Any odd multiple of the 4.07um cell height should work though?

@User xschem is quite flexible for netlist generation. When you create a new component you define how the component gets netlisted in the spice netlist. One example is the standard

devices/bsource.sym

component where you can specify an arbitrary equation for voltage or current. Another example is the

devices/switch_ngspice.sym

that models an ideal switch. VerilogA primitives could easily be created and placed in a schematic and should link to some compiled verilogA code. I have not done specific tests on ngspice, i did that in the past on Hspice.

Does anyone have any examples of using netgen for doing LVS for mixed signal (digital cells and analog)? I am having problems getting the digital cells to be flattened in the spice files. Looking through the pdk provided sky130A_setup.tcl script for netgen there seems to be specific code to handle the digital cells. But that code seems to actually be preventing the logic cells from being flattened to the transistor level. So if I flatten my layout in magic they do not match.

i.e., if I rename the digital cell to something not matching the sky130 library I will pass LVS because it gets fully flattened.

@User: Please grab the latest versions of magic, netgen, and open_pdks. I spent a lot of time over the weekend and into yesterday fixing some major issues that cropped up during the run-up to the first MPW tape-out. Early on, I discovered that large digital standard-cell layouts were taking forever to run through LVS, and I introduced a "quick hack" solution which I only got around to analyzing thoroughly yesterday. I now have a fixed version of netgen that resolves that issue, although it depends on an updated setup file for sky130 on netgen. If after the update, you still have issues with LVS, then send me an example.

@User ^

Good to see some nice analog and rf designs made the tapeout. The other developer on one of my with projects is ramping up to full time so I'm hoping to have time to jump back into design

Hi @User, I am also trying netgen with the LVS check but got some issues. The comp.out file shows

Flattening unmatched subcell *

in the beginning, is this an expected behavior? Also, I found the

sky130_fd_sc_hd__conb_1/short

resistors in

sky130_fd_sc_hd.spice

have three ports, while the

sky130_fd_pr__res_generic_po

resistors extracted from magic only have two ports, which is causing an LVS issue in my case. I have attached my files below. My magic version is 8.3.134 and the open_pdk version is 1.0.134. Thanks in advance!

@User: The conb cells are a known issue. . . they need to be changed from type

short

to type

sky130_fd_pr__res_generic_po

and have the third terminal removed. I believe this is the case with all of the standard cell libraries. I think that's the only issue with running LVS in your design. Since your "tempsenseInst_lvsmag.spice" file is a flattened netlist, then yes, it is expected behavior for netgen to flatten all of the standard cells in 6_final.spice since none of those exist in tempsenseInst_lvsmag.spice. If you want a full hierarchical comparison from netgen, then you need to generate a full hierarchical netlist from magic.

Thanks for the explanation!

Hi @User, when I do the extraction with magic (the "tempsenseInst_lvsmag.spice"), the size of the transistors look like

w=550000u l=1.05e+06u

and it causes a mismatch. According to some previous messages, should I use

.option scale

to solve this issue? Thanks

@User: The size of the transistors should be okay. What sort of mismatch messages are you getting? You don't want to use ".option scale"; I'm doubtful that netgen will even recognize it.

The sizing of the custom cell HEADER.spice I used before (in s8) is defined as

w=0.70 l=0.50

, while the extracted version is

w=700000u l=500000u

, I think that is the cause of the mismatch. The same thing happens in the SLC.spice (another custom cell). I have modified the sizing to match with magic's output, I also changed tran's name from

mMN0

to

xMn0

. Now these mismatch issues are gone.

@User: The "m" instead of "x" is certainly going to cause a problem. Netgen is supposed to be able to figure out that "700000u" is equal to "0.70", though, which is why I was hoping that you could post the error message where it states the property error so I can figure out why that doesn't work. The weird "700000u" number comes from the fact that magic is used to generating microns in the output and so I had to scale up the values in front of the "u" to get the units to come out correct. Some time when I get the chance, I'll modify the code in magic so that it will automatically figure out that removing the "u" and scaling down the value makes a more readable output.