estuart said:
The 80 bit format is extended Double and is a higher precision Double format usually used for internal, intermediate calculations between registers (or stack), which likely originated in the 8087. Guard and sticky bits are often required to meet the IEEE-754 floating point requirement for a properly rounded result.
The 8087 was basically a microcoded 80 bit ALU as I recall.
You can see here that IEEE-754 does not exactly specify the extended Single and Double formats, pages 192-193:
http://www.validlab.com/goldberg/paper.pdf
Also see the bottom of page 250 where differences between extended precision and standard systems are discussed.
This paper also reminds me of transcendental functions see page 196.
I'd say that if the code runs on an X86/X87 architecture, then extended doubles are used since this is the internal floating point unit format.
This is interesting to discuss but I don't think it explains the fairly large difference that Andy is seeing.
Pete B.
andy_c 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.
I got pushed onto a specialized Super Computer project as my first job out of school. The job was sold as RF design work, LOL! One of the system's strengths was floating point performance. It was huge, built mainly from SSI and MSI parts, the FPU was 4 large boards and there were 4 parallel FPUs. I pushed them to use a new VLSI chip set that reduced the 4 boards down to 4 chips that fit on less than 1/4 the area of one board. Anyway ...
Loop control with floating point, I could see how that would be interesting!
PB2 said:
The 8087 is actually an excellent design, better conceptually than many floating point formats out there. This is an interesting article about it and the connection to the IEEE spec:
http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html
PB2 said:
Hi Pete,
I'm porting the VHDL to VBA as we speak
. I had first thought I'd be able to just mindlessly convert line by line, but it looks like VHDL is not strictly sequential execution. For example, logratio is referenced before its value is assigned. So I need to change the statement order. This is the first time I've encountered VHDL or Verilog, so you can see I'm a bit confused. Also, there are statements like:COX == epsox / TOX ;
But this is only supposed to happen if COX is not provided by the user (equation 10). So the VHDL compiler "knows" this and generates code to assign COX only if the user hasn't provided this parameter?
andy_c said:
Hi Pete,
I'm porting the VHDL to VBA as we speak
COX == epsox / TOX ;
But this is only supposed to happen if COX is not provided by the user (equation 10). So the VHDL compiler "knows" this and generates code to assign COX only if the user hasn't provided this parameter?
Ah, I forgot to mention concurrency, but at a glance the program looks like one big module with a few functions assigned. Also this is VHDL-AMS which is slightly different from normal VHDL. Have you found a language reference manual (LRM) for VHDL-AMS? I had to buy the one I have for VHDL because it's a copyrighted IEEE publication.
There is the type signal that is intended to represent a wire, and values assigned to signals with the <= assignment statements are concurrent with a one tick simulator delay as default IIRC, as they should be. In normal VHDL the := assignment statements are used for sequential variable assignments. Don't recall ever seeing a == assignment operator and I think it's new to VHDL-AMS. I pulled out IEEE Std 1076-1987, and I see nothing about quantitiy, or == assignment statements. Also, real is defined as the range for Single precision but stated as or better.
Looking at this further it seems that the quantity declaration is probably for analog signals, and == is probably the analog signal assignment operator. So they would be concurrent as you noticed. Not sure how analog wire delays are handled since I've not used VHDL-AMS. However, looking at that particular case that you found, it just doesn't look right. It looks like a bug. The LRM would clear this up.
There is also concurrency across processes but this looks like one large process with a few functions defined, so it's not an issue.
Here's a VHDL introduction, in case people are interested:
http://www.csee.umbc.edu/~plusquel/vlsi/slides/vhdl.html
and a VHDL tutorial:
http://www.seas.upenn.edu/~ese201/vhdl/vhdl_primer.html#_Toc526061361
Here's some VHDL-AMS validation code, that also offers some decent code examples:
http://www.syssim.ecs.soton.ac.uk/vhdl-ams/examples/mos.htm
And this:
http://www.ececs.uc.edu/~dpl/distribution/reports/vishwa_thesis/
Thanks Pete!
I've been kind of muddling my way through this. It's not too bad. I just go through the algorithm of the EKV manual and find the corresponding VHDL code. Knowing the variable whose value I need, I just work backward through the dependencies until everything I need has been declared and assigned just in time for when I need it. I like the way VBA allows declaring a variable right at the point of use. It's like C++ in that regard. It helps avoid uninitialized variables.
The VHDL code is messy. There's a variable for almost every temporary result of the calculation. But I just let the VBA compiler do the work of finding the undeclared variables, then go fishing in the VHDL.
I got all the way down to the end, then saw I had only one variable left to evaluate before getting the final drain current. When I went to get its value, I realized there was a huge dependency path to evaluate it. LOL! So I'll finish up tomorrow. That final calculation is nothing like what the previous incarnations of the code did. So I am hoping this fixes it.
Thanks again for all your help.
I've been kind of muddling my way through this. It's not too bad. I just go through the algorithm of the EKV manual and find the corresponding VHDL code. Knowing the variable whose value I need, I just work backward through the dependencies until everything I need has been declared and assigned just in time for when I need it. I like the way VBA allows declaring a variable right at the point of use. It's like C++ in that regard. It helps avoid uninitialized variables.
The VHDL code is messy. There's a variable for almost every temporary result of the calculation. But I just let the VBA compiler do the work of finding the undeclared variables, then go fishing in the VHDL.
I got all the way down to the end, then saw I had only one variable left to evaluate before getting the final drain current. When I went to get its value, I realized there was a huge dependency path to evaluate it. LOL! So I'll finish up tomorrow. That final calculation is nothing like what the previous incarnations of the code did. So I am hoping this fixes it.
Thanks again for all your help.
MOSFET Noise models
Do any of you guys have an opinion on the accuracy of the noise behavior for the MOSFET SPICE models in LTSPICE?
BTW, I've always been under the impression that MOSFETs are a lot noisier than JFETs in general, but I've never really looked at the noise characteristics of MOSFETs. Any thoughts?
Thanks,
Bob
Do any of you guys have an opinion on the accuracy of the noise behavior for the MOSFET SPICE models in LTSPICE?
BTW, I've always been under the impression that MOSFETs are a lot noisier than JFETs in general, but I've never really looked at the noise characteristics of MOSFETs. Any thoughts?
Thanks,
Bob
Well, I've got the latest VBA code for the EKV model transcribed from the EKV web site's VHDL-AMS code working now.
I'm happy to report that the VBA model now matches the data of the SPICE simulators. With the VBA code, I get a drain current for the test circuit of 10.832 uA. It's now a bit higher than the SPICE sim, but this makes sense because the simulators are modeling the extrinsic source and drain resistors, which will reduce the current somewhat. The VBA code can't do this because it would require iterative solution of Id given Vgs.
So pretty soon I'll be ready to try using the Excel solver to tweak model parameters to fit measured device data.
I'm happy to report that the VBA model now matches the data of the SPICE simulators. With the VBA code, I get a drain current for the test circuit of 10.832 uA. It's now a bit higher than the SPICE sim, but this makes sense because the simulators are modeling the extrinsic source and drain resistors, which will reduce the current somewhat. The VBA code can't do this because it would require iterative solution of Id given Vgs.
So pretty soon I'll be ready to try using the Excel solver to tweak model parameters to fit measured device data.
Re: Spice models for 2SK389 & 2SJ109
Hi Bob,
These are from PSPICE, and I have not tested them.
.model J2sk389 NJF(Beta=51.76m Rs=8.008 Rd=8.008 Betatce=-.5 Lambda=11.22m
+ Vto=-.5275 Vtotc=-2.5m Cgd=18.28p M=.3367 Pb=.3905 Fc=.5
+ Cgs=20.07p Isr=112.8p Nr=2 Is=11.28p N=1 Xti=3 Alpha=10u Vk=100
+ Kf=92.85E-18 Af=1)
.model J2sj109 PJF(Beta=39.21m Rs=0 Rd=0 Betatce=-.5 Lambda=4.338m Vto=-.5762
+ Vtotc=-2.5m Cgd=67.64p M=.2562 Pb=.3905 Fc=.5 Cgs=61.12p
+ Isr=158.7p Nr=2 Is=15.87p N=1 Xti=3 Alpha=10u Vk=100
+ Kf=109.9E-18 Af=1)
Bob Cordell said:
Hi Bob,
These are from PSPICE, and I have not tested them.
.model J2sk389 NJF(Beta=51.76m Rs=8.008 Rd=8.008 Betatce=-.5 Lambda=11.22m
+ Vto=-.5275 Vtotc=-2.5m Cgd=18.28p M=.3367 Pb=.3905 Fc=.5
+ Cgs=20.07p Isr=112.8p Nr=2 Is=11.28p N=1 Xti=3 Alpha=10u Vk=100
+ Kf=92.85E-18 Af=1)
.model J2sj109 PJF(Beta=39.21m Rs=0 Rd=0 Betatce=-.5 Lambda=4.338m Vto=-.5762
+ Vtotc=-2.5m Cgd=67.64p M=.2562 Pb=.3905 Fc=.5 Cgs=61.12p
+ Isr=158.7p Nr=2 Is=15.87p N=1 Xti=3 Alpha=10u Vk=100
+ Kf=109.9E-18 Af=1)
