I’m having many problems with a switching power supply simulation.
I think most of them are from the sheer number of points it is generating.
The .qdraw file is 147 gigabytes for 29 mS of simulation.
I don’t see any way to reduce the number of points.
LTSPICE does work, but takes about 6 minutes to run, which is still really slow.
QSPICE is taking at least 2 hours, if it will solve at all.
An interesting point is that LTSpice is using all the CPU cores/threads, and QSPICE appears to be using one core/thread.
Before the V() supply source is started, there are negative supply voltages that shouldn’t exist, and extremely high speed oscillations around the inductor components. Minor circuit changes can get into the gigahertz ranges. Nothing in the circuit needs these speeds. It is running at about 110 KHz.
Circuit literally take 2 hours to run, and when done, the post processing of the two .meas commands takes so long I gave up waiting.
When waveforms reach the right side of the screen, it redraws all the waveforms multiple times, the longer the simulation, the more times it redraws the waveforms(twenty times with a 20mS simulation) before readjusting the waveform in the window.
It doesn’t do this if the waveform hits the top of the window.
With the simulation running for 20mS each screen redraw take two seconds with three waveforms.
If you select another trace to look at while the simulation is running (shows in status bar) the graphing updates come to a halt for multiple minutes. Also both windows essentially lock up until the graph operation redraws with the new waveform.
If you abort the simulation and add some .plot commands, then rerun the simulation, the plotting window doesn’t update.
To show the changed plots, you have to close the plotting window first before you restart the simulation.
The plotting window doesn’t seem to synchronize with the simulation, depending on if it is done with the run, rerun and restart commands.
Finally, I’m getting different efficiencies between LTSPICE and QSPICE. QSPICE is 6% lower.
Circuit is quite simple, one inductor, one switching FET, one small signal FET, one comparator, one op-amp. Does 7.5 volts in ±450 volts out. Diode voltage multipliers.
The part I find that is really odd is the signals for the first 100uS with no power applied.
Any suggestions on uploading the circuit and models.
System says it won’t allow won’t allow a .zip file?
When I try the individual files it says new users can’t upload attachments.
There are 14 files with symbols, models and schematic.
I tried the “.opt method gear”, no real difference.
The circuit I would upload is simplified to remove some input current limit circuits to speed things up, and only take about 50 minutes for 12mS of simulation.
V3 is the power, V1 starts the self oscillating circuit, R1, R7 and R8 are loads.
V4 and V5 can be set to +415 and -415 volts to speed things up.
Are low now to ensure the circuit starts under load.
I tried using the QSPICE op-amp, no help.
V3 starts off at zero volts until 100uS, but nodes in the circuit have power and oscillations.
By removing the TI models (TLV3201 and TLV9002) and replacing them with behavioral models, the simulation can run without needing to solve its DC solution using pseudo-transient analysis. However, I still need 3 to 4 minutes to complete this simulation without the TI models, and I am not quite sure if the results match your expectations.
Initially, I wanted to run a comparison result in LTspice (call to use TI model), but it takes too long with pseudo-transient analysis, so I eventually give up.
This is clearly much faster, still a bit slower than I expected at about 6 minutes for a 16 mS simulation.
Was X1 something you made, or did I miss it in the QSPICE distributed files?
On the original circuit, where did the negative voltage on +5V and the oscillations come from during the first 100uS and the ringing until the 500uS trigger even though there was no power applied. I’m assuming somehow from the comparator, although it was a problem with both the TI and Maxim parts.
I added the power input current limit circuitry I had removed and that also works now.
Notice on the plotting window, when the traces hit the right hand side of the graph window they all get redrawn, the longer the simulation runs, the more times the waveforms are redrawn before the window readjusts. It works correctly when they hit the top of a graph.
V4 and V5 should be “Do not stuff”. the current will decrease and the and pk voltage will build up until regulation occurs.
For X1 and X2, they are behavorial model I made and shared in my Github. Qspice also with build-in device (press F2 to bring Symbol & IP Browser), SCHMITT (behavioral > gates) is comparator, OpAmp (behavioral > analog) is opamp. Sometime I took my model as I can setup them faster.
For negative voltage in +5V before V3 is active, it hard to say. If you look into TI model (open their netlist), you can see that they include voltage source in modeling. Frankly, I normally not to include these type of complicated .subckt model in my simulation for complex circuit simulation, as they normally bring more harm than good. I may use these model for the device performance study, but seldom include into a complex circuit. If you disable all external voltage source in your schematic, it seems that you still get that negative voltage at +5V, therefore, I believe the weird behavior is from one of the complex .subckt
Yes, the graph redraw. As this simulation run relatively long and timestep seems reduced to quite small, data size is huge. You can imagine that waveform viewer has to load from such a huge data file and plot it, may need quite a processing. In default, Qspice write data into datafile with at least 2ps for two datapoint. For your simulation, you can add “.option CULLTIME=10n” to force Qspice only write data into .qraw file with at least 10ns between two datapoints, with that, you give up data points, but will speed up everything in waveform viewer as it don’t have to load a Gb file.
I believe other experts may also interest to answer your questions, and they have more experience in dealing with various MFG model, and may give you a better and correct explanation or idea to resolve your problem.
By the way, this simulation file can run with TI model, just very slow. May be 15 mins in my laptop up to 4ms (I am out of patient and terminated the simulation after it almost steady).
I added two lines in schematic
.option fastmath=0 method=gear trtol=7 ; to run TI Pspice model
.option culltime=10n ; to limit .qraw data rate, can disable, just to speed up waveform viewer processing
If fastmath is disable (i.e. to use Qspice80.exe with 80 bits math), this simulation will not run into pseudo transient analysis and can begin simulation immediately. Possibly TI PSpice model need more precision math to support that in this setup. Pspice in default is trtol=7 and gear integration, therefore, setting these two to match Pspice. Culltime is just to reduce the size of .qraw to speed up waveform viewer process.
I think you missed my point on the graph redraw.
It’s not that it takes time to do the graph, it’s that the plot will reach the right side and instead of moving all the plots to the left and continuing, it will sit there redrawing the plots over and over. Sometimes more than twenty times depending on how long the simulation has been running and then move the graphs to the left and continue.
The culltime option doesn’t fix this.
What I observed from the waveform viewer during the simulation run seems normal to me (refer to youtube video below). Is this the ‘problem’ you observed, or are you referring to something else?
My point regarding the culltime is that, for such a lengthy simulation, every time a redraw is triggered, it can consume a lot of processing time. When you run your simulation with the TI model included, it has to write 468 node voltages or device current variables into the .qraw data file, and the number of data sets is around 650k points for just 500us (default culltime, and reduce to 50k points with 10ns culltime). If you allow a huge dataset to be fed into the waveform viewer and its nature is to keep updating the time tick during the simulation without some management (e.g., using .save as @bordodynov mentioned, or culltime), what you can expect is that waveform viewer will require a significant amount of computational work.
If you don’t want the plot to keep auto-updating its time tick during a long-running simulation, when the waveform window pops up, right-click on the x-axis, set the Right to 12ms (same as your Tstop), and the time tick will not update. You can save this plot configuration in the waveform viewer, and the next time you run the simulation, go to the waveform viewer, press “spacebar,” and it will load this user configuration.
This is a bit long, and I would have replied earlier, but apparently there is a limit in the number of posts in a 24 hour period.
At about 1:31 in the video, the traces hit the right hand side and redraw twice before readjusting to leave some blank space for the waveforms to continue drawing into.
This never happens when a waveform hits the top, only on the right. This masks the problem.
Make sure the traces aren’t hitting the top. Change the scale on V(pk) to 250 volts or do the simulation with V4 and V5 as "do not stuff, so there is a steady state with all waveforms inside their display windows.
This gets worse the more nodes in the schematic and the longer the simulation runs.
At 10mS into the simulation, when the waveforms reach the right hand side, all three waveforms will redraw eight times in a row before leaving some blank space, and continuing.
When I had the TLV3201 in the schematic, it would redraw twenty times in a row.
I had mentioned in the beginning of this post about the two windows not being synchronized. If you abort the simulation or just wait for it to finish then add to or comment out some of the plot commands in the schematic and rerun the simulation. The changes made don’t show up in the plotting window. You have to close the plotting window and then start the simulation to update the plotting window.
For the second part of your question, .plot command only active if you don’t have an active waveform viewer AND you didn’t save a plot config file (.pfg) in same name of schematic file in waveform viewer. Below is my testing and can be found in my General Guide in my Github, I think it still follow such rule currently.
In short, if you want the plot to follow .plot everytime, don’t save a .pfg, and close waveform viewer before next run. I have a practice to close waveform viewer everytime as I want thing to follow .plot.
For the first part of your question, well… I normally look into result after simulation complete, and I never run a very lengthy simulation and therefore, how waveform viewer update its data not actually annoying me. If you really think this is a bug, you can report it : goto Qspice > Help > About Qspice, and you can find the contact.
Community can normally give you opinion of how to deal with certain situation, but we cannot do anything if a feature or function not meet user expectation.
I will probably report both of these.
I really think that if a simulation finishes and you modify something on the schematic and then restart the simulation, the modifications shouldn’t be ignored.
Even though the multiple redraws of identical data doesn’t affect most users, it does seem likely that this is a bug, since it doesn’t do this when the data hits the top instead of the right side.
With some circuit mods and trtol = 7, I now have an LTSPICE version with TI parts running in normal mode instead of alternate mode.
A 12mS simulation is now 56 seconds which is much faster than I had before.
So far with QSPICE, with the behavior models you gave me instead of the TI parts is taking 132 seconds.
Not sure why QSPICE with behavior models is slower than LTSPICE with TI parts.
With the TI parts QSPICE is really slow, I quit after 30 minutes.
If you or anyone else is interested in doing more investigation on this, let me know.
I’ll probably keep working on it. I’d like to see QSPICE be faster.
I did the calculation on my home laptop and was able to reduce the simulation time by almost 2.5 times. I present the results and changes of the scheme below: