Verifying a Library

This chapter gives an overview of how you could go about verifying that your symbols are working in ADS. The verification procedures cover the following steps:

• Verifying Component Netlisting
• Verifying Component Simulation Results
• Verifying Component Layout Representation
• Verifying Design Synchronization

While the following sections will describe some recommended procedures for verification, they are by no means comprehensive. It will be up to you, the librarian, to decide what tests will prove that the library is working as expected. If your library can pass the suggested verification procedures, it does not guarantee your library will work in your design flow.

Verifying Component Netlisting

The purpose of verifying component netlisting is to ensure that the following conditions are being met:

• Correct sub circuit is output.
• Proper component is being used for the instance.
• Correct number of pins are output for the instance.
• Pin output order matches the subcircuit port order.
• Proper parameters are being output for the instance.

If these five conditions are met, then you can assume that your component is netlisting properly.

Recommended Schematic Preferences

Because you will need to know which pin was output, it will be necessary to add a lot of wire labels to the design. Adding wire labels does not help very much if the wire labels are not added to the correct instance pin. While verifying netlisting, you should turn on the schematic preference that shows the pin names and the pin numbers on the schematic. This is done by selecting the menu Option > Preferences on the schematic window. The schematic preferences dialog will be displayed (Schematic Preferences dialog). Select the tab marked Pin/Tee. There is a table labeled Visibility (on/off) . By default, Pin Numbers and Pin Names will not be activated. Both should be activated, and then the Apply or OK button should be clicked. After this is done, schematic instances will have the pin name and pin number of the instance pin displayed in the schematic.

Schematic Preferences dialog

In addition to the pin name/number visibility, you may also want to change the size of the component annotations. By default, 12 point Arial will be used as the font size. This may be much too large when compared with the size of the components being used in ADS. If the Component Text/Wire Label tab is selected on the Preferences for Schematic dialog, the default size of the pin name and number annotation can be changed by changing the point size option in the Font Definition table. The wire label size can be changed by setting the point size option in the Wire/Pin Label table.

Creating a Schematic to Verify a Netlist

Verifying netlisting is different from verifying simulation results. To verify the netlist, a minimum number of components should be used, so that there is no confusion about which netlist line refers to which schematic instance. For ADS, the minimum number of components is one. A netlist can be created, even though there is no connectivity on the pins. Additionally, a netlist can be created in ADS, even if the schematic has not been saved.

A schematic for testing part 2301001

In A schematic for testing part 2301001, a schematic for testing a single ADS component is shown. Notice that the preferences were set so that the pin name and pin number are shown (see Recommended Schematic Preferences). Additionally, two wires have been drawn from the POS pin and NEG pin.

Wire labels have been added to these wires, naming the wire on the POS pin POS, and naming the wire on the NEG pin to NEG. This is done for a very specific reason. When ADS creates a netlist, it will assign arbitrary system net names to unnamed nodes. For example, if the POS wire label is not placed on the POS pin, the node name might be _net001. If the wires are not named, there will be no way to identify what the actual pin order was when a netlist is generated.

Similarly, in Schematic that represents part 2301001, the schematic that should represent the pat that is being tested has had wire labels added to the wires connected to the ports. This is so that the sub circuit definition line will use those names, and make pin order identification very simple. If the wires attached to the ports are not named, they will use system names like _net001.

Schematic that represents part 2301001

With the schematic created, you can now create a netlist. Open the Command Line window from the ADS Main window by selecting Options > Command Line . In the Command field of the command line window type de_netlist(); . Enter the command using the Enter key or click the Apply button to process the command. In a text editor, open the netlist.log file in your project directory. You should have a text editor displayed that looks similar to The netlist for the test schematic.

So you have a netlist to look at. How do you know it is correct? Unfortunately, the ADS netlist format was meant to be hidden. In order to allow the format to be changeable from release to release, a decision was made to document as little of the netlist format as possible. The descriptions on the netlist format are meant to be enough to allow you to judge whether a device that follows the exact specifications given in the prior seven chapters is netlisting properly. This is not going to be a comprehensive description of the ADS simulator netlist format.

The netlist format can be broken down into four basic elements, options, variables, instances, C Pre Processor definitions, models, and subcircuit definitions.

The netlist for the test schematic

The first line in the netlist will always be an option line, and will start with the keyword Options. Ignore that line - you won't ever change it. It is also possible to output more options, by placing an Options component. Again, for validating a netlist, the Options will not be important. Options never change the expected format of an instance, subcircuit, or variable.

Variables (and user defined functions) will have the format X=Y, where X is the variable or function name, and Y is the value. In the sample netlist, no variables have been defined, so there aren't any in the netlist. Variables will normally be added by placing a VAR component in a schematic. If you wish to see what a variable definition would look like, place a VAR in the schematic, and re-netlist it.

Models are auxiliary components that will define a special, built in subcircuit definition that is parameterized. Instances will reference the model statements. Models are provided for all active devices, as well as several passive devices. The keyword for a model is model , followed by the name of the model, followed by the particular model definition, followed by the parameters. For more information on models, consult the ADS documentation. In the example shown in The netlist for the test schematic, there are no model devices used.

Subcircuit definitions will have three lines associated to them. There is a designator for the start of the subcircuit; in ADS, the subcircuit designator is the keyword define . The format for the design line is:

define <subcircuit name> ( <port node 1> <port node 2> .... <port node n> )

If there are too many ports, the line can be continued by placing a backslash ( \ ) at the end of the line.

In The_netlist_for_the_test_schematic,_there_is_a_sub_circuit_definition,__define_bpl_rls_lib_capacitors_(POS_NEG)_._An_example_of_setting_up_this_particular_RF_schematic_was_shown_in_Creating an RF Schematic Circuit, and the setup for the device was shown in Setting up Component Families. As was noted in Component Simulation Settings, the capacitor device was set up so it would use "bpl_rls_lib_capacitors" as its schematic. Consulting the verification checklist, the first step is to make sure the correct sub circuit was output, and judging from the displayed results, it was.

The subcircuit definition is ended by having an "end" directive, followed by the subcircuit name. In The netlist for the test schematic, there is a line, "end bpl_rls_lib_capacitors". That designates the end of the subcircuit definition. All of the instance lines between the define statement and the end statement define the topology of the subcircuit.

One last line can show up for a subcircuit definition. The designator "parameters" indicates parameters that can be passed into the subcircuit. These parameters are then accessed as variables within the subcircuit. In The netlist for the test schematic, there is a parameter defined, PART_NO="2301001". This is important.

First, if an instance line using the bpl_rls_lib_capacitors subcircuit does not have a PART_NO parameter, it means that "2301001" will be used as the value for PART_NO anyplace that PART_NO is referenced in the subcircuit. Second, it defines that PART_NO is the only parameter that can be passed into the subcircuit bpl_rls_lib_capacitors. If parameters with names other than PART_NO are passed to the subcircuit, the ADS netlist parser will generate an error, and the simulation will not complete.

A pre-processor directive will be prefixed with a # character. In The netlist for the test schematic, there is one pre-processor directive, #uselib "ckt", "DAC". This is a pre-processor directive that is particular to ADS, and tells the simulator that the component "DAC" is actually a netlist fragment that should be automatically included by the simulator. The "ckt" designator specifies which library file contains the DAC component. The location of the file is then designated in a file, ADSlibconfig .

The ADS pre-processor is derived from CPP. It will obey pretty much any CPP directive. However, it is not recommended that CPP directives be used.
Most of what will show up in an ADS netlist will be instance lines. How do you know its an instance line? Basically, you know because it does not match any of the other designations that have been described already. The basic instance line format for ADS is as follows:

<device> : <instance name> <node 1> <node 2> ... <node n> <param 1> = <value>

The backslash ("\") character can be used to do line continuations. The semicolon character (";") is a comment character. All characters after a semicolon are comments, and ignored by the netlist flattener. Be very careful about using line continuations and semicolons. ADS does line continuations by concatenating the following line to the line with the backslash. Unlike Spice, it will not pass over comment lines. If a semicolon is encountered after a line continuation, everything after the semicolon is ignored.
The device is any subcircuit, model, or built in component supported by the ADS simulator.

The nodes are space delimited. Everything after the instance name is considered a node, until the first item with an equal character is encountered.
The parameters are also space delimited.

Certain special characters in ADS cannot be used in node names, instance names, or device names. If one of these characters is used, the name must be enclosed in double quotes or the simulator will generate an error.

In The netlist for the test schematic, there are a number of instance lines. Since the objective is to decide whether the device, capacitor_capacitor_2301001, netlisted properly, it makes sense to check that instance line.

To find the instance, search for the instance name C1 . There could be multiple C1 instances in the netlist, so it is important to realize that, capacitor_capacitor_2301001 is at the top level of hierarchy. The first C1 in The netlist for the test schematic falls between the define and end statements for bpl_rls_lib_capacitor. That is not the C1 for the capacitor_capacitor_2301001 device, because that device is not placed in the bpl_rls_lib_capacitor schematic. Searching again, there is another C1 instance, and it is the last line of the file (it won't always be the last line, it depends on the order things were done in, although in general you can look at the bottom of the file if you are verifying your circuit as described in this chapter).

Looking at the C1 line, the following can be determined:

bpl_rls_lib_capacitors:C1 POS NEG PART_NO="2301001"

The device being used by the instance is bpl_rls_lib_capacitors. That is the correct device.

The instance name is C1. The matches what was placed in the schematic, giving a high degree of confidence that the correct device is being verified.

The nodes for the device are POS and NEG. That means there are two pins for the device, which matches the number for the bpl_rls_lib_capacitors. The pin count is correct.

The expected pin order, based on what was set up in the Pin Attributes, was POS then NEG. In the ADS schematic, the pin POS had a node name of POS attached to it, so that its node name would be POS. The first node in the netlist is POS. This is correct. In the ADS schematic, the pin NEG had a node name of NEG attached to it, so that its node name would be NEG. The second node in the netlist is NEG. The pin order is outputting the proper pins in the order that was expected.

The schematic had two ports, POS and NEG. Port POS was set to be number 1, and had a wire label, POS, attached to it. In the define statement, the first port node is POS. This matches the instance setting, which also is supposed to be POS. Similarly, port NEG was set to be number 2, and had a wire label, NEG, attached to it. In the define statement for the subcircuit, the second node in the list is NEG, which is what was expected, and which matches the instance setting.

Note By setting wire labels that match the pin names and port names, see how simple it is to verify the pin orders!

The final check, the instance has one parameter, PART_NO. The subcircuit also has one parameter, PART_NO. Checking the schematic, the value of PART_NO is set to "2301001", and a value of "2301001" was output into the netlist. This matches what was expected.

The final analysis? This device is netlisting properly. What if this verification was not done? In other words, why not just place the component and run a simulation with it? The problem with doing that is that, if the simulation results don't match what you expect, you have to look and see whether the problem is coming from the device model, or if there is a netlisting mistake. By verifying the netlisting first, you have guaranteed that any simulation result mismatches are due to the device model.

Using this same template, you just need to verify all of the other components in the family. Once you are familiar with the netlist format, this is not that difficult, and you can place many components in a single netlist to increase the amount of devices that are being checked simultaneously.

Verifying Component Simulation Results

Verifying the netlisting is a very simple process. So is verifying the simulation results. Unfortunately, verifying simulation results, while being straightforward, will be very time consuming. Expect to spend at least one day for every component family that is translated into ADS. This time will go up depending on the complexity of the device model and the number of parts in the family.

Simulation verification should be done for every part that was transferred from Mentor Graphics to ADS. Every part should be placed into a schematic and simulated for every simulator that the part is expected to be used with (i.e. S-Parameter, Harmonic Balance, Circuit Envelope, Transient, etc.). Additionally, if the part has been set up to use optimization and/or statistics, at least one simulation should be done using optimization and/or statistics.

Given the above guidelines, and assuming that the transferred parts will be used with DC, S-Parameter, Harmonic Balance, and Transient simulations, the examples shown is this manual would require 4 parts times 4 simulations, plus 3 more simulations involving an optimization analysis, plus and 3 simulations involving statistics. This is 22 separate simulations for the example part family. Four parts per family is an exceedingly small number. As you can see, the verification will add up.

Added into this problem is, what do you verify against? For Mentor Graphics LMS parts, there are generally not Spice simulation results to compare against, because generally, the parts have not been set up to work with Spice. That leaves measured data, or eye-balling (if you're an experienced modeler).

The bottom line is, it will be up to the librarian to decide what will constitute an appropriate simulation verification. It is recommended that this process be taken very seriously, because if the simulation results are not accurate, there is no point in transferring the library from Mentor Graphics to ADS.

An Example of an S-Parameter Verification

To do a verification, it is necessary to create a simple schematic that will contain the device you want to verify. ADS contains several simulation templates, which can be used to generate a schematic that contains certain simulation elements in it. By using a template, you can create a new schematic that will require only that the part being tested be placed; everything else will already exist.

A test schematic to verify part 2301001

To create a schematic with a template, open a schematic window. Select the menu File > New Design . Type in the name of the new schematic, and then select one of the optional Schematic Design Templates. The schematic in A test schematic to verify part 2301001 used the template S_Params.

In A test schematic to verify part 2301001, the part capacitor_capacitor_2301001 was added, and then wired to the positive terminals of each Term. Just in case there is a problem, the nodes were also labeled POS and NEG, so it would be easier to debug the netlist if it was required.

With the schematic created, the simulation button is pressed. The simulation will run, and a dialog window will appear. This dialog, shown in, will contain error and warning messages that are encountered by the simulator. If there are any errors, or warnings, they should be corrected. This is especially true if the warnings are due to DC not converging. DC convergence issues will result in bad simulation results, even if the simulation does complete.

Simulator Dialog

In ADS 1.5 and beyond, the Data Display will also automatically open. The Data Display Server is used to view the data from a simulation. This is where the question of what you are measuring against becomes important. In the Data Display server, it is possible to view values both graphically, and as table data. If there is nothing to compare against, the data is somewhat meaningless. You may wish to do multiple simulations, comparing the results of the part against ideal components, but ideally, you should have some form of measured data to compare the simulation results against. Data Display of S(2,1) for the part 2301001 shows the decidedly non-ideal simulation characteristics that come from the model used by the 2301001 part based on all of the simulation setups that have been done in the prior chapters. Because the part had not real data to measure its performance against because it is a fake part, there's no way to tell whether this result is accurate or not. For the sake of argument, assume that it is.

The next step would be to run simulations using the same schematic setup, but using some of the other part numbers. It is very important to run at least one simulation for each part, because that will determine that the discrete data file had proper definitions for all of the Mentor Graphics parts that were transferred.

Data Display of S(2,1) for the part 2301001

Verifying Component Layout Representation

There are two goals of transferring Mentor Graphics Libraries into ADS. One is to use the ADS simulator. The other is to be able to generate layouts. For High Frequency board designs, layout is very critical, and it is important to be able to simultaneously develop the schematic design at the same time that the board layout is developed. This is primarily due to the fact that transmission lines, transmission line tees, and vias can have a large effect on circuit performance, and it is impossible to know how to model the transmission lines in the schematic without creating a layout.

ADS provides three ways of generating a layout. First, a layout can be developed directly, without using a schematic as a source for the layout. Mentor Graphics requires that an RF schematic region be created in order to use their layout tools, so this is not an option if designs will be translated from ADS to Mentor Graphics.
The other two options can be used simultaneously. One option is to manually place schematic objects into a layout. This can be a good idea when the Mentor Graphic footprints differ significantly from the orientation of the schematic symbols. The other option is to use an automatic layout placement, known in ADS as design synchronization. The automatic layout placement will try to place all of the devices into a layout. This does not always generate a realistic layout, so it is important to realize that certain designs will require manual placement from the schematic, or will require a combination of manual placement and design synchronization.

Verifying Placement of Components from Schematic to Layout

A new design should be created for this process. The key things that must be checked are that the symbol pins for the Mentor Graphics part match the layout pins of the footprint, and that the proper footprint was placed. It is assumed that the geometry has actually imported correctly, although that should be checked as well if there is any doubt.
Place a single instance of the device that is to be checked. Make sure that the schematic preferences have been set so that the symbol pin names and the symbol pin numbers are displayed. Choose the option Layout > Place Components from Schem to Layout . A layout window will be opened automatically. The components that have not been placed from the schematic will be highlighted. Select the component you want to place (in this case, select the only component in the schematic). If activate the layout window, you should see an outline of the device that is being placed. Click in the layout to place the device.

Next, check the value of the GEOM parameter by double clicking on the layout device that was just placed. The value of GEOM should be identical to the name of the footprint. Open the Library Browser and select the footprint. Place one copy of the footprint in the design alongside the footprint that was placed from the LMS component. The footprints should be identical.

You should make sure to have the layout preferences set up to show the pin number and pin name. If this is true, you will also be able to see the name and pin number of the macro artwork that came from the component placed in the schematic, and the raw footprint that was placed manually. Both the pin names and pin numbers should be identical.
If the footprints are the same and the pin names and numbers are the same, then the LMS component has been set up for layout correctly. An example of this is shown in Sample layout to verify schematic to layout placement.

Sample layout to verify schematic to layout placement

Verifying Design Synchronization

Verifying design synchronization is not much different from verifying part placement. For design synchronization, it is recommended that multiple parts be placed as opposed to a single part.

Take the design that was used with Verifying Placement of Components from Schematic to Layout, and add two mlin components to it. Go back to your layout window and choose the menu option Select > Select All and then delete the components. Now, go back to the schematic window and select the menu Layout > Generate/Update layout. The Generate/Update Layout dialog will come up. Because everything was just deleted from the layout, everything will get placed. There is nothing that needs to be changed on the dialog. Just hit the OK button.

Check to make sure that the transmission line instances have been attached to the proper footprint pins. In Layout using design synchronization, TL1 is attached to the pin POS and TL2 is attached to the pin NEG. This is what was set up in the schematic shown in Schematic used for design synchronization so the design synchronization from schematic to layout is accurate.

Layout using design synchronization

To be very thorough, you should also synchronize the schematic from the layout. This can cause problems with the schematic topology, but it is a good way to update the values from transmission lines. Change the values on TL1 and TL2 for width, as an example. To synchronize to the schematic, choose the menu Schematic > Generate/Update schematic. The Generate/Update Schematic dialog will come up. Again, nothing should need to be changed from the default. Just click the OK button. The schematic values should get updated and the Mentor Part should be placed properly. If this works and the schematic to layout synchronization works, you are good to go.

Schematic used for design synchronization