Intusoft logo


Intusoft Newsletter Issue #40, January 1995
Copyright ©2002 Intusoft, All Rights Reserved

In This Issue  
1 AHDL Modeling Kit Released 4 New ICAP/4 Update
2 Simulating a State Machine 5 New Low Price DOS
Free SPICE on the Internet
3 Pentium Bug and SPICE 6 The Modeling Corner: NTSC Signal Source

New AHDL Released

Intusoft will introduce a Code Model Software Development Kit, or CM-SDK, on February 20, 1995. The CM-SDK allows you
to develop Analog Hardware Description Language (AHDL) models consisting of C code. This“C code modeling” architecture is based on the XSPICE program originally developed by the Georgia Tech Research Corporation, a unit of the Georgia Institute of Technology in Atlanta GA. The Intusoft AHDL differs from current HDL offerings which are proprietary in nature and only work with UNIX based simulators. The C code modeling capability completes the AHDL picture for ISSPICE4 giving it all the features and portability of even the most powerful modeling languages.

What Can Code Modeling Do For Me?

In order to simulate a range of complexities and applications efficiently Intusoft provides several modeling techniques; the most powerful of which is a new AHDL. An AHDL allows you to easily develop just about any model or interface other functions to SPICE. The models may be as simple as a transfer function or as complex as new MOSFET. They can perform virtually any function, analog, or digital, and be blended with any other SPICE model or behavioral modeling syntax. Code modeling opens up many areas of simulation to SPICE users that were formally closed because of the complexities of modeling. It extends ISSPICE4’s capabilities to allow efficient simulation of mixed-signal, board, and systems-level circuits using a top-down design methodology. It also provides a practical alternative to macro-modeling and the widely scattered AHDL languages. With the CM-SDK all types of systems and processes can be modeled and simulated whether they include electronic devices or not. It is now possible to interface ISSPICE4 with hardware, or other programs, or mix electrical-nonelectrical processes. Don’t be surprised if future Intusoft Newsletters cover ISSPICE4 as it performs some of the applications listed on the next page. The possibilities are truly endless!

Intusoft Makes AHDL Model Development Easy!

The Intusoft CM-SDK is a major breakthrough in AHDL technology. It provides an easy way for you to add tremendous functionality to SPICE without having to deal with SPICE’s intricacies. The CM-SDK assists you in writing, compiling, and using C code subroutines with ISSPICE4. The kit works with additions to the simulator core to tell the simulator how to parse the netlist and model syntax and how to call C code that defines the model’s behavior (Figure 2).

A new code model is created from two user generated files. First, the CM-SDK uses a C language code generator to convert an easy to read text file into the data structures required by ISSPICE4. This ‘interface file’ is a table you prepare that describes the model’s ports and parameters. The code model behavior is described in another file using standard C syntax. The AHDL model coding is greatly simplified by supplied macros and functions that handle the details of interfacing a model to SPICE. The complexities of SPICE are hidden; the CM-SDK does most of the work for you. The result of a successful build is a code model library (DLL) that can be
accessed by ISSPICE4. There is no need to recompile the ISSPICE4 executable each time a new model is added. The result is an incredibly simple development path that reduces the effort in making SPICE models from months to days and eliminates the need
for you to learn about the internal workings of SPICE. Although code models must be developed under NT or Windows95, the resulting DLL can be used with ISSPICE4 running under Windows 3.1x on any compatible platform (x86, Mips, or Alpha).

The benefits of developing models using C codehave not been widely recognized. This is mainly due to the limited programming and simulator support and extensive knowledge of SPICE that was previously required. The Code Model toolkit alleviates these difficulties. More technical details on the AHDL features and how the modeling kit works are available via the attached bingo card. Table 1 describes some of the major benefits of using the Intusoft CM-SDK.

 Table 1 - Major benefits of Using the Intusoft CM-SDK

Code Modeling Benefits To Users/Developers

  • Create analog, digital, and mixed mode models using the C language.
  • Add models to SPICE in Days instead of Months
  • Develop specialized models easily: Radiation, RF, Neural Networks, Array Processing, Image Processing, System transfer functions, etc.
  • Provide higher level models for system-level top-down design
  • Interface other programs, simulators, and hardware, to SPICE
  • Extend SPICE’s macromodeling capabilities to nonelectrical applications
  • Users can share compiled code models (DLL’s) since any ISSPICE4 program can access them (The CM-SDK is only needed for development not usage.)
  • The CM-SDK shields the model developer from virtually all internal SPICE-related concerns through specially developed macros and functions.
  • The code model interface is non-proprietary and can be added to any SPICE program or other proprietary simulators.
  • Primitives are added to SPICE via a Windows DLL; Users can add to the existing DLL or create separate DLLs •No need to recompile the SPICE executable each time a new model is added.
  • When paired with ISSPICE4, the CM-SDK can be used as a test bed for model development on other platforms and simulators.

Code Modeling Benefits To Hardware Vendors

  • Language based on publicly available, non-proprietary XSPICE standard
  • Model’s C source code is portable to ANY simulator that is compatible with XSPICE, even across platforms.
  • Source code OR compiled DLL object can be distributed to users. Use of the DLL hides the model implementation. DLL can be copy protected.
  • Code models can be combined with existing SPICE-based models

What’s Included in the CM-SDK

The CM-SDK consists of a compiler and other tools, code model examples and source code, include files, and documentation on how to create AHDL models. The toolkit is supported under Microsoft Visual C++ 1.1 or 2.0 under Windows NT or Windows95.

Introductory Pricing

For a limited time, until April 15, 1995, the price of the CM-SDK is $2500. After 4/15/95 the list price will be $3500. The CM-SDK
is also bundled with the ICAP/4Windows system for $5000 until 4/15/95, $5500 thereafter.

Special Subscription Offer

Intusoft is offering a subscription service for the CM-SDK. Over the course of the year you will get at least two development system updates sent to you automatically, as well as access to special on-line services. Included are compiler fixes, AHDL and SDK feature enhancements, more code model samples, and technical articles. The cost is just $750.00. This is the fastest and most timely way to get the latest tools and information.

Prices listed are in US$ and valid only in the U.S. Contact your local dealer for more info.


Anatomy of a Code Model

In order to demonstrate the utility of AHDL models and point out some SPICE convergence issues, we will do an in depth study of one of the new code models supplied with the ISSPICE4 release; the Laplace expressions model. First; a bit of Laplace transform theory. We will mainly quote results rather than develop proofs which can be found in many elementary circuit theory texts [1].

There are several methods by which a Laplace transform can be implemented using SPICE. First, we can build what amounts to an equivalent circuit, using state space techniques, as shown in Figure 3. Interestingly enough, this technique could be implemented as a subcircuit using SPICE 2. However, this implementation restricts the model to a fixed number of states. The ISSPICE4 Laplace expressions model uses the state space method and accommodates a variable number of states. Another method is to transform the Laplace expression from frequency to time and use convolution to produce the output, that is:

out(t) = in(t) ƒ H(t), where ƒ is the convolution operator.

In the convolution method, the impulse response is truncated so the computer algorithm can deal with a finite sized array. The usual approach is to use the Fourier transform as an approximation to the Laplace transform. This assumption, when transformed back to a Laplace representation produces a transfer function which is aliased into the frequency domain as shown in Figure 4. As long as there is no significant energy applied to the input at frequencies above the folding frequency, this approximation holds and results are accurate. Another requirement is to limit the time step of the simulator to match the values in the H(t) array. This causes a substantial performance penalty, making the convolution method a poor choice for all but a few problems. This is the method used by other simulators like Pspice™ to solve Laplace expressions.

The advantages of the state-space method are to eliminate the aliased artifacts and to establish a larger time step than could be used with the convolution approach. The convolution ap- proach has the advantage of handling non-linear functions; for example, it is used to model transmission lines in ISSPICE4. However, the time step penalty using convolution is so severe, that it is not a wise choice unless nonlinear functions are needed.

By way of example, consider a lead lag network (below) of the form:

H(s) = Gain * (s + wlead) / (s + wlag), where wlead = 10Meg & wlag = 100Meg.

Since there is output at high frequencies, the transform time step must be limited based on the input signal content; that is, the input must have a finite rise time. In SPICE, input rise times are limited to the value of the TSTEP parameter that controls the transient simulation. Simulators typically use this to arrive at the convolution step requirement. For our example, a 1ns step would be typical. The convolution integral, vout = integral( vin(t) ƒ h(t-tau) dt ) must be solved for each time step. This amounts to setting up a storage array of time, value pairs which are the impulse response of the network. If the timestep is constant, only values are needed; however, consid- erable space can be saved by separating the values based on content rather than time. This saving also applies to the solution which would have fewer multiply-accumulate operations. Even so, we can expect hundreds of operations per iteration, com- pared with three or four operations in a state space model.

On the other hand, the time step used in a state space formulation must be small enough to provide numerical stability. The ISSPICE4 algorithms do an excellent job of automatically adjusting the time step as seen in Figure 5. Using the convolution method, Pspice v6.1 took 10.88s (4890 iterations), while ISSPICE4 took 3.9s (1636 iterations) on a Pentium/60 (Figure 6). The forced time step limiting causes Pspice to be slower than ISSPICE4 by over 275%. You can actually improve on ISSPICE4’s internal algorithms by setting the TMAX parameter to about one half the fastest time constant to prevent the continued scaling back that occurs in ISSPICE4 automatically when the timestep become too large. By overriding the automatic TMAX selection, you can reduce the total number of iterations, and therefore, simulation time, by as much as 50%. For the lead lag example, this means dropping from 1636 to 987 iterations.

[1] “Linear Systems Theory”, L. Zadeh & C. Desoer, McGraw-Hill, 1963
[2] “Code-level Modeling in XSPICE”, Fred. L. Cox III, William B. Kuhn, Jeffery Murray, and Stephen Tynor, Proceedings of the 1992 Intl. Symp. on C&S, San Diego, CA, 5/92, IEEE 0-7803-0593-0/92


Simulating A State Machine

ISSPICE4 allows you to describe a system with various levels of abstraction. System designers can work at high levels of abstraction with hierarchical blocks, employing behavioral models to explore architecture, analyze trade-offs and verify system specifications. Later in the design cycle, engineers can use the simulator to test their detailed designs substituting detailed circuitry for each section. For those having to cover both ends of the spectrum, ISSPICE4 allows you to blend behavioral analog and system-level descriptions with SPICE
transistor level models and digital logic within the same simulation environment.

To simulate a mix of problems efficiently a variety of modeling techniques are provided. One of the newest is the Intusoft AHDL. With it, analog, digital, or hybrid (mixed analog/event-driven) models can be developed. The over 25 digital primitives in ISSPICE4 were developed in this way. They carry timing information and use a built-in logic simulator. The logic simulator is event driven in order to exploit the latency found in mixed mode circuits. Users may add their own logic functions or use the over 25 building blocks. One of the most powerful new digital models included in ISSPICE4 is a State Machine.

Describing A State Machine

The state machine provides for straight forward descriptions of logic blocks with a variable number of inputs and outputs and an unlimited number of states. The model can be configured to behave as virtually any type of counter or clocked combinational logic. It can replace very large sections of digital circuits with a functionally identical but faster representation and alleviate the tedious schematic entry of a complex design.

AHDL models are more flexible than traditional SPICE models. They can have an arbitrary number of inputs. For instance, the state machine can have any number of input and output signals. They are delineated by braces around the node numbers in the netlist
(Figure 7). Each set of braces indicates one model port. As shown in the Laplace model used previously, each model parameter may also be a vector of several values. Other inputs to the state machine include a clock and a single reset line. The clk_delay parameter specifies the time after the positive clk signal edge that the outputs will transition. The reset_delay parameter specifies the time after the positive reset signal edge that the outputs will transition to the state number defined by the reset_state parameter.

The state machine is configured through the use of a separate ASCII text file defined by the model parameter State_File. The file defines all the output states plus the input data combinations which trigger state changes. An example state file for a binary counter is shown in Figure 7 along with a sample .Model statement. You can see from the file that the output is a binary counter that changes state on either a high or low input. The value of the single input bit determines whether the counter counts up (in = 1) or down (in = 0).

The state machine is quite useful since the state diagram, or state table is normally available before the circuit is con- structed. The output for the counter is given in Figure 8. ISSPICE4 is the only Windows version of SPICE to have this capability.


Pentium Bugs & Chaos

At first we were quite concerned about the possibility of problems with the Pentium division bug. While not the most prevalent operation division is used quite often in SPICE (adds and multiplies dominate). To investigate the issue we ran several circuits that might be susceptible to the problem on both 486 and Pentium machines. These circuits included a switched current integrator, an analog correlator, and a high-Q VCXO. Since the possible error could approach hundreds of parts per million, we expected that high Q oscillators would exhibit some errors. In all cases the answers on both platforms were identical out to 7 decimal places.

Since we knew the flaw existed, we thought about what other system could reveal it. A circuit that exhibited chaotic effects
came to mind. Fortunately, a simple circuit exists that has been rigorously proven to be chaotic. Chua’s circuit shown in
Figure 9 is very sensitive to initial conditions and exhibits a rich variety of bifurcations and chaos. [1]

Circuit Simulates Chaos

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.

At each time point ISSPICE4 uses an iterative Newton-Raphson procedure to find the solution. The answer is accepted or rejected based on a predetermined amount of error (local truncation error). If the bug were to occur and an erroneous solution generated, ISSPICE would simply reject the answer, back up in time and retry the calculation with another set of values. The same process that occurs under normal circum- stances. The chances of repetitively encountering sets of values that reveal the bug, thus causing a convergence prob- lem, are remote at best. In summary, it appears that the Pentium bug does not appreciably affect SPICE. Footnote: if you can find a buggy Pentium at a discount buy it!

[1] Michael P. Kennedy, “Three Steps to Chaos - Part II: A Chua’s Circuit Primer”, IEEE Trans. on C&S, 10/93, Vol. 40, #10. pp. 657-674


New ICAP/4 Has Native Mixed Mode

Intusoft has released a new version of ICAP/4Windows, (version 7.5) with several major enhancements:

Some of the new models include those for: AMP and Burndy connectors, digital IBIS buffers, National 4046 PLL IC, dual opto-isolators from CP Clare, Motorola ECL, PIN photodiodes, PolyFET RF power Mosfets, Siliconix DMOS FETs and more.

The main addition to the ISSPICE4 program is an integrated event driven simulator. By combining logic simulation along with the analog algorithms, ISSPICE4 can efficiently simulate mixed signal circuits. The event driven techniques exploit the latency associated with digital functions. All the new digital models allow accurate specification of propagation and rise/fall time delays.

A set of over 40 new analog, hybrid (mixed analog/digital), and digital AHDL primitive models has been added to ISSPICE4. AHDL or “C code models” are an extension of the standard devices offered in ISSPICE4 and provide you with an enriched set of devices with which to build subcircuit models. Now you can blend behavioral analog and system-level AHDL descriptions with SPICE transistor level descriptions and digital models all within the same simulation environment.

Current ICAP/4Windows owners may update to the new ver- sion for $295. For those that have bought ICAP/4Windows since October, the upgrade is free (But you must send in your free update card!!). For new customers, the price of ICAP/ 4Windows has not be increased. Many other vendors talk about giving the customer value; Intusoft delivers.


New Lower Price for DOS ICAPS

ICAP/4DOS is now available for the price of $1250 (reduced from $1750). It includes an integrated schematic entry program, ISSPICE3, over 3000 SPICE models, and the INTUSCOPE waveform processor. ISSPICE3 is 32-bit extended memory version of SPICE 3F.2 and is the most advanced DOS based SPICE simulator available. Upgrades to the ICAP/4Windows version (file
compatible, of course) are available for the price difference. Demonstration disks are available.

Fully Functional SPICE: FREE

Intusoft has posted its ICAP/4Windows Evaluation version on both CompuServe and Internet. The software, including sche-
matic entry, ISSPICE4 simulator, a small model library, and the INTUSCOPE waveform viewer, can be downloaded for FREE.
This version is limited to circuits with 15 top-level components. (Special provisions are made for subcircuits.) Through Internet
you can download the software from:

The software (in 3 disks) is located in software_continuous_simulation/icap-4. CompuServe has provided Intusoft with its own Library section (library #21) under the CAD/CAM/CAE forum. The ICAP/4 Windows evaluation version is also stored there.

Newsletter Posted in Electronic Format

Intusoft has posted previous versions of the Intusoft Newsletter on CompuServe in an electronic format. The “electronic” docu-
ment is an exact copy of the published version and can be viewed on a Macintosh or Windows using the Replica™ Viewer
program from Farallon. The Replica Viewer is free and can be downloaded, along with the newsletters, from library 21. The
Replica Viewer also allows you to search a document or copy text (such as models) from the file. Check It Out!!

Prices listed are in US$ and valid only in the U.S. Contact your local dealer for more info.


The Intusoft Modeling Corner

In this issue of The Intusoft Modeling Corner we bring you a report on one of our most complex stimulus sources developed
to date; an NTSC (National Television System Committee) signal generator. The Intusoft Newsletter floppy contains new IC
models from SGS Thomson and Texas Instruments, as well as the SPICE 3 subcircuit netlist for NTSC generator.

The standard for television transmission in the US is defined by the FCC and known as the NTSC signal. This signal contains visual and aural data for transmitting the television image and sound. The NTSC subcircuit contains only the timing information found in the NTSC signal (Figure 10). The aural and visual information is not included. The components of the NTSC signal are multiples of the chrominance subcarrier frequency (Color burst). For this reason the NTSC subcircuit accepts the chrominance subcarrier frequency as a parameter and processes the components based on the frequency passed into the subcircuit. By default the frequency is set to 3.579545MegHz. Since the allowed tolerance is 10Hz it is unlikely that this default will need to be changed. Two additional parameters are provided; RFL representing the reference white level and BLANK representing the blanking level. Their defaults are 0 and 0.75volts, respectively.


Copyright ©2002 Intusoft, All Rights Reserved