4

---

Customizing the Interactive Simulation Environment (ISE)

---

The Interactive Simulation Environment (ISE) enables designers to run simulation interactive Simulation Environment (ISE) enables designers to run simulation interactively while remaining in the Cadence graphics environment.

With an interface to a simulator developed using ISE, designers can

• Interact directly with the simulator.
• Use simulator menus.
• Point at the design to interact with the simulator.

Use OSS and SE to develop an interactive simulation interface, just as you develop a batch interface. You can customize ISE using SKILL. All of the functionality described in this manual is available to you when you develop an interactive interface.

This chapter explains the strategy behind ISE, the way designers use an interactive interface, the way ISE works, and the way you can customize ISE to run your simulator.

Understanding Interactive Simulation

Because ISE is an extension of SE and OSS, all information in this manual on generating netlists and stimulus, and integrating a simulator applies to ISE. This chapter describes extensions and functionality that relate only to interactive simulation.

Interactive and Batch Simulation

Interactive simulation differs from batch simulation. A sequence of steps for running batch simulations can be effortlessly defined. The steps performed during an interactive simulation are determined by the designer. Developing an interactive interface using ISE differs from developing a batch interface using SE because the sequence of steps cannot be determined in advance. In addition to developing the netlist interface, you must also generate a menu and the SKILL functions necessary to run the simulator interactively. This menu may contain many simulator-specific commands. Depending on the application program being integrated, the overlap of these commands with another application can be small.

Only the framework required to develop an interactive interface, or the functional primitives, are provided in ISE because the commands available in an interactive application can vary drastically. You can use these functions with SE and SKILL to create higher level commands used by designers to run interactive simulations.

Creating an Interactive Interface

ISE provides the functionality not available in SE to develop an interactive simulation interface. By building on SE, it is possible to simplify creating an interactive environment and provide consistency between a batch and an interactive interface to the same application. All the basic concepts apply to both interfaces. A netlist is required to communicate the connectivity of the design to the simulator, a single directory called the simulation run directory is used to store all of the inputs and outputs used and produced by the simulator, and functions are provided to translate names used in the design to names acceptable to the simulator.

You can integrate a new simulator into the Cadence environment as an interactive simulator, or you can enhance an existing batch interface to provide both batch and interactive abilities. This migration is an evolutionary process, not a complete redesign. It is simplest first to develop the batch interface so you develop a thorough understanding of SE; then extend this interface so it also functions interactively. Virtually all of the batch interface you develop will be common to the batch and the interactive environments. If you developed the batch interface as described in the “Customizing the Simulation Environment (SE)” chapter in this manual, the extension to an interactive environment involves developing the set of SKILL functions and menus necessary for issuing commands directly to the simulator.

ISE provides you with all of the functions you need to create and maintain the windows used to run a simulator interactively, communicate between windows, translate names interactively, and issue commands to the simulator.

Using an Interactive Simulation Interface

An interactive interface allows designers to interact with the simulator while remaining inside the Cadence graphics environment. It is possible to issue commands to the simulator directly or through menus and interaction with the graphic representation of the design.

Initializing the Interactive Environment

Before invoking an interactive simulation, the designer must execute the simulation environment Initialize command. Once the simulation environment has been initialized, the designer can invoke an interactive session. If no netlist exists in the current simulation run directory, the designer is prompted to determine if he would like one generated before starting the session.

Creating Windows for Interactive Simulation

Next, the windows required to run an interactive simulation are created. By default, the schematic and simulation windows appear. However, you can disable the schematic window.

The schematic window is opened to edit the design, and the design is automatically edited in that window.

The simulation window lets the designer interact with the simulator. This is a text window that displays text output from the simulator. The designer can use this window to issue commands directly to the simulator. The simulator specified is automatically started and linked to this window.

All of the initialization steps are controlled by SKILL variables. The default is to initialize the environment as specified above. However, a designer can modify the default initialization at this point. For example, a designer could alter the window arrangement.

Running the Simulation

Once the environment has been set up, the way the simulation is run is under the control of the designer. There are no predetermined steps. For example, a designer can modify the design in one window and instruct ISE to update the connectivity for the simulator. ISE netlists the design in the foreground and instructs the simulator to read in the netlist. Once these steps are completed, control is returned to the designer.

The designer can instruct ISE to update the simulator with new stimulus for running the simulation. This may require the user to create the input stimulus or simply translate a file of designer-entered stimulus. The translation of the input file is done to convert the designer-assigned names to names assigned by the netlister. Once the stimulus is prepared for input to the simulator, ISE automatically instructs the simulator to read in the stimulus.

The designer can instruct the simulator to simulate for a period of time. ISE issues the appropriate command to the simulator and returns control to the designer. The designer can continue to work while the simulator is running the simulation. As the simulation is running, text output from the simulator is continuously being updated in the simulation window. This display is updated until the designer requests the updating to stop. Updating is also suspended while a menu is on the screen.

Once the simulation stops, the designer can instruct ISE to set a specified node to a specific value. The designer selects the command and points at the node to be set in the schematic window. ISE determines the netlister-assigned name of the selected node and issues the appropriate instruction to the simulator. Next, the designer can instruct the simulator to continue the simulation by using an ISE command or by typing directly into the simulation window.

Ending the Session

At any point, the designer can end the simulation session by selecting the Finish Interactive entry from the menu. ISE issues the appropriate commands to terminate the simulator and closes all of the windows it opened.

When the designer ends the session, the environment is the same as it was before starting ISE. The designer must instruct ISE to terminate the session instead of closing the windows manually, or all of the ISE processes will not be properly terminated until the designer leaves the graphics environment.

Customizing ISE

To fully utilize ISE, you must understand the environment that has been created and make use of the features in a structured and ordered manner. The following sections describe different aspects of ISE that you can use while developing your interface:

ISE Interfacing Steps

Describes the steps to perform when developing an interface using ISE.

Foreground Simulation Environment

Describes how you can use SE commands when developing your interactive interface.

Window Environment

Describes the windowing environment and how it can be used by an interactive interface.

Menu Commands

Describes how to create menus that make use of the windowing environment and issue instructions to the appropriate application.

ISE Variables

Describes the variables defined by ISE that you can use in the Cadence graphics environment to develop an interactive interface to your simulator.

ISE Functions

Describes the functions defined by ISE that you can use in the Cadence graphics environment to develop an interactive interface to your simulator.

ISE Interfacing Steps

When you create an interactive simulation interface, you perform these steps:

• Generate a batch interface
• Design the interface for graphic and nongraphic execution
• Create an interactive menu and SKILL commands

Generate a Batch Interface

Before you can generate an interactive interface to your simulator, you should generate a batch interface. Aside from the flexibility this affords your designers, the interface you develop will be the starting point for your interactive interface. To develop a batch interface to your simulator, follow the steps outlined in the “Integration Steps” section of the “Integrating Simulators” chapter of this manual.

Design the Interface for Graphic and Nongraphic Execution

After developing a batch interface to your simulator, make sure it also executes as a foreground SKILL command in the graphics environment. The main differences between the graphic and nongraphic environments are in displaying messages and executing UNIX commands. If you follow the instructions in the “Customizing the Simulation Environment (SE)” chapter in this manual, your interface should already be capable of executing in both environments. To ensure that messages can be displayed in both environments, always use the simPrintMessage() and simPrintError() functions instead of writing directly to the stdout and stderr ports. To ensure that any programs you invoke as part of the simulation process will function in both environments, always use the simExecute() function instead of system(), csh(), or sh(). Never use any SKILL functions that require a graphic interface unless you are certain the command is invoked only in the graphics environment. You can test which environment the function is executing in by testing the value of the simRunningInSi variable.

Create an Interactive Menu and SKILL Commands

The last step in creating an interactive interface is creating the interactive menu and corresponding set of SKILL commands your designers will use when running an interactive simulation. Creating menus is described in the Virtuoso Design Environment User Guide. You can code the menus in SKILL and they will invoke the SKILL commands you specify. It is not possible to describe the commands you need to create for your simulator. However, there are basic features common to most simulators. For example, a command to update the netlist would invoke the iseUpdateNetlist() ISE function. Another common command is to force a node to a specific value. To do this, you can write a function that will get the simulator input name of the node the designer is pointing at by calling the iseGetExtName() ISE function. You then create a command in your simulator’s input syntax using that name to force the node and issue the command to the simulator using the isePrintSimulatorCommand() ISE function. For a full description of the functions and variables available to you in ISE (in addition to the SE functions described in the “Customizing the Simulation Environment (SE)” chapter in this manual), refer to the “ISE Variables” and “ISE Functions” sections at the end of this chapter.

Foreground Simulation Environment

Most of the functionality required to create an interactive simulation interface is provided by the foreground SE capabilities. To generate an interactive interface, you must be able to reference all global environment variables used by SE, as well as being able to netlist and translate names as a programmable part of your interface. Depending on the completion status of any particular command, you may need to execute special functions. These capabilities are all available in SE.

Global Environment Variables

All global environment variables defined in batch SE are also available directly from SKILL once the Initialize menu command has been executed.

SE Functions

All functions defined in SE are directly available to you from SKILL once the Initialize menu command has been executed. The same functions used to develop a batch simulation interface can be called by a SKILL procedure you write. For example, you can use the netlist() function provided by SE to generate a netlist. This function executes in the same manner in the graphics environment as in the standalone, nongraphic SE program. The function does not return control until it has completed. Once it has completed, it will return t on success, or nil on failure. Your SKILL procedure can use this return status to determine whether to issue an instruction to the simulator to input the netlist or load a probe file into the schematic window to highlight the error regions in the design that caused the netlister to fail.

All SE variables and functions are described in the “Customizing the Simulation Environment (SE)” chapter in this manual. Most of these functions are not available until the Initialize command has been executed.

Differentiating Between Graphic and Nongraphic Environments

Some functions you develop may behave differently depending on the availability of a graphic interface. For example, when graphics are available, you might want to display a form that enables the designer to verify the parameters used to invoke the simulator. This is only possible in the graphics environment. In addition, both the ISE and the SE code used to invoke batch simulations reside in the same simulator-specific caplib file described in the “Customizing the Simulation Environment (SE)” chapter in this manual. The simRunningInSi variable enables you to determine in which environment a procedure is invoked. You should never set this variable. In the graphics environment, it is set to nil. In the non-graphics environment, it is set to t.

Window Environment

With ISE you can issue commands to the simulator, and the Graphics Editor directly. If one of the windows ISE uses has been closed, ISE will not execute the functions that interact with that window.

The functions provided by ISE to interact with the windowing environment are documented in the “ISE Functions” section at the end of this chapter.

Menu Commands

After developing a batch interface to your simulator, you can convert it to an interactive interface by creating the commands and menus required to interact with the simulator and design. You can customize the menus for the schematic and simulation windows. ISE does not bring up any default menus except the Probe menu in the schematic window and the System menu in the simulator window.

To create a menu, define it (as a pull-down menu) using the menu creation routines (such as hiCreateMenuItem, hiCreatePulldownMenu, etc.) described in User Interface SKILL Functions. One menu handle is returned per call to the routine hiCreatePulldownMenu.

To instruct ISE to bring up the menus you define, use the iseSchematicMenuHandle and iseSimulatorMenuHandle variables. The iseSchematicMenuHandle variable is the SKILL list of menu handles for the schematic window. The iseSimulatorMenuHandle variable is the SKILL list of menu handles for the simulation window.

For example, to bring up menus in the schematic window with the handles, A and B, and menus in the simulation window with the handles, C and D, write the following:

iseSchematicMenuHandle = list( A B )
iseSimulatorMenuHandle = list( C D )

You must create these menus before you can call the iseInitSimWindow and iseInitSchematicWindow functions.

The best place to put menu-generation code is the simulator-specific caplib file. Enclose the code by an if-then statement, where the if condition specifies whether the current simulation session is invoked in the graphics or nongraphics environment. An example of the menu-creation code is shown here:

if( ! simRunningInSi then
   menuItem1 = hiCreateMenuItem( 
      ?itemText "start simulator"
      ?callback "iseStartSimulator()"
      ?name ’menuItem1)
   menuItem2 = hiCreateMenuItem(
      ?itemText "exit simulator"
      ?callback "simVerilogExitSimulator()"
      ?name ’menuItem2 )

   myPulldownMenuHandle = hiCreatePulldownMenu(
      ’myPulldownMenuHandle
      "simulator commands"
      list(       ’menuItem1
            ’menuItem2 )
      "this is a help message" 

   iseSimulatorMenuHandle = list( myPulldownMenuHandle )

)

If your menu has several pull-down menus, create them similarly. Then, put the menu handles together into a SKILL list and pass it to ISE through the variable iseSimulatorMenuHandle. For example:

iseSimulatorMenuHandle = list( myPulldownMenuHandle1
   myPulldownMenuHandle2
   ........ )

The commands you create depend on the capabilities of your simulator.

Filtering Simulator Inputs and Outputs

Use the iseFilterInputFunc and iseFilterOutputFunc variables to filter inputs and outputs to and from the simulator. These variables let you register functions to be called when there are inputs (simulation commands) to or outputs from the simulator. Then you can filter this data before passing it back to ISE to send to the simulator or print to the simulation window. To pass the filtered input to ISE to send to the simulator, call the iseCommToSimulator(text) function. To pass the filtered output to ISE, call the iseSendOutputToEncapHistory(text) function.

Creating User Specified Window Placement

Use the iseSchWinAttrId, iseSimAttrId, and iseWaveAttrId variables to specify default window size and placement of the windows opened by ISE in your .Xdefaults file. You can use these variables to specify the attribute string name you use in your .Xdefaults file to identify the defaults for each window.

To specify the desired window size in the .Xdefaults file, the keyword Opus must to be added in front of the window attribute string (example: Opus.userSchSize: 100x200+10+400). When you change the .Xdefaults file, you need to use xrdb .Xdefaults to read the change into the X resource database. Otherwise, the new window sizes won’t be used.

ISE Variables

This section describes the variables defined in ISE.

iseDontOpenSchematicWindowIfOneExists

If set to t, ISE searches all windows and makes the ISE schematic window the first window it finds with the appropriate design that was opened in append mode. If no such window exists, ISE searches all windows and makes the ISE schematic window the first window it finds with the appropriate design that was opened in read or write mode. If no such window is found, ISE opens a new schematic window with the appropriate design opened in append mode.

Default: nil

iseExitSimulator Command

Command issued to terminate the simulator. You must set this variable to a SKILL string that is the exit command for the simulator.

Default: nil

iseFilterInputFunc

Registers your function so that any command string typed into the simulation window (up to the last carriage return/line feed character) is returned to you by the ISE function iseGetInputFromEncapWindow(). You can then filter this simulator command before you pass it back to ISE to send it to the simulator.

Default: nil

iseFilterOutputFunc

Registers a function to be called whenever ISE receives outputs from the simulator. You can then filter these outputs if needed before you pass them back to ISE for printing to the output portion of the simulator window.

Default: nil

iseInitSchWindowFunc

Name of the function for initializing the schematic window.

Default: iseInitSchematicWindow()

iseInitSimWindowFunc

Name of the function for initializing the simulator window.

Default: iseInitSimWindow()

iiseInputNetlistCommand

Command for reading the netlist into the simulator.

Default: nil

iseInputStimulus Command

Command for reading stimulus into the simulator.

Default: nil

iseInvokeSimulatorFunc

Defines the routine you want to call for preprocessing before invoking the simulator. Before the routine returns, you must define the variable iseRunSimulatorCommand. The value of this variable must be the command ISE needs to invoke your simulator. The iseInvokeSimulatorFunc variable takes precedence over iseRunSimulatorCommand. If iseInvokeSimulatorFunc is defined, it will be used first; that is, the preprocessing routine will be called. When the preprocessing routine returns, the variable iseRunSimulatorCommand must be defined.

Default: nil

iseOpenWindowsFunc

Default function for opening windows used by ISE.

Default: iseOpenWindows()

iseReleaseFunc

Name of the function for defining and sending the command to release a node from a preset value.

Default: nil

iseRunSimulator Command

Command to invoke the simulator. You must set this variable to a SKILL string that is the invocation command for the simulator. Define this variable in your .simrc file, or if you want to do preprocessing before invoking the simulator, define it in the preprocessing function (using the variable iseInvokeSimulatorFunc). The variable iseRunSimulatorCommand must be set and returned from the preprocessing routine before the simulator can be invoked (see also iseInvokeSimulatorFunc).

Default: nil

iseSchematicMenu Handle

A SKILL list of the handle of the menu (or menu handles if you have more than one menu) you want to display in the schematic window. You can create this menu by writing SKILL code and using Cadence’s menu-creation routines, such as hiCreateMenuItem, hiCreatePulldownMenu, etc.

Default: nil

iseSetFunc

Name of the function for printing the set node command in the simulator window.

Default: nil

iseSimulateFunc

Name of the function for printing the simulate command in the simulator window.

Default: nil

iseSimulatorMenuHandle

A SKILL list of the handle of the menu (or menu handles if you have more than one menu) you want to display in the simulation window. You can create this menu by writing SKILL code and using Cadence’s menu-creation routines, such as hiCreateMenuItem, hiCreatePulldownMenu, and so forth.

Default: nil

iseStartSimulatorFunc

Name of the function for invoking the simulator.

Default: iseStartSimulator()

iseSchWinAttrId

Name of the identifier used in the .Xdefaults file to specify the placement and size of the schematic window opened by ISE. ISE will only use .Xdefaults for window placement if the user preference for window placement is set to the default value. For example, if the following line appeared in your .Xdefaults file:

Opus.userSchSize: 100x200+10+400

set this variable:

iseSchWinAttrId = "userSchSize"

Default: nil

iseSimWinAttrId

Name of the identifier used in the .Xdefaults file to specify the placement and size of the simulation window opened by ISE. ISE will only use .Xdefaults for window placement if the user preference for window placement is set to the default value. For example, if the following line appeared in your .Xdefaults file:

Opus.userSimSize: 100x200+10+400

set this variable:

iseSimWinAttrId = "userSimSize"

Default: nil

ISE Functions

OSS provides various ISE SKILL functions. For details on the ISE SKILL functions, see OSS Functions in the Digital Design Netlisting and Simulation SKILL Reference.

Remote Interactive Simulation

The interactive simulation environment (ISE) supports remote and local interactive simulation. Remote interactive simulation is starting and running an analysis tool on another machine somewhere in the network. ISE has two different modes of support for remote interactive simulation: network file system (NFS) mode and copy mode.Chk the following text wrt waveform and suggest.

You can dynamically interact with the analysis tool in either remote interactive simulation mode. In NFS-mount mode, the local run directory is mounted (either through manual mount or automount) onto the remote node where your analysis tool runs. Using this mode, you can use your integrated tool to dynamically display waveforms. In copy mode, relevant data is copied to the remote node for analysis, thus preventing the dynamic display of waveforms.

NFS-Mount Mode

NFS allows transparent access to disks located on different machines in the network. The machine where you are running the Cadence environment is referred to as the local node. The machine where your analysis tool is running is referred to as the simulation node.

Automount and manual mount are two different types of directory access under NFS. Automount automatically mounts a disk on another machine in the network when the local machine accesses a directory on the remote disk. Manual mount mounts a disk remotely, either through an entry in the
/etc/fstab file or by using the UNIX mount command. ISE supports both types of directory access.

Usually, you want to take advantage of NFS mounting to run simulation on a remote machine, while pointing to your data on the local machine. With NFS-mount, the online dynamic display of waveforms is possible with any display tool that is integrated into OSS and ISE.

Copy Mount Mode

If NFS-mount is not available, you can still run remote interactive simulation using ISE. In copy mode, ISE copies all data, such as netlists and stimuli, from the local run directory to the remote machine for use in remote simulation.

Assigning the Path

In the following examples, the local node is localmachine, the remote node is remotemachine, and the local run directory in localmachine is

/usr/mySimRunDir. 

When using NFS-mount mode, the variable iseRemoteDiskFullPathName provides the full path name of the mounted directory on the remote node. You can use the ISE variables to incorporate remote interactive simulation. For example, the disk “/usr” on localmachine is mounted onto remotemachine and is named /localmachineUsr. The simulation run directory carries the full path name /localmachineUsr/mySimRunDir.

• In NSF-mount mode, assign the full path name to the variable iseRemoteDiskFullPathName as shown.

iseRemoteDiskFullPathName = "/localmachineUsr/mySimRunDir"

In copy mode, the variable iseRemoteDiskFullPathName is the full path name of the run directory on the remote node remotemachine. You select the location of this run directory on remotemachine. Relevant data, such as netlists and stimuli, are copied from the local node to this remote node for use by the analysis tools. Analysis results reside temporarily in the directory iseRemoteDiskFullPathName until the end of analysis. At that time, all data, including the analysis results, is copied back from the directory iseRemoteDiskFullPathName on remotemachine to the local run directory in localmachine.

• In copy mode, assign the full path name to the variable iseRemoteDiskFullPathName as shown.

iseRemoteDiskFullPathName = "/usr/disk1/mySimRunDir"

There is no default value for this variable. You must bind this variable if you want to run remote interactive simulation using ISE.

Selecting the Mode

The string variable iseRemoteMode identifies the mode of remote simulation you intend to use.

• In NFS-Mount mode, set the value of iseRemoteMode to mount:
  

  iseRemoteMode = "mount"

• In copy mode, set the value of iseRemoteMode to copy:
  

  iseRemoteMode = "copy"

There is no default value for this variable. You must bind this variable if you want to run remote interactive simulation using ISE.

Copying the Simulation Files

The variable iseFilesForRemoteSimulation identifies the files on localmachine that you want copied to the run directory on remotemachine. This variable is a SKILL list of fully qualified file names.

• In copy mode, set the variable iseFilesForRemoteSimulation to a list of files to copy to the remote node.
  

  iseFilesForRemoteSimulation = '("/usr/mySimRunDir/si.inp"
  "/usr/mySimRunDir/stimuli.file1" 
  "/usr/mySimRunDir/stimuli.file2")

The si.inp file is automatically included in the files to be copied to the remote node.

• If you do not want to copy the si.inp file, set the variable iseUserWantCompleteFileCopyControl to t. (The default value is nil.)
  

  iseUserWantCompleteFileCopyControl = t

OSS System Requirements

For remote simulation using OSS/SI/ISE, the following system requirements must be met:

• On the local node, the executable serv must be accessible through your UNIX search path. This is a Cadence-supplied executable and can be found in install_dir/tools/dfII/bin.
• On the remote node, you must have a login directory, and the executable serv must be accessible through your UNIX search path.

Return to top