Re: Ekv
Hi Edmond,
I'm not a Verilog-A guy, but comparing the Verilog-A code to the equations in the EKV manual, it looks like $vt is a Verilog-A reserved variable for kT/q, where T is the simulation temperature. I suspect it can't be assigned like a normal variable, so it seems to be a safe practice.
Yes, it's very sloppy coding. I'd call it a hack in fact. Also, the interpolation "function" is just coded inline as many times as it's called (3). I found an article on the web that states that the open-source ADMS compiler (what they use to convert Verilog-A to C) does not support functions! So that's probably why they did it that way. I've been looking for the C source for this model, but all I can find is notices that say the license does not allow redistribution of EKV C source code. Some public domain model!
I tried the "else if" thing, but the code does not follow that branch, so it has no effect. My detailed experience is in this usenet post
estuart said:Hi Andy,
What's that (undefined?) $vt thingy? A global variable? If so, sloppy programming.
As for "else z0 = 1", maybe it should read (in C) as "else if( fv < -15.0 ) z0 = 1;"
Hi Edmond,
I'm not a Verilog-A guy, but comparing the Verilog-A code to the equations in the EKV manual, it looks like $vt is a Verilog-A reserved variable for kT/q, where T is the simulation temperature. I suspect it can't be assigned like a normal variable, so it seems to be a safe practice.
Yes, it's very sloppy coding. I'd call it a hack in fact. Also, the interpolation "function" is just coded inline as many times as it's called (3). I found an article on the web that states that the open-source ADMS compiler (what they use to convert Verilog-A to C) does not support functions! So that's probably why they did it that way. I've been looking for the C source for this model, but all I can find is notices that say the license does not allow redistribution of EKV C source code. Some public domain model!
I tried the "else if" thing, but the code does not follow that branch, so it has no effect. My detailed experience is in this usenet post
andy_c said:
My main HDL experience is with VHDL, but I have done some Verilog, not that it really matters. Verilog is C like, and VHDL is ADA like, just another programming language. HDLs of course have the required features to describe hardware as I'm sure you know.
About poor code quality, and really also poor hardware design practice these could probably make for a long conversation. Seems the industry assumes that if a person is college trained that they know and understand what is required to solve real world engineering problems. You probably know how far off the mark this is, LOL. I've seen my good share of bad code and hardware design in my career. "No Silver Bullet" comes to mind which makes some good points but I do not agree with completely:
http://en.wikipedia.org/wiki/No_Silver_Bullet
This should be required reading for every professional programmer:
http://en.wikipedia.org/wiki/The_Elements_of_Programming_Style_(book)
It seems you're saying that the first if is dead code?
And if I had to guess, I'd say that the first if statement was the coder's first attempt, the second was a bug fix. The first if was left in probably with the intention of deleting it after debugging was finished. Yes, it is very sloppy, but the code might work correctly if my guess is right. Just throwing the idea out there.
Pete B.
PB2 said:
In searching around, I found some VHDL code for EKV written by the EKV authors themselves. It's in "ekv26.vhd" inside this zip file. In there, the structure of the "if" statement is much more clear. I'm going to translate the VHDL into VBA and see if that gives results consistent with the SPICE simulators.
Re: Re: Re: Re: Re: EKV modeling of power MOSFETs
This reminds me of processor emulation where we have to get exact agreement.
I've not followed the problem too closely but believe that I understand the issue. One obvious question is precision, it is difficult to determine the required precision for a long string of calculations and often single precision floating point is not enough. I believe Knuth has a chapter covering this issue.
It seems that the SPICE calculations agree and so it is probably reasonable to suspect the VB code. I trust your programming Andy and therefore I would not be surprised if you find a bug in VB, assuming it is not a precision issue.
The tedious debug method would be to single step the VB and compare intermediate values. Is there a source for the correct intermediate values? I would think that the Verilog-A code would complie as C code fairly easily, I think you mentioned a translator.
I'd guess that you already had these thoughts Andy, just offering them for discussion.
Pete B.
andy_c said:
This reminds me of processor emulation where we have to get exact agreement.
I've not followed the problem too closely but believe that I understand the issue. One obvious question is precision, it is difficult to determine the required precision for a long string of calculations and often single precision floating point is not enough. I believe Knuth has a chapter covering this issue.
It seems that the SPICE calculations agree and so it is probably reasonable to suspect the VB code. I trust your programming Andy and therefore I would not be surprised if you find a bug in VB, assuming it is not a precision issue.
The tedious debug method would be to single step the VB and compare intermediate values. Is there a source for the correct intermediate values? I would think that the Verilog-A code would complie as C code fairly easily, I think you mentioned a translator.
I'd guess that you already had these thoughts Andy, just offering them for discussion.
Pete B.
Re: Re: Re: Re: Re: Re: EKV modeling of power MOSFETs
Fortunately, VBA allows explicit declaration of variable types. I've declared all my variables as type double, which makes them 64-bit. So I think I'm okay there.
I hope it's not a bug in VB itself. That would be hard to find! My suspicion is there's some algorithm difference between the SPICE code and the Verilog-A code. Given that the two SPICE simulators have such good agreement, it's likely they are using the same algorithm, and the tiny difference is just the precision of the solution of the nonlinear equations. Now that I found the VHDL code, I'll be able to look for algorithm differences. Right away, I see the interpolation functions differ somewhat.
This problem is I don't have the source code of a "known good" reference. I'm suspicious of the Verilog-A code, and I'd trust the VHDL more I think, just because it has somebody's name on it, and that guy is one of the EKV model developers.
Thanks. Any ideas are welcome! I'm about ready to try version number 3, translated from the VHDL.
PB2 said:
Fortunately, VBA allows explicit declaration of variable types. I've declared all my variables as type double, which makes them 64-bit. So I think I'm okay there.
I hope it's not a bug in VB itself. That would be hard to find! My suspicion is there's some algorithm difference between the SPICE code and the Verilog-A code. Given that the two SPICE simulators have such good agreement, it's likely they are using the same algorithm, and the tiny difference is just the precision of the solution of the nonlinear equations. Now that I found the VHDL code, I'll be able to look for algorithm differences. Right away, I see the interpolation functions differ somewhat.
This problem is I don't have the source code of a "known good" reference. I'm suspicious of the Verilog-A code, and I'd trust the VHDL more I think, just because it has somebody's name on it, and that guy is one of the EKV model developers.
Thanks. Any ideas are welcome! I'm about ready to try version number 3, translated from the VHDL.
I notice that VHDL type real is used in ekv26.vhd which is usually double precision floating point according to this reference:
http://www.csee.umbc.edu/help/VHDL/types.html
Other net references state that it is single.
This statment in ekv26.vhd requires double precision:
yk:=exp(v)+1.0e-64;
Something to keep in mind also with the VB types. Just saw your post above that you've got them declared as doubles, I figured that you would!
Pete B.
http://www.csee.umbc.edu/help/VHDL/types.html
Other net references state that it is single.
This statment in ekv26.vhd requires double precision:
yk:=exp(v)+1.0e-64;
Something to keep in mind also with the VB types. Just saw your post above that you've got them declared as doubles, I figured that you would!
Pete B.
Pete, your point about the debugger gave me an idea. The EKV manual spells out a sequential algorithm with no looping and a standard mathematical - not programming - notation. This would be the perfect thing for MathCad. I could format the equations such that MathCad would display them identically to the equations in the EKV manual. Then I could look at each intermediate result in MathCad and compare it with the values in the VBA debugger. This would rule out any possibility that I might have misplaced some parentheses or some stupid error like that in my VBA code.
So that will be the next step - then the VHDL translation.
So that will be the next step - then the VHDL translation.
PB2 said:
Wow, thanks man! Here is the spreadsheet and an LTSpice sim. Alt-F11 is the shortcut to the VBA editor.
This is my first foray into VBA. This EKV version is the one I transcribed directly from the manual. The one I translated from Verilog-A is much messier. They both give the same answer. I have assumed that the simulation temperature is the same as the temperature at which the device parameters were extracted.
andy_c said:
OK, got it Andy, the LTSpice sim works, forgot to mention that I have OpenOffice, not going to buy MS Office *again* until I absolutely need it, LOL! I can read the code and will at least do a quick check of the equations.
Oh, so you've coded it twice and get the same answer? That sure seems to support the idea that you've got it right, or that it is a VBA issue. Wouldn't we want the VBA temp to match the LTSpice temp?
Pete B.
PB2 said:
Great! Thanks a bunch.
The thing that concerns me is that the C code of LTSpice and Micro-Cap might have some "tweaks" or updates that aren't present in the Verilog-A that I have, or documented in the EKV reference manual. Some things changed between the EKV reference manual and the Verilog-A. For example, you'll see the dielectric constants of silicon and the oxide layer are slightly different between the two. Also, I just tried the interpolation function from the VHDL code, and that fixed the problem that caused me to add in the "On Error" VBA code to InterpFunc(). So it looks like the VHDL is more up to date than the Verilog-A code that I got from the Silvaco site.
The temperatures should be the same between VBA and LTSpice at 27 deg C. The temp in Kelvin is 300.15 deg in the VBA code. I never saw that ".15" in the conversion before, but I did verify it on a unit conversion site I visited. Looking at the LTSpice MOSFET model docs, Tnom (parameter measurement temp) defaults to 27 C. In the docs for .OPTIONS, temp (device simulation temp when not specified) is also 27 C. So I think this all matches up.
Again, I really appreciate your double-checking this for me. Checking other people's code is not fun.
Edit: Oops, looks like you posted right before I did.
Yes, revision level came to mind. I notice that the ekv manual is V262, so who knows about further updates. All it takes is a typo in the manual or a missed update as I'm sure you know.
I considered comparing to the VHDL, but started with the ekv manual since you numbered everything and made it so easy. Given that your two versions agree and you think the VHDL is newer, I should probably check against that instead. On equation 54 so I might as well finish, perfect so far, as I expected! Your code is so easy to read, it's really not a chore at all. I'll do it again with the VHDL if it's easy enough to read.
You've been very generous Andy so I'm happy to try and help out here.
I considered comparing to the VHDL, but started with the ekv manual since you numbered everything and made it so easy. Given that your two versions agree and you think the VHDL is newer, I should probably check against that instead. On equation 54 so I might as well finish, perfect so far, as I expected! Your code is so easy to read, it's really not a chore at all. I'll do it again with the VHDL if it's easy enough to read.
You've been very generous Andy so I'm happy to try and help out here.
OK here's something. Equation 58 in the manual is KPa, the code is KP. I've not dug into the theory to really understand this, I figure you'll know off the top of your head.
Similarly with GAMMAa in equation 60, and I probably missed VTOa.
There seems to be a KP, AKP, and KPa, in the manual.
KPa is given in terms of KP in equation 28. Oh, I see that they're only related to short distance matching, so I'd assume we're taking them to be equal with a perfect match? Or ....?
Also checked all the input data and model parameters, all looks fine. I did notice the differences in the dielectric constants as you mentioned.
I'd say it all looks fine. Best guess is a revision level difference. I'll try to get to the VHDL soon.
As far as precision goes, I'd expect that SPICE uses doubles internally, anyone have any details about this?
This is from one of Intusoft's newsletters concerning the Pentium divide bug, which is not the issue however they get different answers with different math modes:
"As a test we ran two simulations of Chua’s circuit on a Pentium and a 486; one using the coprocessor and one using coprocessor emulation. (ISSPICE4 contains a coprocessor emulation mode.) If the results from the two 486 runs were the same, but different on the Pentium, the bug might be the cause. Unfortunately, all four answers were different. Revealing that the math libraries used to compile ISSPICE4 had just as much effect on the initial conditions as the platform."
Still I understand that math libraries and precision should not cause such a large error. But if truncation to zero causes an entire term in an equation to drop out, very unlikely, then larger errors might be seen.
Much more likely a revision difference.
Pete B.
Similarly with GAMMAa in equation 60, and I probably missed VTOa.
There seems to be a KP, AKP, and KPa, in the manual.
KPa is given in terms of KP in equation 28. Oh, I see that they're only related to short distance matching, so I'd assume we're taking them to be equal with a perfect match? Or ....?
Also checked all the input data and model parameters, all looks fine. I did notice the differences in the dielectric constants as you mentioned.
I'd say it all looks fine. Best guess is a revision level difference. I'll try to get to the VHDL soon.
As far as precision goes, I'd expect that SPICE uses doubles internally, anyone have any details about this?
This is from one of Intusoft's newsletters concerning the Pentium divide bug, which is not the issue however they get different answers with different math modes:
"As a test we ran two simulations of Chua’s circuit on a Pentium and a 486; one using the coprocessor and one using coprocessor emulation. (ISSPICE4 contains a coprocessor emulation mode.) If the results from the two 486 runs were the same, but different on the Pentium, the bug might be the cause. Unfortunately, all four answers were different. Revealing that the math libraries used to compile ISSPICE4 had just as much effect on the initial conditions as the platform."
Still I understand that math libraries and precision should not cause such a large error. But if truncation to zero causes an entire term in an equation to drop out, very unlikely, then larger errors might be seen.
Much more likely a revision difference.
Pete B.
PB2 said:
Yes, you'll see that the "sub a" terms are equal to the terms without "sub a" when perfect matching is assumed. According to the docs, "These model equations are only applicable in Monte-Carlo and sensitivity simulations". So I didn't change the variable names to the "sub a" ones. I just kept the original names.
The VHDL looks messy, so I've given it a rest until tomorrow, when I'll do a third try. Third time is a charm?
Edit: All the C math functions take double arguments and return double, so pretty much all numerical C code is written using double.
Another weird thing I noticed was in the VBA docs, when they talked about min and max double values. It's clear that the doubles in VBA are not IEEE-754 compliant. Compliant implementations all have the same min and max representable values for a 64-bit implementation. But I think the tolerance on f(x)=0 in nonlinear equation solving would swamp out precision issues with double between C and VBA.
andy_c said:
Yes, you'll see that the "sub a" terms are equal to the terms without "sub a" when perfect matching is assumed. According to the docs, "These model equations are only applicable in Monte-Carlo and sensitivity simulations". So I didn't change the variable names to the "sub a" ones. I just kept the original names.
The VHDL looks messy, so I've given it a rest until tomorrow, when I'll do a third try. Third time is a charm?
Edit: All the C math functions take double arguments and return double, so pretty much all numerical C code is written using double.
Another weird thing I noticed was in the VBA docs, when they talked about min and max double values. It's clear that the doubles in VBA are not IEEE-754 compliant. Compliant implementations all have the same min and max representable values for a 64-bit implementation. But I think the tolerance on f(x)=0 in nonlinear equation solving would swamp out precision issues with double between C and VBA.
I'll also probably look at the VHDL tomorrow.
Much of my digital design and microcode work involved floating point math hardware for both IEEE-754 and IBM-370 formats. I believe that there were often some mode settings in hardware implementations to optimize for speed. This link claims that denorms can be disabled in Pentium 4 making it much faster but not exactly IEEE-754 compliant. Probably fine for graphics transformations, not for numerical calculations:
http://www.cygnus-software.com/papers/x86andinfinity.html
I agree that if double precision is used throughout that these considerations should be insignificant.
That's funny about VBA, maybe they use BCD arithmetic, LOL! I think the 8087 would actually do BCD math on variable length strings, LOL!
PB2 said:
Sounds like you've done some heavy duty stuff.
My only brush with IEEE-754 was when porting a large application from Borland C++ to MS Visual C++. At the time, Visual C++ was at version 6, and sacrificed IEEE-754 compliance for speed, while the Borland compiler was compliant, but produced slower code. There were some strange floating-point bugs I had to fix in the port. These were mostly in loops that erroneously used floating-point conditions to control loop execution. These loops would execute a different number of times in the code of the two compilers. But of course, this only happened in obscure cases
.