How OLE 2 Enhances Interoperability in EDA Tools by Matthew Archambault and Charles Hymowitz Above all, Object Linking and Embedding, or OLE, is a standard. Like any standard, it is not perfect, but it is one that is supported throughout the software industry, in operating systems (Windows), in development tools (Microsoft Visual C++, Borland), and in applications. OLE provides a common framework through which programs from one or more vendors can communicate, and a common foundation in which programmers can work. No special training or knowledge of proprietary interfaces is required to implement effective integration. An OLE interface essentially allows two programs to share functionality without having to know about one another. Any programming language/compiler/platform combination that supports OLE can be used. The limiting factor is porting the application, not the interface. OLE is supported by Microsoft and is an integral part of all of Microsoft's application programs, such as Word and Excel. OLE is even supported in Microsoft cross-platform development tools that allow porting of Windows applications to the Macintosh and RISC environments. OLE Automation is a technology that allows one OLE application, an OLE Automation Controller, to take advantage of services provided by another OLE application, an OLE Automation Server. The service provided will depend on the server, but is always provided though a standard object interface. The interface is used to expose any capability through a cross-application, object-based interface. Because of the nature of the software development process and the expertise required to develop even a single EDA tool, the best tools are not available from a single vendor. Hence, "tight integration" has been the mantra for customers forced to use EDA tools they purchase from different vendors. This request has prompted many vendors to produce shell programs that integrate EDA tools using vendor specific, but publicly available, communication protocols. From the customer's standpoint, this meets most of the requirements. From a vendor's point of view, however, the myriad of protocols can become a development and support nightmare for integrating tools from multiple vendors. In order to alleviate this dilemma, more and more vendors are choosing OLE as their interface standard of choice. Here we will discuss a little bit about OLE and give two examples of how OLE is improving EDA tool interoperability.

OLE2 Automation In its simplest form, OLE2 Automation is a mechanism that allows one application to use the computing resources of another. At one end we have an application that exposes key computing features, OLE Automation objects, for use by other applications. This type of application is referred to as an OLE Automation Server. At the other end, we have an application that uses the object(s) exposed by the OLE Automation Server. This type of application is called an OLE Automation Controller. At the heart of OLE Automation is the OLE Automation Object. A simple example of this scenario, discussed later, is when a SPICE circuit simulator acts as an OLE Automation Server and a schematic entry program acts as an OLE Automation Controller. SPICE exposes its ability to accept a netlist and run a simulation as an OLE Automation Object. The schematic takes advantage of this capability without having to know any specifics related to how SPICE processes the data and sends back a result. From the user's point of view, the two programs communicate flawlessly and transparently even though they may be from two different vendors. An OLE Automation object is an instance of a class that exposes properties, methods, and events to OLE Automation Controllers. Each OLE Automation object has its own unique members. Exposing the members makes the object accessible by an OLE Automation controller. You can expose two types of members for an object: Methods are actions that an OLE object can perform. Properties are functions that access information about the state of an OLE object.   All OLE Automation objects implement the IUnknown interface. This is a common OLE interface that allows controllers to get pointers to other interfaces on a given OLE object. A second interface, IDispatch, is implemented to expose the methods and properties of the object. Through IUnknown an application can make available all the interfaces that are supported. For instance, one SPICE server can support interfaces to multiple schematic vendors and even support multiple versions of these interfaces for the schematic packages. In this manner, the Automation Controller can obtain the proper IDispatch interface. A complete description of the OLE Automation interface is beyond the scope of this document. Detailed descriptions of OLE Automation can be found in the Microsoft Developer Library and most book stores.

OLE And Circuit Simulation In order to give you a better idea of how OLE enables interoperability, we'll take a look at the new ICAP system from Intusoft. ICAP is a set of five integrated EDA tools that perform analog and mixed signal simulation. ICAP includes ICAPS (the controlling application), IsSpice4 (the circuit simulator), IntuScope (the graphical data processor), SpiceMod (the SPICE Modeling utility) and IsEd (the text editor). The ICAPS program provides the main interface to the ICAP system and acts like a program manager controlling program flow for the active project. The Intusoft Integration Module provides the user interface for the ICAP system using the OLE Automation interfaces exposed by ICAPS and the interfaces exposed by third party EDA tools. Driving SPICE from a schematic requires more than the ability to generate a netlist. Many sub-tasks must be automated in order for the circuit simulation process to be made easy to use. In the past this has not been the case and users have invariably complained that SPICE is too hard to use. Special dialogs are needed for the SPICE control statements and Monte Carlo Options. And special facilities are needed to enable cross-probing of waveforms from the schematic. The following figure shows the communication flow between the ICAP programs and a third party schematic entry program.

A third party requests the general ICAPS interface, and then uses the exposed properties and methods to perform simulations and data analysis. Additional interfaces to control the simulator or post processor and to implement cross-probing features can also be obtained from the ICAPS interface. ICAPS will respond to the request by passing a pointer to the IDispatch of the requested interface. Type libraries are provided to ease the implementation of controlling applications. If the calling program allows menu items to be inserted, these menu functions can call interface methods and properties by connecting to an already created object by using the Running Object Table (ROT). This provides the schematic with greater access to the simulator resulting in a more seamless interface. In any case, the toolbar is a convenient way of providing access to a multitude of options. From the user's point of view, the functionality and associated dialogs added by the Integration Module are accessed from within the schematic. Hence, it appears as if the two packages were shipped together from the same vendor. From Intusoft's perspective, the OLE interface allows us to transparently integrate and upgrade the circuit simulation capabilities with other schematic front-ends without having to sign non-disclosure agreements and obtain proprietary information about the other packages. The schematic vendor, in turn, is able to keep up with latest SPICE simulation technology without having to make any code additions.

The ICAP OLE Interface All interaction with ICAP series of programs and the third party schematic packages is done through the interfaces of the ICAPS program using the Integration Module. Some of the Properties and Methods of this interface are described below. Property name Return type Description Application VT_DISPATCH Returns the Application object; read only. Caption VT_BSTR Sets or returns the title of the application window; read/write. Setting the Caption to VT_EMPTY returns control to the application. Cases VT_LONG Sets or returns the number of cases for a Monte Carlo simulation. CircuitName VT_BSTR Sets or returns the active circuit filename. (i.e. Sample.Ckt) DefaultFilePath VT_BSTR Sets or returns the default path specification used by the application for opening files; read/write. FullName VT_BSTR Returns the file specification for the application, including path; read only. For example, C:\SPICE4\IS. Monte VT_BOOL Sets or returns the state of the Simulation Control Monte flag. Parent VT_DISPATCH Returns the application object; read only. ScopeAdvise LPDISPATCH Sets or returns the IDispatch of the data processor IntuScope. SimPause VT_BOOL Sets or returns the state of the Simulation Control Simulator Pause flag. SpiceAdvise LPDISPATCH Sets or returns the IDispatch of the analog/mixed signal simulator IsSpice4. (Contains ICL Script interface) Version VT_BSTR Returns the version number of IsSpice4. Visible VT_BOOL Sets or returns whether the application is visible to the user; read/write. The default is True when the application is started with /Automation command-line switch. Method name Return type Description EditText VT_EMPTY If it is open and running the current circuit, IsEd is brought to the foreground. Otherwise, it is started. ForceSimulate VT_EMPTY Forces a simulation on the active circuit. The simulator is closed if it is currently open with the active circuit. Quit VT_EMPTY Exits the application and closes all open documents. ReleaseScopeAdvise VT_EMPTY Release the IDispatch for IntuScope. ReleaseSpiceAdvise VT_EMPTY Release the IDispatch for IsSpice4. Scope VT_EMPTY If it is open and running the current circuit, IntuScope is brought to the foreground. Otherwise, it is started. Schematic VT_EMPTY If it is open and running the current circuit, the schematic is brought to the foreground. Otherwise. it is started. Simulate VT_EMPTY If it is open and running the current circuit, IsSpice4 is brought to the foreground. Otherwise, a simulation is started.

OLE Interface for SPICE IsSpice supports two types of OLE enhancements. The first is that IsSpice is an OLE Automation Server. This means that any OLE Automation Controller can "drive" the simulator. For example, a math program, like MATLAB, could use SPICE as a simulation engine and ask it to run an analysis and pass back the results so that they can be used in a subsequent MATLAB calculation. IsSpice exposes an Interactive Command Language (ICL). ICL is a scripting language that contains a wide variety of simulation related functions such as analysis control functions and functions that change part values. Some of the key ICL functions are shown below. A simple "script", or macro, would be: view tran v(3) ; display V(3) as the simulation runs tran 1n 200n ; run a transient analysis print v(3) ; send the data for V(3) back to the Automation Controller The ICL is a publicly available protocol developed by Intusoft to interface external applications to the IsSpice4 simulator. It exposes all of the interactive functionality of IsSpice4. With OLE, the ICL interface is distilled into a form that makes it easy to access all the capabilities of SPICE.

Interface methods and properties for IsSpice4. Property name Return type Description Application VT_DISPATCH Returns the application of the object. Caption VT_BSTR Sets or returns the main IsSpice4 window caption. CircuitFullName VT_BSTR Sets or returns the active circuit filename witha full path. DefaultFilePath VT_BSTR Sets or returns the default path specification used by IsSpice4 for opening files; read/write. FullName VT_BSTR Returns the file specification for the application, including path; read only. For example, C:\SPICE4\IS. Name VT_BSTR Returns the name of the application. Parent VT_DISPATCH Returns the parent of the object. RemoteCommandFlag VT_BOOL Returns True if the remote command is still running ScriptOutput VT_BSTR Gets the contents of the IsSpice4 output window. Normally used after a Doscript ScriptErr VT_BSTR Gets the contents of Errors & Status window. ScriptStatus VT_BOOL Return True if ICL scripts can be sent to IsSpice4. Visible VT_BOOL Sets or returns whether the main IsSpice4 window is visible. Method name Return type Description DoScript VT_BSTR Sends an ICL command, or a set of ICL commands to IsSpice4. Simulate VT_BSTR Begins a simulation for the active circuit file. DoRemoteScript VT_BSTR Executes an ICL script remotely. Quit VT_EMPTY Exits IsSpice4. An example Visual Basic script that runs a simulation can be found in the file ICAPS.XLS A second OLE interface provides the ability to attach OLE Automation Servers to IsSpice as circuit elements. This interface is actually composed of two parts; an Automation Controller, called Array.DLL, and a set of OLE2 Automation Servers. Array.DLL is provided with the IsSpice4 program. The OLE2 Automation Servers represent a set of pre-defined SPICE models which dynamically link to IsSpice4 at run time. They are provided as examples of the types of servers that can be hooked into IsSpice4. The communications links are shown below. Referring to the above figure, the Array.DLL contains the OLE Automation Controller. On behalf of IsSpice4, Array.DLL will request the OLE Automation Servers to provide computing services to complete a simulation. Example servers include Fourier transforms, hardware interfaces for data acquisition boards and analog output boards, sound compression, and special file I/O. Users can add their own servers which are quite easy to create since they do not require any Windows interface (dialogs, menus, etc.) code. A useful server might contain a proprietary computational algorithm that must be simulated in SPICE along with other traditional circuitry. Also part of this interface is an embeddable OLE Object that allows real-time updating of simulation data. Those interested in integrating ICAP or IsSpice4 with their own products should contact Intusoft. More information is available along with a complete OLE specification.

Conclusions Once multiple vendors choose to communicate using OLE, a common interface can be easily implemented. Programs can then communicate with one another allowing the combined functionality to be exchanged, thus enhancing both applications. For example, such a situation exists in the Mechanical CAD field where 3D graphics can easily be shared and included in documentation among programs from different vendors. Hopefully this scenario will come to pass in the EDA arena where standard interfaces for circuit simulation and PCB layout programs would be welcomed. BIOGRAPHY Mr. Charles Hymowitz is the vice president of product development at Intusoft. He received his B.S.E.E. degree in Electrical Engineering from Rutgers University. He has done post graduate work at CSULB and UCLA. Mr. Hymowitz is the author of several books and numerous papers on SPICE and device modeling. He is the Editor in Chief of the industry standard SPICE publication, the "Intusoft Newsletter". Mr. Matthew Archambault is the chief applications engineer at Intusoft. He received his B.S.E.E degree in Electrical Engineering from Wilkes University. He has been part of the development team for a variety of simulation tools and has developed numerous analog and mixed signal simulation models for SPICE. Mr. Archambault is the main architect of the IsSpice and ICAP simulation interface including the OLE communication system.