1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88
|
ACS 0.21 bug list (03/28/96)
1. "exp" function is weird.
2. Error handling in batch mode leave something to be desired. It
usually reverts to interactive mode.
3. It is not clear how to map an initial unknown (logic) to analog
when there is no analog model. What actually happens is that it
is not mapped and could go either way. I guess that is what is
meant by "unknown".
4. The name of a logic family must be no more than 4 letters. The
reason is that names of the analog models of its members are made
by concatenating the family name, the gate type, and a number.
The gate type and number adds 4 characters, leaving 4 for the family
name. There is no trap for this. It just won't find it.
5. Meyer's model for MOSFET capacitance can have some strange
effects on step size as it crosses region boundaries. I believe
Spice has the same bug. It behaves different from Spice at Vds
== 0. ACS does not have the discontinuity, but distributes the
capacitance different from Spice when reversed.
6. Non-unix versions may have strange ideas about where to put
temporary files. The MSDOS version puts them in \tmp on the current
drive, so you must create it if it doesn't already exist. I believe
this approach is better than the usual MSDOS approach of putting
the trash files in the current directory or in some other surprise
place. The VMS version puts them in the current directory, although
I think this is a poor choice. Future versions will use an
environment variable (probably TMP) to determine this.
-------------------------------------------
Other notes:
It is still possible to get small differences in the answers between
ACS and Spice. This does not show in a single stage but may show
in a high gain circuit such as an open loop op-amp. It varies
exactly why but could be one or more of: different (better) diode
model, different gmin handling, different interpretation of
tolerances, different order of calculations results in different
roundoff error, different bypass criteria. This will probably
always be this way.
Don't forget to do an "op" before "ac" to set the operating point.
Unlike Spice, ACS does NOT do it automatically. It's not a bug.
It's a feature. This enables you to easily do an AC analysis at
any point on the transfer curve. Run a transient analysis to the
point where you want the AC performance then do the AC analysis.
This way you can see changes in the frequency response with variations
in the signal. If your circuit is unstable at a particular spot
on the waveform, ACS is the only simulator that I know of that lets
you do an AC analysis there. (other than ECA-2, a predecessor to
ACS) A future release will use command options to handle this more
gracefully, but for now don't forget the op.
ACS has a simple behavioral modeling language that allows you to
specify special characteristics of most simple components
(R,G,C,L,V,I,G,E,F,H). Among its features, the SPICE source functions
(PWL, SFFM, etc.) can be applied to any simple component. It is
possible to make components time dependent, to use a different
value for different analyses, to give them complex values, and to
make them nonlinear. This is not documented.
-------------------------------------------------
Future work planned:
Hot items:
BSIM model
BJT model
There are a few changes planned eventually as part of ongoing research efforts:
Real (fast) logic simulation.
Full implementation of selective trace.
Pole-zero analysis.
May happen subject to funding:
Interconnect analysis. (not just transmission lines)
Better transmission line model.
Since the program was developed as a research tool, there are
several other loose ends (low priority):
Better matrix ordering. (Markowitz makes it worse.)
Roundoff error in incremental update.
Bypass of analog code in logic simulation.
Documentation of behavioral modeling and logic simulation.
Documentation in general.
-------------------------------------------------
I appreciate your input. In particular I need good test cases and
help in prioritizing changes. You can send comments by email to
al@atd.rochester.ny.us.
|