This is the transient variation of the LDO output with varying supply from 0 to 2.2v in 1uS .. can this be considered as a stable response where it only needs settling time or it is an unstable response due to the overshoot at the start?

@User we can see that it is stable because it settles to a steady state value. But normally being strictly stable is not sufficient. Some ideas: 1. What is the phase/gain margin? 2. Do you know where your poles and zeros are? 3. Can you determine anything about the dynamic behavior of your circuit if you assume it's second order and look at the overshoot to find a Q value?

good phase margin of about 70 degrees at 10mA load

Do you have 10 mA load in the plot you showed?

Yes but at no load the phase margin is about 40 degrees so i think i couldn't support full stable range >>for now the minimum load to get PM>50degrees is 50uA

@User: Sounds like a digital project check that was improperly ported directly to the analog project checks. I'll check with the team working on the precheck scripts.

Thank you :) I can see that it would naturally make sense where the project is all digital, yeah

@User I'm trying to use xschem to draw a simple schematic, but none of the keys are working except insert. So it's very annoying to zoom, move, copy or wire things as everything has to be done through menu clicks. This is running in a VM. Ever seen this before?

@User has left the channel

How does multiplier works in res_xhigh_po since i didn't find any change in resistance value when varying multiplier

@User taking the

sky130_tests/test_res.sch

, setting mult=1 on first simulation (top picture) and mult=4 on second simulation (second picture) on R9 (res_xhigh_po) affects resistance. The second resistance (500 Ohm) is 1/4 the first resistance (2kOhm). Resistance is measured as v(res)/I(res) vs temp. The resistor '`mult`' parameter is assigned in netlist both to ngspice

m

parameter and

mult

parameter. Ensure your open_pdks installations is reasonably recent.

we are running post layout simulation for a simple inverter included in the following files: but we get zero output as shown below Any help @User @User Thanks in advance

I'm Ali Elshorbagy and I'm working at Mabrains, I made a small testcase to document a weird behaviour that i found when using loops inside ngspice. I'm simply doing dc sweep on sky130 nfet transistor on different widths and lengths. I just change the device parameters inside while loop inside control statement. I found an unexpected behaviour. Initial value for width and length affect solution values.  Normal behaviour during simulation is initial values will be replaced by values given inside the loop but surprisingly i found that initial values affect the results. In this git repo i have 2 netlists (netlist1.net and netlist2.net) exactly the same but initial value for width and length are different. When i invoke ngspice to run those two netlists i have a completely different results https://github.com/mabrains/xyce_sky130/tree/main/testcases/ngspice_loops_behaviour I found a similar behaviour whe i used .data inside Xyce and can be found here: https://github.com/mabrains/xyce_sky130/tree/main/testcases/Xyce_data_behaviour @User @User

ngspice_comparison.webm

I did a comparison script that compare Xyce and ngspice results for different type of sweeps. I tried dc sweep for sky130_fd_pr__nfet_01v8 for tt corner simulating all Bins w and L in the model and i found max error between the two simulators was 0.033% Here is the link for comparison script and results. https://github.com/mabrains/xyce_sky130/tree/main/testcases/xyce_vs_ngspice @User @User @User @User

I am designing an ldo with its bandgap circuit..i have a problem that when i inserted the bandgap circuit inside a symbol the .nodeset lines are ignored so the simulator gives wrong solution at some points. The same circuit placed in another schematic not inside a symbol gives reasonable results,but when i remove .nodeset lines from this schematic it gives same unreasonable results as the same circuit inside a symbol What should i do so that the .nodeset lines are not ignored in the schematic inside symbol

Anybody building High-speed ADC/DAC in #sky130 ?

@User consider that ngspice flattens out the circuit netlist before starting building matrices and solving the ODE equation system. For this reason you always must bring the

.nodeset

lines to the top level, so if bandgap has a

.nodeset v(a)=0

and bandgap is placed as instance

x1

, the nodeset must become

.nodeset v(x1.a)=0

at global scope (that is, outside the bandgap

.subckt

..

.ends

) EDIT i verified that a .nodeset in a schematic placed as a symbol in another schematic gets expanded by ngspice: for example a .nodeset v(c6)=-40 placed in a schematic placed as instance x1 will be expanded by ngspice as: .nodeset v(x1.c6)=-40 So my above statement is wrong.

@User also consider that if a circuit works well with some .nodeset conditions there are probably more equilibrium states for the circuit. Bandgap references typically need a startup circuit that removes the unwanted equilibrium state. These start up circuits must be always active ("static" startup) , whenever the bandgap leaves the "on" state for whatever reason (vcc/gnd noise, coupling, whatever) startup circuit must kick in and pull the circuit back to the "on" state. Historically implementations with a "dynamic" startup, like something pushing the bandgap high on poweron and then doing nothing have produced references that in some misterious situations turn themself off. This should never happen. When a good "static" startup circuitry is added normally the circuit does no more need any .nodeset to converge to the right (and now unique) solution.

I have posted a feature request for ngspice --> allowing .save instructions to be placed inside .subckts @User @User do you think it's a reasonable request? allowing .save inside subcircuits allows the important nodes to be automatically saved whenever these blocks are used in a bigger analog circuit. This improves reusability and the analog designer does not need to take care of manually saving "important" internal nodes of analog symbol libraries. Looking at the ngspice frontend code this looks simple to implement (the same is already done for .nodeset cards).

Last 12hrs - VSDOpen Sky130 tapeout tutorial For Analog Design aspirants For so many years, you have been asking for Analog Design Workshop by Analog Expert - There you go. Here's tapeout quality Bandgap Design using Sky130 2-day cloud lab based tutorial by Dr. Saroj Rout, Adjunct.Prof. and Asst. Prof. Santunu Sarangi from Silicon Institute of Technology who has spent many years designing bandgap IP using XFAB. It was an honour to have them on board and share their entire learning on the VSD-IAT platform. Guess what - This tutorial is totally hands-on from circuit to layout, as seen from images, and all of them using Skywater 130nm PDK, so it's completely manufacturable Features - Low cost ($25), 2-day, cloud lab based workshop Timings - You can login at your own convenient time during 24-hrs duration of the workshop and start with lectures/labs at your own pace Workshop Start date - 20th October, 11:59pm IST Workshop End date - 22nd October, 11:59pm IST Registration link (Last 12hours)- Indian Participants- https://pages.razorpay.com/bandgapinr International Participants- https://pages.razorpay.com/bandgapdollar All the best and happy learning

@User My expectation is that if the problem is with the start up circuit then the gate of the mosfets within the core of the bandgap will be pulled to vdd (this never happened for me) ,but i found that sometimes the simulator solves the dc sweep on supply correctly (when inverting the sweep from maximum to minimum) although it solved wrong operating point which is used in ac simulations i need to measure the psrr which is the reason why i use nodeset also note that despite using nodeset the simulator fails to solve at some corners

@User If you have any resources for static start-up circuits please publish them

Just a reminder to everyone that Google has search setup for the PDK @ https://cs.opensource.google/skywater-pdk -- It can make it easier to see things like the .svg graphs of the FETs @ https://cs.opensource.google/skywater-pdk/sky130_fd_pr/+/main:cells/pfet_01v8/tests/sky130_fd_pr__pfet_01v8_ids_v_vds.svg

Hey Guys I'm trying to integrate the sky 130 open pdk with xschem for some reason it's missing the 20 volt spice models any idea why this is the case ???

@User Currently xschem assumes you install the pdk via open_pdks. If you do so the open_pdks adds the 20v0 transistors, you just need to do a

.lib /path/to/share/pdk/sky130A/libs.tech/ngspice/sky130.lib.spice tt

, otherwise you have to manually include a model file in addition to the .LIB statement.

@User with previous xschem + skywater-pdk installed alone (not as part of open_pdks) this was the situation:

@User I installed it with openpdks itself I'm still getting the same error.

I'll just add the path manually

@User this is strance since the

.../share/pdk/sky130A/libs.tech/ngspice/sky130.lib.spice

includes

corners/tt.spice

and this one includes the 20v0 transistor models at the bottom:

* SKY130 Spice File.
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_01v8__tt.pm3.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_01v8__mismatch.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_01v8_lvt__tt.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_01v8_lvt__mismatch.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_01v8__tt.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_01v8__mismatch.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_03v3_nvt__tt.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_03v3_nvt__mismatch.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_05v0_nvt__tt.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_05v0_nvt__mismatch.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__esd_nfet_01v8__tt.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_01v8_lvt__tt.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_01v8_lvt__mismatch.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_01v8_hvt__tt.pm3.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_01v8_hvt__mismatch.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__esd_pfet_g5v0d10v5__tt.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_g5v0d10v5__tt.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_g5v0d10v5__mismatch.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_g5v0d16v0__tt.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_g5v0d10v5__tt.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_g5v0d10v5__mismatch.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_g5v0d16v0__tt_discrete.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__esd_nfet_g5v0d10v5__tt.corner.spice"
.include "tt/nonfet.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_20v0__tt_discrete.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__pfet_20v0__tt_discrete.corner.spice"
.include "../../../libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_20v0_nvt__tt_discrete.corner.spice"
.include "../all.spice"
.include "tt/rf.spice"