Bob Cordell said:
I used Micro Cap for several years before switching to LTSpice. It is nice to use once the usual idiosicracies are sorted out. Magnetics are a pain in terms of speed, and FFT is not as easily worked with - tough this may be lack of expertise in my part, which also applies to LTSpice.
Models inserted in the spice text are surprisingly strightforward to work with unless you want to mess around with libraries.
I guess Bob is right about LTSpice, in fact I recall something about critical code rewriting for switching environments in the help section.
Rodolfo
PD. I know this is abusive, but Andy, could you refresh us about tricks regarding clean FFT's ....i.e. proper timestep selection, hacks etc....
ingrast said:I know this is abusive, but Andy, could you refresh us about tricks regarding clean FFT's ....i.e. proper timestep selection, hacks etc....
Hi Rodolfo,
Sorry I missed your post earlier. The only thing I do is a trick I learned in the LTSpice users' group. That is to first figure out the integer number of cycles over which the FFT will be taken. Then take the time span for this and divide it by (number of points in the FFT - 1) and choose that as the maximum time step for the transient sim. Then, when doing the FFT, choose an FFT stop time equal to the stop time of the transient sim, and the FFT start time as the stop time minus the time span for the integer number of cycles chosen. I usually simulate about twenty cycles total and take the last four or so. But this is only for viewing the spectrum plot.
If it's just harmonic distortion that you're concerned with, just use a "dot FOUR" directive in the schematic. This makes LTSpice automatically choose the last cycle of the transient sim for the FFT - freeing you from having to specify it. So in that case, I just take the time of one period and divide it by (number of points in FFT - 1) to get the maximum time step for the transient sim. The results from "dot FOUR" can be seen as text using "View, SPICE error log" after the transient sim completes. The text can be copied and pasted into Excel, which will parse them into columns nicely.
The idea of the time step choice is to make the FFT points coincident with the simulation points so LTSpice doesn't have to interpolate to get the FFT points. Of course, one must use ".options plotwinsize = 0" to disable waveform compression.
That's as far as I go with it. I've seen plots from JCX that have a residual way lower than mine, but I don't know what technique he's using. Maybe he could chime in. I'm not a DSP person, so I"m not familiar with all the windowing options and their advantages and disadvantages.
That's all I know
Since there hasn't been much response beyond the initial discussion about a SPICE sticky thread, let me propose something.
"Electronics and Parts" has traditionally been the focal point of general CAD discussion, mainly about PCB design software. Also, there have been a lot of good posts about SPICE techniques that cover all device types - tubes and solid state, magnetics and other passives, scattered among the tubes forum and the solid state forum, and the power supplies forum as well. I'm proposing a post in "Electronics and Parts" that would introduce the idea of a focal point for SPICE-related tips, tricks and models - including model extraction techniques. It could start with a post containing links to other threads with useful information in this category, as well as links to external web sites with useful information.
If there is interest in such a thing, I'd be willing to serve as an email focal point for the initial post containing the links. What I'd like to see would be a link to the discussion or information in question, a short description of what the discussion is about, and a short description of why you think the discussion is important. Then I could condense this into a post that would kick the thread off. Maybe some of the previous posts in this thread, with tips about FFT techniques for distortion analysis, could be moved there, since they're off-topic for "BJT vs. MOSFET". I would ask, in return for this effort, that the moderators make this post a sticky.
Regarding the Wiki, I got the impression that the whole Wiki concept was born of the not-too-swift computer science concept of "learn a new computer language for every task to be performed". That's fine if, in learning the language, one can re-use the acquired skills for other useful things. Learning HTML is a good example of this. As I get older though, I become much less tolerant of abuses of my time, and the Wiki appears to be to be a classic example of that. Of course, I could spend the time to learn the Wiki techniques, but it appears their only application is yet further time abuse. So I am less than enthusiastic about the Wiki, unless there were some breakthrough that would greatly simplify the process.
"Electronics and Parts" has traditionally been the focal point of general CAD discussion, mainly about PCB design software. Also, there have been a lot of good posts about SPICE techniques that cover all device types - tubes and solid state, magnetics and other passives, scattered among the tubes forum and the solid state forum, and the power supplies forum as well. I'm proposing a post in "Electronics and Parts" that would introduce the idea of a focal point for SPICE-related tips, tricks and models - including model extraction techniques. It could start with a post containing links to other threads with useful information in this category, as well as links to external web sites with useful information.
If there is interest in such a thing, I'd be willing to serve as an email focal point for the initial post containing the links. What I'd like to see would be a link to the discussion or information in question, a short description of what the discussion is about, and a short description of why you think the discussion is important. Then I could condense this into a post that would kick the thread off. Maybe some of the previous posts in this thread, with tips about FFT techniques for distortion analysis, could be moved there, since they're off-topic for "BJT vs. MOSFET". I would ask, in return for this effort, that the moderators make this post a sticky.
Regarding the Wiki, I got the impression that the whole Wiki concept was born of the not-too-swift computer science concept of "learn a new computer language for every task to be performed". That's fine if, in learning the language, one can re-use the acquired skills for other useful things. Learning HTML is a good example of this. As I get older though, I become much less tolerant of abuses of my time, and the Wiki appears to be to be a classic example of that. Of course, I could spend the time to learn the Wiki techniques, but it appears their only application is yet further time abuse. So I am less than enthusiastic about the Wiki, unless there were some breakthrough that would greatly simplify the process.
Just to kick things off, I wanted to add a link to a post from the Tubes forum about a program called CurveCaptor. Here is the link:
http://www.diyaudio.com/forums/showthread.php?s=&threadid=56327
I'd love to have something like this for creating models of solid state devices. It would be cool to be able to specify the graph area, data limits on x and y axes, and whether each axis is linear or log. Then, to be able to get just the V-I values from the graph would be great. When I do my own models, I have to painstakingly read the values from the graph manually. Ugh!
As you can see, the tube guys are doing some fantastic work in the area of SPICE model development.
Edit: Looks like the Engauge Digitizer might be just the ticket for this application.
http://www.diyaudio.com/forums/showthread.php?s=&threadid=56327
I'd love to have something like this for creating models of solid state devices. It would be cool to be able to specify the graph area, data limits on x and y axes, and whether each axis is linear or log. Then, to be able to get just the V-I values from the graph would be great. When I do my own models, I have to painstakingly read the values from the graph manually. Ugh!
As you can see, the tube guys are doing some fantastic work in the area of SPICE model development.
Edit: Looks like the Engauge Digitizer might be just the ticket for this application.
ingrast said:
Yes, I got the evaluation, thanks. I'm sure I will use it often. Usually when I make models of various types, the time-consuming part comes from getting the data from the datasheet graphs. For example, in fitting the gate-drain capacitance to datasheet values for the LTSpice VDMOS models, I grab about 20 points of capacitance vs. voltage to fit the capacitance formula. I basically sit there in front of my computer with a ruler trying to get the data point values. Then there's the issue of interpolating on log scales. It's very tedious and time consuming. That's where I think this "Engauge Digitizer" can help. Hopefully it can deal with log scales.
Also, I'd like to eventually learn a systematic way to get BSIM3 parameters for MOSFETs. If I could grab a ton of points very fast with the digitizer and bring them into Excel, it would be a snap to determine how close the model fits the data once the formulas for the model have been entered into Excel.
bogdan_borko said:
I'm not using CircuitMaker but I can help with LTSpice.
I've found through experience that it is not a good idea to modify existing LTSpice libraries. Here's why. If you wish to share a simulation with someone else (such as posting it here), and you have added a certain model to your library and the other person has not, then any simulation using that model will not run for the other person because they don't have your model.
A better, but more tedious way, is to just take a copy of the model file, say, mymodel.mod, and put it in the same directory as your .asc simulation file. Then manually add a SPICE directive to your schematic to use this model file. This is done by pressing the "S" key, then entering the text ".include mymodel.mod" without quotes. Of course, just replace "mymodel.mod" with the actual name of the model file.
Let's say that mymodel.mod contains this text:
.MODEL mjl3281a npn(...model parameters here...)
To change the default "NPN" transistor type for example, do not right-click on the transistor and use the normal "Pick New Transistor" option. Instead, just right-click on the text of the device where it says "NPN" and paste in the model name (in this case "mjl3281a" without quotes) into the dialog box where it currently says "NPN". Then LTSpice will look for "mjl3281a" instead of "NPN" when it goes to run the simulation. Because you have added a ".include mymodel.mod" SPICE directive and mymodel.mod contains the definition of the mjl3281a model, it will find the model.
AnaSoft SPICE Models
I go searching for spice models every so often when I'm working on a project and I came across AnaSoft here many years ago. I don't recall which models I used so I cannot comment on them. Anyone else have comments concerning these models:
http://www.anasoft.co.uk/links.html
Pete B.
I go searching for spice models every so often when I'm working on a project and I came across AnaSoft here many years ago. I don't recall which models I used so I cannot comment on them. Anyone else have comments concerning these models:
http://www.anasoft.co.uk/links.html
Pete B.
Intusoft SPICE models
I have been impressed with Intusoft's products over the years and purchased IS-Spice back in the early 80s, running it on an XT, yep it was SLOW. I did not use it much, but it did seem to be a quality product.
I seem to have (some?) of Intusoft's libraries from much later - 2002 but I'm not sure if they are free or not:
http://www.intusoft.com/products/icapsSPICE_Model_Libraries.html
Has anyone else used them?
Intusoft had an excellent news letter and I also have several of their books.
Pete B.
I have been impressed with Intusoft's products over the years and purchased IS-Spice back in the early 80s, running it on an XT, yep it was SLOW. I did not use it much, but it did seem to be a quality product.
I seem to have (some?) of Intusoft's libraries from much later - 2002 but I'm not sure if they are free or not:
http://www.intusoft.com/products/icapsSPICE_Model_Libraries.html
Has anyone else used them?
Intusoft had an excellent news letter and I also have several of their books.
Pete B.
I've been playing around with the freeware Engauge Digitizer a bit. In doing SPICE model parameter extraction in the past, I've been painstakingly reading values from graphs manually. This is very time consuming, boring, and not very accurate. I record these values into Excel and use some least-squares techniques with the Excel solver to find a set of model parameters to get a best fit to the data. After seeing a reference to the Engauge Digitizer in a thread in the Tubes forum I decided to check it out.
Wow! I'm embarrassed to think how much time I wasted manually reading data from graphs. This tool is great! The documentation is very well written. Without having to study anything, you can get up to speed immediately and start grabbing data just by reading the step-by-step instructions in the help files.
Here's how it works. You get a graphics file containing the plot whose data you'd like to fit. I just use the freeware IrfanView to get a screen capture from the PDF file of the datasheet in PNG format. Then you use File, Import to bring the file in. Then, using the mouse, you mark three axis points (left x-axis, right x-axis and top y-axis) and their x and y values. You can specify whether each axis is linear or log. Then you just click on the curve and it automatically grabs a whole bunch of x,y pairs from the curve. You can specify as many curves as you want. Then you just do a File, Export and it will save a comma-separated file (.csv file) that can be brought directly into Excel. Way cool!
I wish I'd known about this tool when I first started doing model parameter extraction. I could have saved myself many hours and gotten better data in the bargain.
I'd encourage anybody doing model parameter extraction to try this tool out.
Wow! I'm embarrassed to think how much time I wasted manually reading data from graphs. This tool is great! The documentation is very well written. Without having to study anything, you can get up to speed immediately and start grabbing data just by reading the step-by-step instructions in the help files.
Here's how it works. You get a graphics file containing the plot whose data you'd like to fit. I just use the freeware IrfanView to get a screen capture from the PDF file of the datasheet in PNG format. Then you use File, Import to bring the file in. Then, using the mouse, you mark three axis points (left x-axis, right x-axis and top y-axis) and their x and y values. You can specify whether each axis is linear or log. Then you just click on the curve and it automatically grabs a whole bunch of x,y pairs from the curve. You can specify as many curves as you want. Then you just do a File, Export and it will save a comma-separated file (.csv file) that can be brought directly into Excel. Way cool!
I wish I'd known about this tool when I first started doing model parameter extraction. I could have saved myself many hours and gotten better data in the bargain.
I'd encourage anybody doing model parameter extraction to try this tool out.
processing .WAV files, "initializing circuit matrix" message
Finally I found what's behind the enormous delay that LTSpice uses to exhibit when processing .WAV files, showing the message "initializing circuit matrix..."
I switched off virtual memory, just having my 160MByte of real RAM on this PC (PII, 500MHz), and fiddled a little with different .WAV file sizes. Eventually LTSpice complained "Could not allocate 90,316,800 more bytes in one contiguous block" when I tried to link a 128 seconds long mono .WAV file (16bit/44.1kHz) to a voltage source. The .WAV's filesize was 11,296,768 bytes
Dividing the numbers gives us a factor of 8, this means it allocates (and fills) a huge memory array with 16 bytes per sample. This might come from one long double (8 byte) for the sample value and one long double for its time stamp value being memorized. Rather inefficient, I'd say. Once you don't have enough real RAM, windoze starts to use the swap file and that is what slows the process down, way more the CPU power. The latter I could prove with swap enabled again and using a 64 sec file (5.5MByte) which was processed almost in half the time once the data came from windows HD cache memory rather than directly from the HD when processed again.
Looks like a good aproach is to
i) really strip one's system down to the minimum memory waste (don't load the typical resident "little helper" stuff,
ii) use an OS with benign memory reqs, like WIN98SE),
iii) have only LTSpice openend,
iv) have lots of real RAM
v) and have the swap(s) on a different harddisk than your working files and system, preferably the fastest you can get or even a RAID-striped setup.
Regards, Klaus
Finally I found what's behind the enormous delay that LTSpice uses to exhibit when processing .WAV files, showing the message "initializing circuit matrix..."
I switched off virtual memory, just having my 160MByte of real RAM on this PC (PII, 500MHz), and fiddled a little with different .WAV file sizes. Eventually LTSpice complained "Could not allocate 90,316,800 more bytes in one contiguous block" when I tried to link a 128 seconds long mono .WAV file (16bit/44.1kHz) to a voltage source. The .WAV's filesize was 11,296,768 bytes
Dividing the numbers gives us a factor of 8, this means it allocates (and fills) a huge memory array with 16 bytes per sample. This might come from one long double (8 byte) for the sample value and one long double for its time stamp value being memorized. Rather inefficient, I'd say. Once you don't have enough real RAM, windoze starts to use the swap file and that is what slows the process down, way more the CPU power. The latter I could prove with swap enabled again and using a 64 sec file (5.5MByte) which was processed almost in half the time once the data came from windows HD cache memory rather than directly from the HD when processed again.
Looks like a good aproach is to
i) really strip one's system down to the minimum memory waste (don't load the typical resident "little helper" stuff,
ii) use an OS with benign memory reqs, like WIN98SE),
iii) have only LTSpice openend,
iv) have lots of real RAM
v) and have the swap(s) on a different harddisk than your working files and system, preferably the fastest you can get or even a RAID-striped setup.
Regards, Klaus
EKV modeling of power MOSFETs
Over in the "BJT vs. MOSFET" thread, there's been some discussion of the effects of taking into account the MOSFET weak inversion (sub-threshold conduction) in SPICE simulations of the crossover region behavior of a power MOSFET output stage.
There are plots in Doug Self's book of a simulated MOSFET output stage in which the input of a complementary source follower is swept with DC, and the derivative of the output voltage with respect to the input is plotted. These plots show some really nasty nonlinear behavior in the crossover region, with two sharp dips in the curve and a hump in between. It appears that Self's SPICE analysis was done using one of the traditional MOSFET SPICE model types (level 1, 2 or 3). These models don't take into account sub-threshold conduction.
But Edmond Stuart (estuart) has created some BSIM3 models for the 2SJ201 and 2SK1530 power MOSFET devices, based on actual measurements of them in the weak inversion region. BSIM3 takes into account weak inversion in its V-I characteristic. It was shown over in the other thread that when you do plots like what Self did, comparing the simulated behavior in the crossover region of a source follower using level 1 models and Edmond's BSIM3 models, that the level 1 model gives a terrible-looking result that looks like Self's, while the BSIM3 model gives a very benign, smooth behavior in the crossover region. Those plots are shown here. Some people, including myself and Edmond, have reached the conclusion that Self's "gloom and doom" about MOSFET output stages is based on a faulty SPICE analysis and is, as such, incorrect.
Because of these results, I've been interested in replacing the LTSpice VDMOS models in my power amp simulation with models that take into account weak inversion. I've described a little bit about some preliminary investigations in this post in the BJT/MOSFET thread. The result is that I decided to use the EKV model, because it's the simplest one that supports weak inversion. Also, it's well documented.
This brings me to a question that Edmond asked me in the other thread, which I'm answering here because it relates strictly to SPICE.
Hi Edmond,
I'm not using these devices, but after I'm finished extracting model parameters for the devices I do use, I could try extracting data for these if you're interested in trying them.
Here's the status so far. You probably remember that for the LTSpice VDMOS parameter extraction I did before, I was using the Excel solver to adjust the model parameters to minimize the sum of the squares of the errors between model prediction and datasheet values of drain current. This was pretty easy because the formula for the drain current for level 1 is a simple thing that fits into a single spreadsheet cell. But for EKV, the computation of drain current is somewhat complex. So I'm writing a function in Visual Basic for Applications (VBA, which is part of Excel) that computes the drain current given Vgs and Vds. This works just like a built-in spreadsheet function. Each time it's called, it fetches the values of the model parameters from the spreadsheet, and together with Vgs and Vds passed as arguments, computes the drain current using the equations from the EKV model manual. There are 17 DC parameters, so in theory at least, I could use the solver to adjust all 17. It's basically an implementation of the EKV DC model in VBA, used in conjunction with a primitive optimizer (the Excel solver) to adjust the parameters. So far, I"ve implemented about half the required equations in the EKV model manual in my VBA function. I'd like to be able to generate some test plots tomorrow.
The other thing I want to incorporate into this is using the Engauge Digitizer as described in an earlier post. This should make getting data from the graphs as painless and accurate as possible. I'll use data from two graphs to do the fitting - the output curves, and the Id vs. Vgs at a fixed Vds.
Over in the "BJT vs. MOSFET" thread, there's been some discussion of the effects of taking into account the MOSFET weak inversion (sub-threshold conduction) in SPICE simulations of the crossover region behavior of a power MOSFET output stage.
There are plots in Doug Self's book of a simulated MOSFET output stage in which the input of a complementary source follower is swept with DC, and the derivative of the output voltage with respect to the input is plotted. These plots show some really nasty nonlinear behavior in the crossover region, with two sharp dips in the curve and a hump in between. It appears that Self's SPICE analysis was done using one of the traditional MOSFET SPICE model types (level 1, 2 or 3). These models don't take into account sub-threshold conduction.
But Edmond Stuart (estuart) has created some BSIM3 models for the 2SJ201 and 2SK1530 power MOSFET devices, based on actual measurements of them in the weak inversion region. BSIM3 takes into account weak inversion in its V-I characteristic. It was shown over in the other thread that when you do plots like what Self did, comparing the simulated behavior in the crossover region of a source follower using level 1 models and Edmond's BSIM3 models, that the level 1 model gives a terrible-looking result that looks like Self's, while the BSIM3 model gives a very benign, smooth behavior in the crossover region. Those plots are shown here. Some people, including myself and Edmond, have reached the conclusion that Self's "gloom and doom" about MOSFET output stages is based on a faulty SPICE analysis and is, as such, incorrect.
Because of these results, I've been interested in replacing the LTSpice VDMOS models in my power amp simulation with models that take into account weak inversion. I've described a little bit about some preliminary investigations in this post in the BJT/MOSFET thread. The result is that I decided to use the EKV model, because it's the simplest one that supports weak inversion. Also, it's well documented.
This brings me to a question that Edmond asked me in the other thread, which I'm answering here because it relates strictly to SPICE.
estuart said:
Hi Edmond,
I'm not using these devices, but after I'm finished extracting model parameters for the devices I do use, I could try extracting data for these if you're interested in trying them.
Here's the status so far. You probably remember that for the LTSpice VDMOS parameter extraction I did before, I was using the Excel solver to adjust the model parameters to minimize the sum of the squares of the errors between model prediction and datasheet values of drain current. This was pretty easy because the formula for the drain current for level 1 is a simple thing that fits into a single spreadsheet cell. But for EKV, the computation of drain current is somewhat complex. So I'm writing a function in Visual Basic for Applications (VBA, which is part of Excel) that computes the drain current given Vgs and Vds. This works just like a built-in spreadsheet function. Each time it's called, it fetches the values of the model parameters from the spreadsheet, and together with Vgs and Vds passed as arguments, computes the drain current using the equations from the EKV model manual. There are 17 DC parameters, so in theory at least, I could use the solver to adjust all 17. It's basically an implementation of the EKV DC model in VBA, used in conjunction with a primitive optimizer (the Excel solver) to adjust the parameters. So far, I"ve implemented about half the required equations in the EKV model manual in my VBA function. I'd like to be able to generate some test plots tomorrow.
The other thing I want to incorporate into this is using the Engauge Digitizer as described in an earlier post. This should make getting data from the graphs as painless and accurate as possible. I'll use data from two graphs to do the fitting - the output curves, and the Id vs. Vgs at a fixed Vds.