ISIS APPLICATION NOTE

ISIS SDF Netlist 3.0 Technical Information

1. IntroductionSDF is Labcenter's native netlist format. It was designed with the following requirements in mind:

q The netlist file should contain all the textual information stored in the schematic. This includes notjust part name and connectivity but also part properties, net properties and pin types. It is thuspossible to do all manner of database type processing on your designs by means of analysingSDF files.

q The format should be compact. Some netlist formats are mind bogglingly verbose - the EDIFformat as defined by an international standards committee) has failed to catch on because evensimple designs can result in files of over 1Mb!

q The format should be easy to parse. In fact, SDF files can be read with BASIC programs so youdon't have to be a C wizard to make use of SDF.

The rest of this document describes the SDF file format - if you don't understand what follows it is unlikelythat you have sufficient programming experience to work with SDF files.

2. Basic File StructureAn SDF file is divided into several sections or 'blocks', as follows:

q A header block.q A PROPERTIES block.q A MAPPINGS block.q A MODELDEFS block.q Zero or more SCRIPT blocks.q A PARTLIST block.q A NETLIST block.

2.1 Block StructureEach section or block is identified by a single line which begins with the block name immediatelypreceded by an asterisk ('*') character.

The header and SCRIPT blocks are subtlety different to the others - the header because it is simply just afile header at the top of the netlist, and the SCRIPT block as it is simply a direct dump of similarly-namedtext script objects in ISIS. The structure and format of these blocks is discussed fully in a subsequentsection.

For the remaining blocks, the block name is followed by a comma (',') character and an integer count ofthe number of additional lines in the block that follow it. Each block is line oriented (i.e. one item orrecord per line) and comma separated. Fields likely to contain commas are enclosed in double quotes;no field may contain the double quote character.

3. The HEADER BlockThe header block is simply a block of text that appears at the top of the SDF file and gives details of thedesign from which the netlist was extracted An example header block is shown below:

ISIS SCHEMATIC DESCRIPTION FORMAT 3.0=====================================Design: C:\PROTEUS\SAMPLES\SOMEFILE.DSNDoc. no.: <NONE>Revision: <NONE>Author: <NONE>Created: 10-Jun-94Modified: 12-Jun-94

The first line identifies that the file contains an SDF version 3.0 netlist; the remaining lines containinformation extracted from the Design Properties dialogue form in ISIS. Each field starts exactly 10characters in from the left.

MDF model files created for use with the LISA simulators have a slightly different header.

LISA MODEL DESCRIPTION FORMAT 3.0

In other respects they are identical to normal SDF files.

4. The PROPERTIES BlockThe PROPERTIES block contains global design properties assigned through *DEFINE scripts in the ISISdesign and possibly through other mechanisms (e.g. for netlists generated for use with either of the LISAsimulators, simulation control properties assigned of the Edit...Graph dialogue forms are placed in thePROPERTIES block). There is only one PROPERTIES block in an SDF 3.0 netlist file.

For example, an ISIS design containing the text script:

*DEFINEBETA=100MIN_STEPS=100

results in a netlist containing the following PROPERTIES block:

*PROPERTIES,2BETA=100MIN_STEPS=100

The first line indicates that this is a PROPERTIES block and contains two records. Each record is thenspecified on its own line in the form:

<pname>=<pvalue>

where:

<pname> is the name of the property being assigned.<pvalue> is the value being assigned to it.

Note that the names of properties being assigned and the values they are assigned is dependent on theend use of the netlist.

5. The MAPPINGS BlockFor a normal SDF 3.0 netlist, the MAPPINGS block is always empty (that is, the record count in the*MAPPINGS line is always zero). For MDF linkable netlists (i.e. model files) generated for use with theLabcenter LISA simulators, the MAPPINGS block contains the MAP ON mappings from a MAP ON script inthe ISIS design.

The MAPPINGS block is used by the Labcenter LISA simulators to conditionally define a set of sheetproperties depending on the value of another (second) sheet property. At present, the netlist generator inISIS only generates a MAPPINGS block from a MAP ON script where this second property is the VALUEproperty (this is usually the value of the component being modelled) and hence this parameter is notexplicitly present in the netlist.

For example, an ISIS design containing the text script:

*MAP ON VALUE7407 : TDLHDQ=6n, TDHLDQ=20n, OCOPS=Q7417 : TDLHDQ=6n, TDHLDQ=20n, OCOPS=Q74HC07 : TDLHDQ=7n, TDHLDQ=7n, OCOPS=Q

results in a model netlist containing the following MAPPINGS block:

*MAPPINGS,37407 : TDLHDQ=6n, TDHLDQ=20n, OCOPS=Q7417 : TDLHDQ=6n, TDHLDQ=20n, OCOPS=Q74HC07 : TDLHDQ=7n, TDHLDQ=7n, OCOPS=Q

The first line indicates this is a MAPPINGS block and is followed by three records. Each record is then ofthe form:

<value> : <pname=pvalue>, ..., <pname=pvalue>

where:

<value> is the text to be matched against the sheet VALUE property.<pname> is the name of a property to be assigned if a match occurs.<pvalue> is the value to be assigned to the named property if a match occurs.

Thus, in the above example, if value of the sheet VALUE property is 74HC17, then the sheet propertiesTDLHDQ and TDHLDQ are assigned the value 7n and the property OCOPS is assigned the value Q.

For more information in MAP ON scripts, consult section 6.4.7 in the ISIS manual and the DSIM ModellingTutorial (section 2.5.4 in particular) in the LISA manual.

6. The MODELDEFS BlockFor a normal SDF 3.0 netlist, the MODELDEFS block is always empty (that is, the record count in the*MODELDEFS line is always zero). For MDF linkable netlists (i.e. model files) generated for use with theLabcenter LISA simulators, the MODELDEFS block contains the model definititions from the MODELSscript(s) in the ISIS design.

The MODELDEFS block is used by the LISA simulators (currently only the analogue simulator) to allowseveral property assignments to be grouped under a single name. A component can then assign all theproperties in a MODELDEFS record by assigning the MODELDEFS record name to its MODEL property.

For example, an ISIS design containing the text script:

*MODELS741_NPN : BETAF=80,ISAT=1E-14,RB=100,VAF=50,TAUF=0.3E-9,TAUR=6E-9741_PNP : BETAF=10,ISAT=1E-14,RB=20, VAF=50,TAUF=1E-9, TAUR=20E-9

results in a netlist containing the MODELDEFS block:

*MODELDEFS,2741_NPN : BETAF=80,ISAT=1E-14,RB=100,VAF=50,TAUF=0.3E-9,TAUR=6E-9741_PNP : BETAF=10,ISAT=1E-14,RB=20, VAF=50,TAUF=1E-9, TAUR=20E-9

The first line indicates this is a MODELDEFS block and is followed by two records. Each record is then ofthe form:

<name> : <pname=pvalue>, ..., <pname=pvalue>

where:

<name> is the name of the record.<pname> is the name of a property to be assigned.<pvalue> is the value to be assigned to the named property.

Thus, in the above example, if a component in the netlist contains the property assignment:

MODEL=741_NPN

this is the same as it containing the multiple assignments:

BETAF=80,ISAT=1E-14,RB=100,VAF=50,TAUF=0.3E-9,TAUR=6E-9

For more information in MODELS scripts, consult section 6.4.8 in the ISIS manual.

7. The SCRIPT BlocksAn SDF 3.0 netlist may contain zero or more SCRIPT blocks. Each SCRIPT block is a direct export froman a script in the ISIS design, the first line of which begins *SCRIPT and in which the last line begins*ENDSCRIPT. All characters after the leading *SCRIPT and up to and including the characters on theline beginning *ENDSCRIPT are placed in the netlist.

For example, an ISIS design containing the text script:

*SCRIPT A_SCRIPT 1234This is the first line.This is the second.*ENDSCRIPT

results in a SDF 3.0 netlist containing the *SCRIPT block:

*SCRIPT A_SCRIPT 1234This is the first line.This is the second.*ENDSCRIPT

Note that, unlike other netlist blocks, *SCRIPT blocks do not indicate the number of lines in the block. Ifyou are parsing the netlist, you must parse until the *ENDSCRIPT line is reached.

8. The PARTSLIST BlockThe PARTSLIST block contains a complete list of all components or parts in the ISIS design togetherwith their library name, value, and user-specified component properties (other system properties, such asdevice properties are not listed).

An extract from a PARTSLIST block is shown below:

*PARTLIST,44C1,CAPACITOR,1n,PRIMITIVE=PASSIVEC2,CAPACITOR,10n,PRIMITIVE=PASSIVED4,DIODE,,BV=2.55,IBV=6.3m,PRIMITIVE=ACTIVEJ1,CONN H2,OUTPUT,PRIMITIVE=NULLJ2,CONN H4,POWER,PRIMITIVE=NULLR1,RESISTOR,390,PRIMITIVE=PASSIVER2,RESISTOR,6k8,PRIMITIVE=PASSIVER3,RESISTOR,9k1,PRIMITIVE=PASSIVE......U1,74LS161,74LS161,MODFILE=74XX161.MDFU2,74LS161,74LS161,MODFILE=74XX161.MDFU3,MEMORY_4_4,MAIN MEMORY,FILE="DATA.DAT,BINARY",PRIMITIVE=DIGITAL

The first line identifies the PARTSLIST block and details the number of records in it. The format of eachrecord is then:

<ref>,<library>,<value>,<pname=pvalue>,...< pname=pvalue>

where:

<ref> is the component reference.<library> is the library device.<value> is the part value.<pname> is the name of a component property.<pvalue> is the value assigned to the named property.

For example, the record:

D4,DIODE,,BV=2.55,IBV=6.3m,PRIMITIVE=ACTIVE

indicates a component with the reference D4 based on the library device DIODE and which has a blankvalue. The component has three properties, BV, IBV and PRIMITIVE which have been assigned thevalues 2.55, 6.3m, and ACTIVE respectively.

As a further example, the record:

U3,MEMORY_4_4,MAIN MEMORY,FILE="DATA.DAT,BINARY",PRIMITIVE=DIGITAL

indicates a component with reference U3 based on the library device MEMORY_4_4 with the value MAINMEMORY. The component has two properties, FILE and PRIMITIVE, the former assigned the value

"DATA.DAT,BINARY" and the latter the value DIGITAL. Note how the value assigned to the FILEproperty has been enclosed in double quotes by the netlist generator (the is no need for the user to placequotes inside ISIS) as the value itself contains a comma which might otherwise be confused as thedelimiter before the next property assignment.

8. The NETLIST BlockAn extract from a netlist block is shown below:

*NETLIST,330#00000,1U1,TS,28

#00003,2U1,IP,16R4,PS,2...#00215,4Q12,PS,CD6,PS,-U38,IP,8C38,PS,2

#00216,2C38,PS,1U38,IP,5A15,3U1,TS,5U7,IP,2U8,IP,1

$MREQ$,1U1,TS,19

$M1$,2U9,IP,8U1,TS,27

+12,2,STRAT=POWERU8,PP,14U7,PP,14

As with the other netlist blocks, the first line identifies the block and gives the number of nets in thenetlist.

Each net starts with a line of the form:

<net_name>,<num_nets>[,<net_property>=<value> ... ]

Net names beginning with a # are created automatically by ISIS to identify otherwise un-named nets. Adollar character ($) is used to "bracket" inversion bars so a net appearing as RD/WR in the ISIS designappears as RD/$WR$ in the netlist.

Where net property wire labels or sheet-global net properties have been used on the schematic, thesewill appear as additional parameters following the net name and size. The +12 net shows an example ofthis where the STRAT property will be recognised by ARES.

Following the net-name record come an appropriate number of pin, label or terminal records of the form:

<part_ref>,<pin_type>,<pin_id> or<label_ref>,LBL or<term_ref>,<term_type>

where:

<part_ref> is a component reference matching a component listed in the PARTLIST block.<pin_type> is one of the electrical type of the pin and is one of the following:

PS - Passive GT - Generic Terminal

IP - Input IT - Input Terminal

OP - Output OT - Output Terminal

IO - Input/Output BT - Bidirectional Terminal

TS - Tri-State PR - Power Rail

OC - Open Collector

OE - Open Emitter

PP - Power Pin<label_ref> is the name of a net label.<term_ref> is the name of a terminal.<term_type> is the electrical type of terminal as given in the second column of the table the

<pin_type> above.<pin_id> is the name of the pin (for a logical netlist) or the pin number (for a physical

netlist).

Each group of pin records is followed by a single blank line and then the start of the next net.

It will be noted that not all the records in each net relate to physical pins. The records for Labels andLogical Terminals serve mainly to carry additional net names that have been used for the net. These non-physical records can be identified either by their electrical type or by the fact that they have two ratherthan three fields - there is no pin_id.

[END OF DOCUMENT]

ARES III REGION FILE FORMAT

1. INTRODUCTION

ARES III normally saves PCB layouts in a compact binary format which is subject tocontinual evolution and re-definition as features are added to the products. The LYTformat is also quite impenetrable to the casual adventurous user, even if he hasprogramming know how and is armed with a binary file editor.

From version II of our third generation products, we have implemented a secondaryfiling system which uses an ASCII file format which will be much less subject tomodification. This has been done for several reasons:

• Firstly, it makes much more feasible the creation of user or 3rd party boardprocessing utilities such as Gerber or DXF import converters.

• Secondly, it provides the experienced user with a way to perform obscureediting operations since the file can be loaded into a text editor and sectionscut and pasted as required.

• Thirdly, it is much easier to recover information from a corrupted ASCII filethan from a corrupted binary file - in a sense, the REG file format is a usefuldebugging aid for ourselves!

REG files are loaded and saved with the File-Import and File-Export commands. Itfollows that several REG files can be assembled with the layout editor. Also, anysub-group of objects in a layout can be tagged and exported should one wish tomanipulate just a sub-section of the design.

2. BASIC FILE STRUCTURE

REG files are identified by the string "ARES REGION FILE" on the first line.

Subsequent blocks are introduced with designators such as

*OBJECTS

and where appropriate, block ends are marked with lines such as

*END_OBJECTS

The file format is designed so that it can be read fairly easily with the fscanf()function in C or C++.

3. HEADER BLOCK

An example HEADER block is shown below:

*HEADERVERSION 300 300UNITS 10nmAREA 5350 4350 6650 5450

The VERSION numbers are the versions of ARES and of the file format itselfmultiplied by 100, so 277 refers to ARES version 2.77.

The UNITS record indicates the units of all subsequent dimensions in the region file.Currently, units will either be 1th or 10nm. Note that all dimensions must be integers,so it is no use specifying UNITS 1in and then having floating point numbers all overthe place.

The AREA numbers represent the extent of the region and are in thou. Thecoordinate origin is at the top left; x increases to the right and y increases downward.

The three entries in the HEADER block are mandatory and must come in the ordergiven above.

4. OBJECTS BLOCK

The OBJECTS block defines any Components, Pads, Polygonal Zones or 2DGraphics used in the layout. Each type of object uses a different syntax as describedin the following sections.

N.B. The objects block is not mandatory if there are no objects.

4.1 Component

The syntax for the first line of a component record is

COMPONENT <ref_x> <ref_y> <rot> <mir>

Note that there is no layer information. Instead, the mirror value determines thelayer.

<ref_x> and <ref_y> define coords of the anchor which is normally pin 1, or at anyrate the first pin that was placed when the package was defined.

<rot> is the rotation in degrees clockwise about the reference. Currently only 0, 90,180, 270 rotations are allowed.

<mir> defines both refleciton and layer. Bit 0 is mirror x, bit 1 is mirror y so valuescan be 0,1,2 or 3. Values 1,2 imply solder side mounting.

The next two lines define the part id and value labels. The syntax for a label is:

"<string>" <ref_x> <ref_y> <rot> <mir> <char_width> <char_height> <tjust>

<ref_x> <ref_y> is the centre of the label.

<string> can be up to 15 chars max.

<ref_x> and <ref_y> are absolute coords - i.e. NOT relative to the componentorigin.

<rot> and <mir> are as for components.

<tjust> is as follows:

Bit 0 Right justifyBit 1 Left justifyBit 2 Align topBit 4 Align middle

The next line gives the package (i.e. library part) and associated information:

"<string>" <ncprims> <nsprims> <npins>

<string> is the package name enclosed in quotes.

The <type> field is removed in ARES III - ARES can now recognize duplicatedpackages.

<ncprims> is the number of primitives on the component silk screen. <nsprims> isthe number of primitives on the solder silk screen. <npins> is the number of pins.

For each primitive is a GRAPHIC record as described in section 4.4 componentside first, then solder side according to the ncprims and nsprims numbers. Notethat where the component has been mirrored, the component silk screen primitiveswill come from the solder silk screen symbol of the original library package and viceversa. Similarly, the coordinates of the all primitives refer to their actual positionson the board, not their positions relative to the library part origin.

Then for each pad there is a line of the form

"<pad_style>" <lyr> <ref_x> <ref_y> <rot> <mir> "<num>"

In ARES III, layers are named, and <lyr> will generally be TOP, BOT or ALL.

Once again, <ref_x> and <ref_y> are absolute coords - i.e. NOT relative to thecomponent origin. <num> is the pin number - max 3 characters in ARES II, 5characters in ARES III. Non-numeric characters are permitted.

4.2 Pad

In ARES, a distinction is made between a pad and a via in that a pad may carry a pinnumber and is normally used in the construction of new packages though pads mayalso be used for mounting holes etc.

The format for a PAD record is

PAD "<num>" "<pad_style>" lyr <ref_x> <ref_y> <rot> <mir>

"<num>" can be up to 5 chars max.

4.3 Zone

A zone is a polygonal area of copper. The format for a ZONE record is

ZONE <lyr> <num_vertices> <vt1_x> <vt1_y> ... <vtn_x> <vtn_y>

This represents a zone boundary. There may be some futher changes in this area.

4.4 2D Graphics

ARES supports a range of 2D drawing primitives which can be used either in theconstruction of package silk screen outlines or for creating graphics/markings etc onthe layout.

The format of a GRAPHIC record is

GRAPHIC <lyr> <primitive_type> <primtive_data>

<primitive_type> is one of

LINEBOXCIRCLEARCBEZIERTEXTPOLYLINESYMBOL

The format of <primitive_data> for each type is described in the following sections.

4.4.1 Line

The format of a LINE primitive is

LINE 4 <x1> <y1> <x2> <y2>

4.4.2 Box

The format of a BOX primitive is

BOX 4 <x1> <y1> <x2> <y2>

4.4.3 Circle

The format of a CIRCLE primitive is

CIRCLE 3 <x> <y> <rad>

4.4.4 Arc

The format of an ARC primitive is

ARC 8 <x> <y> <x1> <y1> <x2> <y2> <rad_a> <rad_b>

<x1> ... <y2> define a clip box which restrict the part of the eliptic quadrant that isdrawn.

4.4.5 Bezier

BEZIER 8 <x1> <y1> ... <x4> <y4>

The 4 control points define a standard Bezier cubic curve.

4.4.6 Text

The format of a TEXT primitive is

TEXT <x> <y> <rot> <mir> <char_width> <char_height> <tjust> "<string>"

<x> <y> is at the bottom left of normally oriented text.

<tjust> is as for labels.

<string> can be up to 40 chars max.

4.4.7 Polyline

The format of a polyline is

POLYLINE <n> <x1> <y1> ... <xn> <yn>

<n> is the number of vertices. Max 256.

4.4.8 Symbol

ARES provides a symbol library facility whereby groups of primitives can be madeinto single "symbol primitives" and stored in a library. The format of a SYMBOLprimitive is

SYMBOL <x> <y> <rot> <mir> "<name>" <n>

<x> <y> <rot> <mir> orient the symbol.

<n> is the number of constituent primitives which follow on succeeding lines.

4. VIAS BLOCK

All vias in the layout are listed one per line in this block. The format of a VIA recordis

"<pad_style>" <lyr> <lyr> <ref_x> <ref_y> <rot> <mir>

The vias block is not mandatory.

5. LAYER BLOCKS

ARES supports 16 routing layers named TOP,BOT, I1..I14.

Each layer is introduced with a line of the form

*LAYER <lyr>

The import module can cope with the layers in any order, or with several blocks forthe same layer, or with no layer blocks at all. Each RECORD, again one per line hasthe form

<style> <type> <num_segs> <seg1_x> <seg1_y> ... <segn_x> <segn_y>

<type> is S for signal and P for power plane and is more or less obsolete in ARESIII.

N.B. There is one more coord pair than the number of segments.