Using Switch Views, Stop Views and the Hierarchy Editor

This chapter provides information on using switch views , stop views and the Hierarchy Editor . A switch view is a list that describes the views to use and their priority. A stop view is a list that designates when to stop moving down in hierarchy. In other words, if a view is in the switch view list, and also in the stop view list, it won't traverse any lower in hierarchy.

RFIC Dynamic Link supports the concept of using switch views and stop views . Dynamic Link also supports Cadence's Hierarchy Editor tool, which enables more detailed specification of switch views and stop views than the standard Artist forms. Switch views and stop views are utilized by the netlister to expand hierarchy. The Hierarchy Editor enables you to override the switch view list and stop view list for each instance in a schematic's hierarchy.

Note
The information provided in this chapter refers to using the Cadence Hierarchy Editor tool with the RFIC Dynamic Link and Advanced Design System. For more detailed information on using the Cadence Hierarchy Editor tool exclusively, refer to your Virtuoso Analog Circuit Design Environment User Guide . For more detailed information on expanding hierarchy in the Cadence environment, refer to the section on How the Netlister Expands Hierarchy in your Cadence documentation.

Expanding Hierarchy with the Dynamic Link Netlister

The flowchart shown in the following figure describes the general process used by the RFIC Dynamic Link netlister to move through and expand the hierarchy in Dynamic Link.

Netlist Hierarchy Expansion

In the Cadence schematic window, choose the DynamicLink > Setup Options menu item to access the Setup Options form. The Setup Options form enables you to designate a switch view list, and a stop view list.

Setting a Switch View List and a Stop View List.

Each instance in a hierarchy has a master cell, that contains a number of views for that cell. Typically views are schematic, symbol, layout, extracted, etc. The switch view list is used to enable you to designate the priority of each view for hierarchical netlisting. The stop view is used to designate whether a view in the switch view list should be traversed for hierarchy. A stop view is implied to have no hierarchy. For an example of this, refer to the design hierarchy_bottom in the library examples that is provided with the Dynamic Link installation.
In this example, the cell hierarchy_bottom has two alternate schematic views, schematic_ideal and schematic_parasitics (see the following two figures).

Alternate schematic view schematic_ideal for the example cell hierarchy_bottom .

Alternate schematic view schematic_parasitics for the example cell hierarchy_bottom .

Two instances of the cell hierarchy_bottom have been placed in the schematic hierarchy_top (see the following figure) in the examples .

The schematic view for the example cell hierarchy_top

This cell is in turn placed in the ADS example project design hierarchyTest , with the schematic view chosen as the Cadence view (see the following figure). Because there are two alternate schematics, it becomes necessary to tell the netlister which one to use when you netlist the design hierarchy_top . The switch view list is used to tell the netlister which one you want to use.

The cadence cell hierarchy_top placed in ADS

The following figure shows how the setup options have been changed to designate that schematic_ideal takes priority.

Switch View List with schematic_ideal taking priority

Referring to the Hierarchy Expansion flowchart in the figure Netlist Hierarchy Expansion, when an instance of hierarchy_bottom is encountered, the following occurs:

There is no ads view, so the next switch view is looked at.
There is no schematic view, so the code continues to the next switch view.
There is a schematic_ideal view. Since schematic_ideal is not in the stop view list, it is opened, so that a subcircuit can be netlisted for it.
With hierarchy_bottom as the top cell, now the first instance, and only instance encountered, is the analogLib res component. The switch view list is consulted.
- Is there an ads view? Yes, there is.
- Is the ads view a stop view? Yes, it is.

This means that the res component will not be opened as a schematic with hierarchy. Instead, it is meant to be a simulator primitive. Either a built in simulator component exists, which will be used, or a subcircuit definition has been included into the simulator that defines what the component is. A single component line is output for it, and the netlister continues on.

The following figure shows the resulting netlist from netlisting hierarchy_top with schematic_ideal having higher priority than schematic_parasitics . Note that the instances and subcircuit definition have been highlighted.

Netlist of the example cell hierarchy_top with schematic_ideal taking priority

If you prefer to use the schematic_parasitics schematic, the hierarchy_top schematic does not need to be changed. Instead, in the setup options form, you change the switch view list so that schematic_parasitics comes before schematic_ideal as shown in the following figure.

Switch View List with schematic_parasitics taking priority over schematic_ideal

Referring to the flowchart in the figure Netlist Hierarchy Expansion again, when an instance of hierarchy_bottom is encountered, the switch view list is checked. There is no ads view or schematic view. There is a schematic_parasitics view, which is not a part of the stop view list. This results in the netlister opening the schematic_parasitics view, which is netlisted as a subcircuit. The netlister then goes on to the next instance, without ever checking for a schematic_ideal view (in point of fact, it is not necessary to put schematic_ideal in the switch view list, since it will not be used). The following figure shows the resulting netlist with the setup options from the previous figure.

Netlist of example hierarchy_top with schematic_parasitics taking priority

In all of the above examples, the stop view list was set to ads . This is the recommended stop view list to use for the RFIC Dynamic Link netlister. If you consult the netlist flowchart in the figure Netlist Hierarchy Expansion, you will notice that it is not necessary for the stop view to be ads , any view can be used to designate that a part is a primitive. In the future, the RFIC Dynamic Link netlister will be expanded, so that alternate simulation definitions can be used based on which stop view is encountered (e.g. ads vs. ads_ptolemy). At present, the netlister always uses the simulation definition defined for ads in the cell's CDF, no matter which stop view is encountered.

Using the Hierarchy Editor with RFIC Dynamic Link

The Hierarchy Editor is a stand alone Cadence tool that enables switch views and stop views to be designated for each instance in a schematic hierarchy. For information regarding the hierarchy editor in general, consult your Cadence Hierarchy Editor User Guide .

When the Hierarchy Editor is used, a cell view specific to that tool is generated. The view itself is actually a text file, and cannot be opened directly in anything other than the Hierarchy Editor. The default view name for the Hierarchy Editor is config . A config view has a top cell view that it points to. All other information regarding switch views and stop views is then created based on the top cell view that is being pointed to. It is not necessary for the Hierarchy Editor view to be a part of the cell that it is pointing to, although in most cases this will be the simplest way to organize things.

The following figure displays the Create New File form used to create a Hierarchy Editor view. In this case, a Hierarchy Editor view is being made for the example cell hierarchy_top (see the figure The schematic view for the example cell hierarchy_top). The goal is to set up this config view so that, during netlisting, it is possible to specify that one instance of hierarchy_bottom should use the schematic_ideal view, while the other instance uses the schematic_parasitics view.

Creating a Hierarchy-Editor view

After the new view is created, the Hierarchy Editor tool is started. For a new view, the New Configuration form appears as shown in the following figure.

New Hierarchy Editor Configuration

Notice that all fields are left blank initially, except the Library and Cell fields which were specified in the Create New File form shown in the figure Creating a Hierarchy-Editor view. At this point, it is necessary to designate the top cell view, as well as the switch view list and stop view list. The Library List can normally be left blank. For more information on the Library List field, refer to your Cadence Hierarchy Editor User Guide .

It is necessary to fill in the Top Cell view. The top cell view should be a standard CDB view. From the standpoint of RFIC Dynamic Link, this means either a view that is edited with Virtuoso-schematic, or Virtuoso-layout. If you use a layout view, it should be an extracted view of some sort (i.e. the layout will contain connectivity and instances that can be traced back to schematic equivalents). Typically, you will put in either schematic or extracted as the view name.

The Library List, View List, and Stop List can be filled in by using a template. Templates contain default settings for particular simulators. To select a template, click the Use Template button in the New Configuration form. The Use Template form appears.

In the following figure, the ads template was selected, which has filled the View List in as ads schematic extracted , and the stop list as ads . These names represent the default view names for the tools that the Dynamic Link netlister supports. During netlisting, the view list and stop list will override the switch view list and stop view list that is specified using the Dynamic Link setup options dialog. Also, the Hierarchy Editor view will not consult the Dynamic Link options dialog to fill in the switch view list or stop view list, it is a completely separate tool, and must be set up independently.

New Hierarchy Editor Configuration, using ADS template

When the new configuration is accepted, the main Hierarchy Editor window will be filled out. The main window shows the current Top Cell setting, as well as the global Library List, View List, and Stop List. In addition, the Hierarchy Editor will expand the hierarchy of the top cell, and show which views will be used for each instance within the top cell's hierarchy. When nothing has been overridden, the expansion will follow the flow chart shown in the figure Netlist Hierarchy Expansion. The following figure shows how the example hierarchy_top schematic view was expanded using the global bindings. The Cell Bindings shows the two cells that were found, hierarchy_top and hierarchy_bottom . You may need to select View > Update to see the hierarchy_bottom Cell in the Cell Bindings list. The view found for hierarchy_top was schematic, this is a special case. Because it is the top cell, the library, cell, and view found will always be the same as what is specified for the top cell, regardless of the view list and stop list. The cell hierarchy_bottom says that the view found was **NONE**. Because hierarchy_bottom has the views schematic_ideal , schematic_parasitics , and symbol , this is accurate. None of hierarchy_bottom 's views are in the global view list. If netlisting were attempted at this point, an error would result. The cell bindings give a visual indication of this.

Initial Hierarchy Editor Main Window

In the following figure, the global view list has been changed, so that it now includes schematic_ideal and schematic_parasitics . The cell bindings are now updated to reflect the new hierarchy expansion. Because schematic_ideal precedes schematic_parasitics in the global view list, the expansion now says that, for hierarchy_bottom , schematic_ideal is the view found. Also, the analogLib res cell has been found, because hierarchy_bottom was expanded. This expansion happens because schematic_ideal is not listed in the global stop view list. Since res has an ads view, the expander decides that ads will be the view used for the res cell.

Hierarchy Editor with schematic_ideal in Global View List

So far, all of this demonstrates is that the Hierarchy Editor can be used to see how expansion would occur for a specified view list and stop list. That's nice, but it doesn't add any functionality over what was provided by the Setup Options form. What is needed is a way of overriding the view list. As it happens, the Hierarchy Editor is capable of doing just that.

In the following figure, the switch view list has been changed, so that schematic_parasitics is now first in the switch view list.

Hierarchy Editor with an instance view overridden

Notice that the instance bindings table is now displayed. When hierarchy_top is selected, the instance table shows all of the instances in the schematic. As it happens, hierarchy_top contains two instances of hierarchy_bottom , I2 and I3 (see the figure The schematic view for the example cell hierarchy_top). If the global switch view list is used, both instances will expand to use schematic_parasitics. In this case, we have chosen to change the default behavior. In the view to use field, schematic_ideal has been specified. The view found field now specifies schematic_ideal instead of schematic_parasitics . Now, when the cell hierarchy_top is netlisted with this configuration, it will be necessary to expand the hierarchy for both schematic_parasitics and schematic_ideal. The netlister keeps track of the proper component name for the netlist.

The figure below shows the resultant netlist that is created using this configuration.

Netlist using configuration detailed in figure 10-15.

An alternate way of viewing the overridden expansion is to look at the tree view, as opposed to the cell and instance binding tables. This is shown in the following figure.

Tree view of hierarchy_top configuration with I2 set to use schematic_ideal.

The Hierarchy Editor makes it possible to override the hierarchy expansion on any instance. It is also possible to override the global switch view list on any instance. This allows you to change the expansion options for one tree of a hierarchy, while leaving all other trees intact.

Placing the config view in ADS

In order for a Hierarchy Editor configuration to be used during netlisting, it is necessary to place the Hierarchy Editor view in the ADS schematic. This is done by selecting the DynamicLink > Instance > Add Instance of Cellview menu option in ADS. When the Select Design dialog appears, set the view name to the Hierarchy Editor view. In the hierarchy_top example, this is done by selecting the view name config (see the following figure).

Selecting the Hierarchy Editor view for placement in ADS.

A new symbol is generated for the config view, and you are then be able to place it. In the hierarchy_top example, the symbol graphics are inherited from the hierarchy_top cell. This results in a symbol that looks identical to the hierarchy_top schematic symbol for ADS. However, this symbol is now linked to the Hierarchy Editor view, as opposed to being linked to the schematic view.

Hierarchy Editor test bench with config view placed

The previous figure shows the new test bench where the config view is used instead of the schematic view. If the Cadence instance is selected, and you descend into it's hierarchy, the top cell view for the configuration will be opened. The configuration being used will be indicated in the title of the schematic/layout window that is opened. The following figure shows the hierarchy_top schematic that will be opened. Note that the title indicates that the Config in use is examples hierarchy_top config . This is important, as it means that hierarchy expansion will obey that particular configuration.

Note also that the top cell view does not need to remain constant. Thus, if you wish to do a simulation where the top cell schematic is used, and then do another simulation wherein an extracted view is used, you do not need to make multiple ADS symbols and then swap them. You can make a single Hierarchy Editor configuration, and swap the top cell view name. Once the test bench is set up, you do not need to modify anything in ADS to change your simulation. For the hierarchy_top example, a simulation would result in the netlist shown in the figure Netlist using configuration detailed in figure 10-15., based on the configuration shown in the figure Hierarchy Editor with an instance view overridden.