Controlling the IC-CAP System

This section provides details on the use of the iccap_func command. The first example in this chapter illustrated the iccap_func command:

 iccap_func("/npn/dc/fgummel","Display Plots")

The iccap_func command needs at least two arguments. The first argument is the name of an object on which you want to act and the second argument is the action you want to perform.

In addition, you can provide responses when the macro requires user input (through dialog boxes) during execution. This capability to answer provides truly automated operation. If you do not provide answers in advance, the dialog boxes appear when the macro executes and wait for input. For further information on this capability, refer to the section Anticipating Dialog Boxes.

Specifying an Object

IC-CAP is implemented in an object-oriented fashion. To the user, this means selecting an object in the system, such as a setup, and then selecting an action, such as Simulate. The iccap_func command reflects this object-oriented style, since the command requires an object name and then an action. The command searches first for the object within the IC-CAP system and then, having found the object, it executes the action to be performed on that object.

When using the iccap_func command, particularly within a macro, you specify objects by using a leading "/" character in their names.  (When viewing the setup in the Model window, the leading character is not shown, so it is easy to forget this detail when programming with iccap_func.) For example:

 iccap_func("/npn/dc/fgummel","simulate")

The hierarchy of objects is illustrated next. An asterisk (*) next to an object (in the illustration) indicates that multiple objects or items with different names can be specified for that object. For example, a model may have many DUTs, but only one Parameter Set.

IC-CAP
   |— Variables
   |— GUI Items
         |— GUI Items
   |— Simulation Debugger
   |— Hardware
         |— HPIB Analyzer
   |— PlotOptions
   |— MODEL(*)
         |— Variables
         |— GUI Items
               |— GUI Items
         |— Circuit
         |— PlotOptimizer
         |— PlotOptions
         |— Parameter Set
         |— MACRO(*)
         |— DUT(*)
               |—Variables
               |— GUI Items
                     |— GUI Items
               |—Test Circuit
               |—Device Parameter Set
               |—SETUP(*)
                     |—Variables
                     |— GUI Items
                           |— GUI Items
                     |—Instrument Options
                     |—INPUT(*)
                     |—OUTPUT(*)
                     |—TRANSFORM(*)
                     |—PLOT(*)
                            |— PlotOptions

Specifying an Action

Having identified an object, such as /npn/dc/fgummel, you then provide the name of an action to perform on it. Many of the available actions in IC-CAP are made up of multiple words, such as Rebuild Active List in the Hardware window. When specifying a multi-word action, spaces and capitalization do not matter. However, when specifying the object, spaces (or the lack of) and capitalization are critical. IC-CAP allows you to name one model as npn and another as Npn, so the spelling and capitalization of an object must be exact.

Ambiguous Object Names

In the IC-CAP system, it is possible for two objects to have the same name. For example, in an npn model, there is nothing to prevent you from naming a DUT as dc_dut and naming a macro the same thing. Perhaps this Macro performs all necessary characterization operations for the DUT of the same name.

To eliminate confusion in such cases, include an optional object type when specifying the name of the object. For example, suppose you have a DUT and a macro called xyz. Specifying:

iccap_func("/npn/xyz","execute")

does not work. Even though the DUT does not have an execute action associated with it, IC-CAP does not know how to differentiate the object. Instead, include the object type:

iccap_func("macro /npn/xyz","execute")

Anticipating Dialog Boxes

It is possible to provide answers, in advance, for dialog boxes that arise during execution of a macro. These are provided as additional arguments to the iccap_func command. The following example calls the Save As dialog box, which requires a filename for saving the setup:

iccap_func("/npn/dc/fgummel","Save As","fgummel.set")

In this example, fgummel.set is provided as the filename that you would otherwise type in the dialog box displayed by the Save As command. You can include any number of string expressions, separated by commas, to anticipate any number of dialog boxes. If you fail to anticipate all of the dialog boxes and do not provide answers for all of them, then the system displays the dialog boxes when the macro runs, and you can provide answers at that time.

Another interactive technique is to anticipate the dialog boxes and use the LINPUT command to prompt the user for the information to be supplied. Without this prompt, you may see a dialog box in which a filename is requested, but not know what the file is to be used for.

LINPUT "Enter filename to save the Setup fgummel:",
user_answer iccap_func("/npn/dc/fgummel","Save As",
user_answer)

It is possible to stop a macro from running if iccap_func generates an error message box. Include the following command to monitor the error log, and read the number of characters in the error box text:

 x=check_error_log()

If the number of characters has increased since the last call to iccap_func, the macro can be programmed to stop.