From: Jinhua Chen (firstname.lastname@example.org)
Date: Tue Sep 26 2000 - 11:12:27 PDT
Unfortunately, the model I got was encrypted. I know this model will not work
with others. Because it sets the '.OPTION SCALE=0.7'. The model I worked
before either used '.OPTION SCALE=1e-6' or '.OPTION SCALE=1'.
The PARHIER option is a good feature to fix the general global '.param'
But not the '.OPTION' one. I agree with you.
At 01:30 PM 9/26/00 -0400, Ingraham, Andrew wrote:
>The bottom line is that there is no good way to fix this, except by
>insisting that all model vendors do not use the SCALE and SCALM parameters.
>In my opinion, SCALE/SCALM are evil and will only cause endless headaches.
>They are fine as long as you are creating models STRICTLY FOR YOUR OWN
>CONSUMPTION which will never be used by anyone else; but anytime a model is
>created by a vendor to be used by his/her customers, or by co-workers, there
>must not be a SCALE or SCALM parameter in it! (i.e., both must be left at
>the SPICE default of 1.0.)
>You've hit one of my HSPICE hot buttons. Grrr.
>HSPICE does have the PARHIER option which affects whether parameters are
>local or global; and HSPICE support once tried to tell me that it would fix
>the problem. However, it does not affect the SCALE/SCALM options which are
>The same can also be said about any .GLOBAL nodes, even GND nodes,
>especially (but not only) when they are hidden within encrypted models.
>They should never exist on models intended for use by other than the model's
>creator. Let me choose how to connect ground, and let me insert package
>parasitics without having to reverse-engineer the SPICE model (which I have
>had to do many times).
>If your model vendor can't or won't fix the model, you could embarrass the
>heck out of them until they change their ways.
>If you have unencrypted models, you might be able to apply suitable scaling
>factors to all device dimensional parameters and fix it yourself. Not
>recommended for any but the simplest of models.
>Many SPICE model vendors live in a vacuum, and seem to think we work in one.
>I never use a vendor's model all by itself. Just about the only reason I
>need SPICE models is so that I can simulate the interconnect between chips,
>and there is rarely any interconnect that goes from a chip to itself without
>touching some other semiconductor device. Connecting together models from
>different vendors is the norm, NOT the exception. Get with it, guys!
>**** To unsubscribe from si-list or si-list-digest: send e-mail to
>email@example.com. In the BODY of message put: UNSUBSCRIBE
>si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
>si-list archives are accessible at http://www.qsl.net/wb6tpu
| NORTH EAST SYSTEMS ASSOCIATES, INC. |
| ------------------------------------- |
| "High Performance Engineering & Design" |
| Jinhua Chen, Ph.D e-mail: firstname.lastname@example.org |
| Sr. SI Engineer http://www.nesa.com/ |
| NESA, Inc. Tel +1.978.897-8787 |
| 636 Great Road Fax +1.978.897-5359 |
| Stow, MA 01775 USA |
**** To unsubscribe from si-list or si-list-digest: send e-mail to
email@example.com. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
This archive was generated by hypermail 2b29 : Tue May 08 2001 - 14:29:35 PDT