Proteus Isis Application Note (english)

ISIS APPLICATION NOTE ISIS SDF Netlist 3.0 Technical Information 1. Introduction SDF 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 not just part name and connectivity but also part properties, net properties and pin types. It is thus possible to do all manner of database type processing on your designs by means of analysing SDF files.

q

The format should be compact. Some netlist formats are mind bogglingly verbose - the EDIF format as defined by an international standards committee) has failed to catch on because even simple 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 you don'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 unlikely that you have sufficient programming experience to work with SDF files.

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

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

2.1 Block Structure Each section or block is identified by a single line which begins with the block name immediately preceded by an asterisk ('*') character. The header and SCRIPT blocks are subtlety different to the others - the header because it is simply just a file header at the top of the netlist, and the SCRIPT block as it is simply a direct dump of similarly-named text script objects in ISIS. The structure and format of these blocks is discussed fully in a subsequent section. For the remaining blocks, the block name is followed by a comma (',') character and an integer count of the number of additional lines in the block that follow it. Each block is line oriented (i.e. one item or record 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 Block The header block is simply a block of text that appears at the top of the SDF file and gives details of the design from which the netlist was extracted An example header block is shown below: ISIS SCHEMATIC DESCRIPTION FORMAT 3.0 ===================================== Design: C:\PROTEUS\SAMPLES\SOMEFILE.DSN Doc. no.: Revision: Author: Created: 10-Jun-94 Modified: 12-Jun-94

The first line identifies that the file contains an SDF version 3.0 netlist; the remaining lines contain information extracted from the Design Properties dialogue form in ISIS. Each field starts exactly 10 characters 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 Block The PROPERTIES block contains global design properties assigned through *DEFINE scripts in the ISIS design and possibly through other mechanisms (e.g. for netlists generated for use with either of the LISA simulators, simulation control properties assigned of the Edit...Graph dialogue forms are placed in the PROPERTIES block). There is only one PROPERTIES block in an SDF 3.0 netlist file. For example, an ISIS design containing the text script: *DEFINE BETA=100 MIN_STEPS=100 results in a netlist containing the following PROPERTIES block: *PROPERTIES,2 BETA=100 MIN_STEPS=100 The first line indicates that this is a PROPERTIES block and contains two records. Each record is then specified on its own line in the form: = where:



is the name of the property being assigned. is the value being assigned to it.

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

5. The MAPPINGS Block For 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 the Labcenter LISA simulators, the MAPPINGS block contains the MAP ON mappings from a MAP ON script in the ISIS design. The MAPPINGS block is used by the Labcenter LISA simulators to conditionally define a set of sheet properties depending on the value of another (second) sheet property. At present, the netlist generator in ISIS only generates a MAPPINGS block from a MAP ON script where this second property is the VALUE property (this is usually the value of the component being modelled) and hence this parameter is not explicitly present in the netlist. For example, an ISIS design containing the text script: *MAP ON VALUE 7407 : TDLHDQ=6n, TDHLDQ=20n, OCOPS=Q 7417 : TDLHDQ=6n, TDHLDQ=20n, OCOPS=Q 74HC07 : TDLHDQ=7n, TDHLDQ=7n, OCOPS=Q results in a model netlist containing the following MAPPINGS block: *MAPPINGS,3 7407 : TDLHDQ=6n, TDHLDQ=20n, OCOPS=Q 7417 : TDLHDQ=6n, TDHLDQ=20n, OCOPS=Q 74HC07 : 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 of the form: : , ..., < pname=pvalue> where:



is the text to be matched against the sheet VALUE property. is the name of a property to be assigned if a match occurs. 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 properties TDLHDQ 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 Modelling Tutorial (section 2.5.4 in particular) in the LISA manual.

6. The MODELDEFS Block For 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 the Labcenter LISA simulators, the MODELDEFS block contains the model definititions from the MODELS script(s) in the ISIS design. The MODELDEFS block is used by the LISA simulators (currently only the analogue simulator) to allow several property assignments to be grouped under a single name. A component can then assign all the properties in a MODELDEFS record by assigning the MODELDEFS record name to its MODEL property. For example, an ISIS design containing the text script: *MODELS 741_NPN : BETAF=80,ISAT=1E-14,RB=100,VAF=50,TAUF=0.3E-9,TAUR=6E-9 741_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,2 741_NPN : BETAF=80,ISAT=1E-14,RB=100,VAF=50,TAUF=0.3E-9,TAUR=6E-9 741_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 of the form: : , ..., < pname=pvalue> where:

is the name of the record. is the name of a property to be assigned. 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 Blocks An SDF 3.0 netlist may contain zero or more SCRIPT blocks. Each SCRIPT block is a direct export from an 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 the line beginning *ENDSCRIPT are placed in the netlist.

For example, an ISIS design containing the text script: *SCRIPT A_SCRIPT 1234 This is the first line. This is the second. *ENDSCRIPT results in a SDF 3.0 netlist containing the *SCRIPT block: *SCRIPT A_SCRIPT 1234 This 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. If you are parsing the netlist, you must parse until the *ENDSCRIPT line is reached.

8. The PARTSLIST Block The PARTSLIST block contains a complete list of all components or parts in the ISIS design together with their library name, value, and user-specified component properties (other system properties, such as device properties are not listed). An extract from a PARTSLIST block is shown below: *PARTLIST,44 C1,CAPACITOR,1n,PRIMITIVE=PASSIVE C2,CAPACITOR,10n,PRIMITIVE=PASSIVE D4,DIODE,,BV=2.55,IBV=6.3m,PRIMITIVE=ACTIVE J1,CONN H2,OUTPUT,PRIMITIVE=NULL J2,CONN H4,POWER,PRIMITIVE=NULL R1,RESISTOR,390,PRIMITIVE=PASSIVE R2,RESISTOR,6k8,PRIMITIVE=PASSIVE R3,RESISTOR,9k1,PRIMITIVE=PASSIVE ... ... U1,74LS161,74LS161,MODFILE=74XX161.MDF U2,74LS161,74LS161,MODFILE=74XX161.MDF U3,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 each record is then: ,,,,...< pname=pvalue> where:



is the component reference. is the library device. is the part value. is the name of a component property. 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 blank value. The component has three properties, BV, IBV and PRIMITIVE which have been assigned the values 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 MAIN MEMORY. 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 FILE property has been enclosed in double quotes by the netlist generator (the is no need for the user to place quotes inside ISIS) as the value itself contains a comma which might otherwise be confused as the delimiter before the next property assignment.

8. The NETLIST Block An extract from a netlist block is shown below: *NETLIST,330 #00000,1 U1,TS,28 #00003,2 U1,IP,16 R4,PS,2 . . . #00215,4 Q12,PS,C D6,PS,U38,IP,8 C38,PS,2 #00216,2 C38,PS,1 U38,IP,5 A15,3 U1,TS,5 U7,IP,2 U8,IP,1 $MREQ$,1 U1,TS,19 $M1$,2 U9,IP,8 U1,TS,27 +12,2,STRAT=POWER U8,PP,14 U7,PP,14 As with the other netlist blocks, the first line identifies the block and gives the number of nets in the netlist. Each net starts with a line of the form: ,[,= ... ] Net names beginning with a # are created automatically by ISIS to identify otherwise un-named nets. A dollar character ($) is used to "bracket" inversion bars so a net appearing as RD/WR in the ISIS design appears as RD/$WR$ in the netlist. Where net property wire labels or sheet-global net properties have been used on the schematic, these will appear as additional parameters following the net name and size. The +12 net shows an example of this 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>,, ,LBL ,

or or

where: <part_ref>



is a component reference matching a component listed in the PARTLIST block. 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

is the name of a net label. is the name of a terminal. is the electrical type of terminal as given in the second column of the table the above. 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 and Logical Terminals serve mainly to carry additional net names that have been used for the net. These nonphysical records can be identified either by their electrical type or by the fact that they have two rather than 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 to continual evolution and re-definition as features are added to the products. The LYT format is also quite impenetrable to the casual adventurous user, even if he has programming know how and is armed with a binary file editor. From version II of our third generation products, we have implemented a secondary filing system which uses an ASCII file format which will be much less subject to modification. This has been done for several reasons: • Firstly, it makes much more feasible the creation of user or 3rd party board processing utilities such as Gerber or DXF import converters. • Secondly, it provides the experienced user with a way to perform obscure editing operations since the file can be loaded into a text editor and sections cut and pasted as required. • Thirdly, it is much easier to recover information from a corrupted ASCII file than from a corrupted binary file - in a sense, the REG file format is a useful debugging aid for ourselves! REG files are loaded and saved with the File-Import and File-Export commands. It follows that several REG files can be assembled with the layout editor. Also, any sub-group of objects in a layout can be tagged and exported should one wish to manipulate 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: *HEADER VERSION 300 300 UNITS 10nm AREA 5350 4350 6650 5450 The VERSION numbers are the versions of ARES and of the file format itself multiplied 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 over the place. The AREA numbers represent the extent of the region and are in thou. The coordinate 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 order given above. 4. OBJECTS BLOCK The OBJECTS block defines any Components, Pads, Polygonal Zones or 2D Graphics used in the layout. Each type of object uses a different syntax as described in 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 <mir> Note that there is no layer information. Instead, the mirror value determines the layer. and define coords of the anchor which is normally pin 1, or at any rate the first pin that was placed when the package was defined. 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 values can 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>" <mir> is the centre of the label. <string> can be up to 15 chars max. and are absolute coords - i.e. NOT relative to the component origin. and <mir> are as for components. is as follows: Bit 0 Bit 1 Bit 2 Bit 4

Right justify Left justify Align top Align middle

The next line gives the package (i.e. library part) and associated information: "<string>" <nsprims> <string> is the package name enclosed in quotes. The field is removed in ARES III - ARES can now recognize duplicated packages. is the number of primitives on the component silk screen. <nsprims> is the number of primitives on the solder silk screen. is the number of pins. For each primitive is a GRAPHIC record as described in section 4.4 component side first, then solder side according to the ncprims and nsprims numbers. Note that where the component has been mirrored, the component silk screen primitives will come from the solder silk screen symbol of the original library package and vice versa. Similarly, the coordinates of the all primitives refer to their actual positions on the board, not their positions relative to the library part origin. Then for each pad there is a line of the form "<pad_style>" <mir> "" In ARES III, layers are named, and will generally be TOP, BOT or ALL. Once again, and are absolute coords - i.e. NOT relative to the component origin. is the pin number - max 3 characters in ARES II, 5 characters 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 pin number and is normally used in the construction of new packages though pads may also be used for mounting holes etc. The format for a PAD record is PAD "" "<pad_style>" lyr <mir> "" 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 ... 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 the construction of package silk screen outlines or for creating graphics/markings etc on the layout. The format of a GRAPHIC record is GRAPHIC <primitive_type> <primtive_data> <primitive_type> is one of LINE BOX CIRCLE ARC BEZIER TEXT POLYLINE SYMBOL 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> <x2>

4.4.2 Box The format of a BOX primitive is BOX 4 <x1> <x2> 4.4.3 Circle The format of a CIRCLE primitive is CIRCLE 3 <x> 4.4.4 Arc The format of an ARC primitive is ARC 8 <x> <x1> <x2> <x1> ... define a clip box which restrict the part of the eliptic quadrant that is drawn. 4.4.5 Bezier BEZIER 8 <x1> ... <x4> The 4 control points define a standard Bezier cubic curve. 4.4.6 Text The format of a TEXT primitive is TEXT <x> <mir> "<string>" <x> is at the bottom left of normally oriented text. is as for labels. <string> can be up to 40 chars max. 4.4.7 Polyline The format of a polyline is POLYLINE <x1> ... <xn> is the number of vertices. Max 256.

4.4.8 Symbol ARES provides a symbol library facility whereby groups of primitives can be made into single "symbol primitives" and stored in a library. The format of a SYMBOL primitive is SYMBOL <x> <mir> "" <x> <mir> orient the symbol. 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 record is "<pad_style>" <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 The import module can cope with the layers in any order, or with several blocks for the same layer, or with no layer blocks at all. Each RECORD, again one per line has the form <style> <seg1_x> <seg1_y> ... <segn_x> <segn_y> is S for signal and P for power plane and is more or less obsolete in ARES III. N.B. There is one more coord pair than the number of segments.