• Introduction
• Applications
• Input
• Outputs
    Ansoft ANF
    Optimal XFL
    OEA Netan
Running NETEX
• command syntax
Proximity Nets
• What is a Proximity Net?
• Why Would I Need It?
• How it Works
When Net Names Collide
• Different Net Names
   on Same Conductor

• Separate Conductors
   with Same Net Name

• Log file reporting
Layers and Datatypes
• What is a GDSII Datatype?
• How to Separate Entities
   by Datatype
The Technology File
• Conductor Stackup
• Assigning Net and Node
   Names using Text Layers

• Conductor Name Mapping
The Configuration File
• Data Units
• Expansion
• Output Directory
• Temporary Directory
• Extraction Directives
     • All
     • Bycoordinate
     • ByName
Saving Intermediate Results
• The GDSII file with all nets
• How Last State is Saved

Using netexmgr

NETEX is executed from a command line using a control program called netexmgr which deals with proper calling of the netex engine and its associated helper programs.

Command Line Syntax

The command line syntax for netexmgr is:




         -t <tech_file_name> 
           -c <cfg_file_name> 

options include:

 -window:xmin,ymin,xmax,ymax    clip to window

 -proximity[:<mode>]     Compute proximity nets.
                          0  no proximity
                          1  use proximity engine.
                          2  extractors generate
                             respective proximity

   -cpl                      generate coupling
                             (.cpl) file.

   -manh                     assume input data 
                             is Manhattan

   -testpt                   run in test point 

   -frac                     fracture output in
                             trapezoidal mode

   -frac:<stepvalue>         fracture output in
                             orthogonal mode

   -scale:<scalevalue>       scale fractured 

   -oeafmt                   Generate OEA's
                             NETAN format (ascii)

   -outputformat:<STR>       GDSII | ANF | 
                             NETAN | XFL                

   -trace                    Run in net trace mode
                             (requires a cfg file w.
                             coordinate or label
                             extraction directive)

   -nodetrace                Run in node trace mode
                             (requires a cfg file w.
                             coordinate or label
                             extraction directive)

   -startorder:<order_num>   Specifies the start
                             order layer number;
                             overrides cfg file

   -droporder:<order_num>    Specifies the drop order
                             layer number; overrides
                             cfg file directive.

   -tlib <tlib_file>         Format NETAN output
                             with <tlib_file>

   -merge_nets               Don't merge physically
                             separated nets with 
                             same label.

   -add_net_text             Add text labels to 
                             named nets

   -flag_multi_netnm         Do not rename nets w.
                             multiple net names

   -thrnum:<thread_num>      Use thread_num number
                             of CPU's

   -engargs <arg_list>       Appends <arg_list> to
                             netex engine command 

   -xterm                    run in an xterm

   -memstats                 include memory usage
                             statistics in log file.

Command Line Arguments Details


the name of the input gdsii file. You should include the full path information unless the file is already located in your current working directory.



the name of the structure (cell) you wish to process. In most cases (but not all) this is the top level structure in the GDSII file.



the name of the technology file that defines the stackup (and other items). You should include the full path info unless the file is located in the current working directory. Note that a tech file is mandatory and the netex cannot run without one.

     -t   /home/gdsii/testcase/


the name of the configuration file used by netex. Include the full path name if needed. This file is optional; netex will run without it. However if you wish to define selected nets and coupling extraction then this file should be present.

   -c   /home/gdsii/testcase/clock_fast.cfg

Command Line Options


clip to window - use this option if you want to process a only a limited region of the GDSII file. You must specify the window coordinates in the order: LLx,LLy,URx,URy. Note that the window data is clipped first; then nets are built. Any nets that would be connected outside the window are not going to be connected.

    -window: -3000,-2300,1000,1200


tells NETEX to extract all conductors within the coupling distance or range of influence of the nets you have selected for extraction. Note that this is only needed for doing parasitic extraction - otherwise the extra computations are quite intensive. There are three "modes"

 -proximity:0 - turns off proximity calculation
 -proximity:1 - normal proximity calculation
 -proximity:2 - proximity net generated after the netex operation


tells NETEX to produce an ascii file that lists all of the nets that "couple" to the selected nets. This output is only available if -proximity is used.


tells NETEX that the input data is Manhattan. This allows it to use faster and more efficient algorithms than if the data is all angle.


tells NETEX that you will be specifying nets by coordinate (see the configuration file) and that you do not need it to compute all nets - just those specified by the coordinates in your EXTRACT statement.


this option tells NETEX to "fracture" the output into trapezoids (top/bottom are parallel). Originally requested by OEA but never used.


this option tells NETEX to "fracture" the output into rectangles. the "stepsize" parameter is the height of the shortest rectangle to be used when approximating data that is non-manhattan. Essentially the output polygons are "sliced" along the X-axis into rectangles. (for OEA NETAN output)


scales the fractured output per this value. Default = 1. It is not clear what use such scaling might be put to - requested by OEA.


produce ASCII output in OEA's format. This also requires that the -frac or -frac:stepsize option be used. Of use to those running OEA's NETAN software.


directs NETEX which type of output to produce: GDSII (default), Ansoft's ANF, OEA's NETAN and Optimal's XFL.


trace mode ...


node trace mode is more efficient when extracting one or a few small nets out of a large design. Rather than find all nets first and then pull out the desired ones, this mode subdivides the layout into small windows and starts tracing at the user provided seed point. At the boundary of each window it creates a marker which is used to launch net traces in the butting windows. This process is repeated until the net is completely traced out.


sometimes when doing the net building the IC designer chooses not to use all of the metal/poly layers defined in the technology file. For example, you might only wish to build nets from the top level METAL6 down to and including METAL3 but to stop at METAL2. The designer could modify his technology file but in general it is best to leave a technology file constant. Instead use the STARTORDER and specify the stackup position (not GDSII layer number) to start at. See technology file ...

Normally this directive would be located in the NETEX configuration file but if it is present as a command line argument, the command line value overrides the value found in the config file.


drop order is similar to start order with the exception that NETEX process all of the technology file layers to build the nets and then drops data on stackup layers below the drop order value. Why? Startorder uses less compute energy but some conductors might only be connected on layers below the STARTORDER value and NETEX would return them as not connected. So Droporder has NETEX compute all the way down and then simply "drop" any conductors in the filtered layers.

Normally this directive would be located in the NETEX configuration file but if it is present as a command line argument, the command line value overrides the value found in the config file.


Assume the user has defined one or more text layers to label nets. It happens that two nets with a common net label don't physically connect. How should NETEX treat these two nets?

If -merge_nets is not used, NETEX assumes the labels are correct and outputs both conductors on the same net. NETEX reports in the log file that two physically separated nets share the same name.

If -merge_nets is present, NETEX creates separate outputs for each net. The first net is labeled with the assigned name. The second is and subsequent have _DUP1, _DUP2, _DUP3 ... appended to net name. The log report is the same.

This option helps a user identify geometrically where the commonly labeled "pieces" of the net are located; it has been found helpful in identifying floating conductors that are labeled as a member of a net, but which don't really connect to the net.


Assume the user has defined one or more text layers to label nets. Normally in the output GDSII data, no text appears. Each structure in the output file is named based on the net label.

If add_net_text present on the command line, NETEX will take any text strings it used to identify nets and output them along with the net geometries.

The text in the output will have the same insertion point and the same text string but other text parameters such as mirroring, rotation, reference location and such are not passed to the output.

This option has been found useful for both documentation purposes (when plotting or viewing the output from NETEX) and for tracking down possible text labeling errors.


tells NETEX to run in an xterm window.

ARTWORK CONVERSION SOFTWARE, INC.                  Company Profile
417 Ingalls St.,     Santa Cruz, CA 95060         Tel (831) 426-6163     Fax 426-2824               email: