This chapter describes the utility programs of the
Bartels AutoEngineer software. These utilities are additional programs that are run outside
Bartels AutoEngineer, i.e., at the operating system prompt or in a batch file. With these programs useful add-on tools are supplied such as library management, DDB file contents listing, BAE software setup and configuration, ASCII net list import, etc.
Contents
7.1 BAEHELP
Name
baehelp - BAE Windows Online Documentation Access
Synopsis
baehelp [file]
Description
The
baehelp utility program activates the Windows default web browsers and loads the optionally specified (HTML) file (or URL).
baehelp automatically loads the BAE User Manual from the
../baedoc directory relative to the BAE programs directory if the argument is omitted.
Warnings
baehelp can only be used under Windows.
7.2 BAESETUP, BSETUP
Name
baesetup - Bartels AutoEngineer Setup Module
bsetup - Bartels AutoEngineer Setup Utility
Synposis
bsetup -encode <code>
bsetup setupfile
Description
Releasing BAE Software Authorizations
The
bsetup command format
bsetup -encode <code>
is used for releasing BAE software updates and/or authorizations on previously delivered hardlock keys. The
-encode option requires one argument specifying the authorization code for the BAE software configuration to be released. BAE authorization codes are provided by Bartels System GmbH on demand. When using the
-encode option,
bsetup must be called from the BAE programs directory on the machine where the hardlock key to be released is currently mounted. One BAE call is required immediately after running
bsetup with the
-encode option (and a valid authorization code) to release the new software authorization, i.e., to transfer the new authorization code from the BAE setup file
bsetup.dat (where it has been stored to with
bsetup) to the hardlock key (note message
New Options : <sw-config>). Correct BAE authorization check is then ensured on subsequent BAE calls, i.e., BAE must be exited immediately after being called for releasing a new BAE authorization.
Defining and Modifying BAE Setup Data
The
bsetup command format
bsetup setupfile
is used for defining user specified BAE configuration parameters and defaults, such as BAE menu color setup, layer menus, documentary layer definitions, standard library access paths, etc.
bsetup accepts the setup file name
setupfile as argument. This file must have an extension of
.def but this extension must not be included with the command line.
bsetup translates the setup file and stores the defined setup parameters to a file named
bsetup.dat in the current directory. When starting the
Bartels AutoEngineer or activating one of BAE's program modules the corresponding setup parameters are loaded from the
bsetup.dat file in the BAE programs directory.
The Windows, Linux and Unix versions of the BAE software also provide the
baesetup module for modifying the BAE system parameters.
baesetup can be called using the
function from the BAE main menu.
baesetup uses a graphical interface with dialog boxes, making it much easier to be operated than the
bsetup utility which usually requires a DEF file containing the complete BAE parameter data set to be created and/or modified.
baesetup also provides a function for exporting the setup data to a
bsetup compatible DEF file.
Input File Format
Start Data, End Data, Comments
The setup file format must start with the keyword
SETUP and must end with the keyword
END.. Commentary text can be placed between
/* and
*/.
LAYMENUTEXT Command
The
LAYMENUTEXT command is used to set the names of the most used signal layers in the BAE layout system menus. The formal syntax of the
LAYMENUTEXT command is
LAYMENUTEXT LINE <line> ("<text>",<layer>);
where
<line> is the menu line number (in range 1 to 12),
<text> is the text to be displayed in the layer selection menus, and
<layer> is the signal layer to be used (range 1 to 100). A special
LAYMENUTEXT command format is given by
LAYMENUTEXT TOPLAYER ("<text>");
The above command above defines the menu text for the top signal layer option of the layer selection menus.
LAYPADLAYER Command
The
LAYPADLAYER command is used to enable or disable layer assignments on BAE layout library pad hierarchy level. The formal syntax of the
LAYPADLAYER command is
LAYPADLAYER (ENABLE) ;
and/or
LAYPADLAYER (DISABLE) ;
The
LAYPADLAYER command is historic and is used to support earlier versions of the BAE software. It is strongly recommended to use the
DISABLE option when creating new layout elements. The pad layer assignment should only be enabled for updating old job files.
LAYPLTMARKLAY Command
The
LAYPLTMARKLAY command defines a documentary layer to be used by the
CAM Processor for film registration marks. This layer is always plotted with the
mode. The formal syntax of the
LAYPLTMARKLAY command is
LAYPLTMARKLAY (<layer>) ;
where
<layer> is the documentary layer number (we recommend the "Plot Markers" layer).
LAYGRPDISPLAY Command
The
LAYGRPDISPLAY command is applied for defining a documentary layer to be used for displaying layout groups at movement with the group
set to
. The formal syntax of the
LAYGRPDISPLAY command is
LAYGRPDISPLAY (<layer>) ;
where
<layer> is the documentary layer number.
LAYDOCLAYER Command
The
LAYDOCLAYER command is used to define up to 100 documentary layers for the BAE layout system. Each documentary layer can have information relevant to either or both sides of the PCB. I.e., each documentary layer consists of three sides (sub-layers) named
(solder side, bottom layer),
(component side, top layer) and
(both component and solder side). This layer structure enables mirroring of SMT parts with all documentary text and graphic from the component side to the solder side and vice versa. When plotting
or
of a documentary layer with the
mode, the
elements automatically are added to the output, i.e., they are plotted together with
and/or
. The formal syntax of the
LAYDOCLAYER command is
LAYDOCLAYER <layer> ("<text>",<side>,<rotate>[<,index>]) ;
where
<layer> is the number of the documentary layer in a range of 1 to 100. The
<text> entry is used for specifying an up to 18 character long name for the documentary layer (e.g.,
Silkscreen,
Insertion Plan, etc.). The documentary layer name is displayed in the documentary layer selection menus of the BAE layout system. The
<side> entry is used for specifying the query mode to be used with side selections when defining objects on the corresponding documentary layer. The choices for
<side> are
SIDE1 | enables interactive input on of the documentary layer only |
SIDE2 | enables interactive input on of the documentary layer only |
BOTH | enables interactive input on of the documentary layer only |
NONE | causes the BAE layer menu functions to offer a submenu choice for selecting the documentary layer side on interactive input |
The
<rotate> parameter specifies the mode of text to be created on the corresponding documentary layer. The choices for
<rotate> are:
LOGICAL | text can be rotated and mirrored but remains readable (e.g., for silkscreen) |
PHYSICAL | text can be fully mirrored and rotated but cannot be moved with the and/or functions (e.g., for insertion plan) |
NOROTATE | text with fixed mirror and rotate mode, i.e., the part can be rotated and mirrored but the text position remains fixed (e.g., for drill plan) |
The
<index> parameter is optional and specifies the color palette and layer menu output index for the documentary layer. Documentary layer output index numbers start at 1. Documentary layers without output index assignments are automatically assigned to free index output positions. This feature allows for frequently used documentary layers to be placed at the top of the documentary layer selection menus and/or to group documentary layer definitions within layer menus according to their functionality.
DOCMENU Command
The DOCMENU command can be used to assign frequently used docmentary layers to the top levels of the layer selection menus in the layout system. The formal syntax of the DOCMENU command is as follows:
DOCMENU <menuline> (<layer>) ;
<menuline> specifies the line and/or position for displaying the documentary layer <layer> in the top level layer menus.
USERUNITS Command
The
USERUNITS command is used for setting the default units for the BAE layout system. Once set, this default is used whenever the user is prompted for size or coordinate input. The formal syntax of the
USERUNITS command is
USERUNITS (METRIC) ;
and/or
USERUNITS (IMPERIAL) ;
where
METRIC applies for mm units and
INCH applies for inch units. Alternate units can always be used by adding either
" (for inches) or
mm (for mm) to the input value.
SCMDEFLIBRARY Command
The
SCMDEFLIBRARY command is used to set the default SCM library path and the name of the SCM library file containing all the standard SCM symbol definitions (such as bustap, standard label, pin symbol, module port, etc.). The formal syntax of the
SCMDEFLIBRARY command is
SCMDEFLIBRARY ("<libpath>/<stdlib>");
where
<libpath> is the path to the directory which contains the SCM symbol library files and
<stdlib> specifies the name
<stdlib>.ddb of the SCM standard symbol library file in that directory. Please note the use of the slash
/ as directory and database hierarchy delimiter (instead of backslash
\ as in DOS). With the SCM library path properly set any SCM symbol can be accessed either by selecting the library file and symbol from the
popup menu or by specifying the symbol at the corresponding
function prompt as in
<scmlib>/<symbolname>
where
<scmlib>.ddb is the name of a SCM library file in the SCM library directory (e.g.,
74ls/74ls90 for symbol
74ls90 in library
74ls.ddb,
passiv/r for symbol
r in library
passiv.ddb, etc.). The SCM command
(see menu
) can be used to redefine the standard SCM library path
(- input resets the library,
! and/or
. input restores the library path defined through
SCMDEFLIBRARY).
LAYDEFLIBRARY Command
The
LAYDEFLIBRARY command is used to set the default layout library file containing the layout symbols. The formal syntax of
LAYDEFLIBRARY command is
LAYDEFLIBRARY ("<libpath>");
where
<libpath> is the path name of the library file
<libpath>.ddb. Please note the use of the slash
/ directory and database hierarchies delimiting (instead of backslash
\ as in DOS). With the layout library path properly set any layout symbol can be accessed by specifying the symbol with the
function as in
<symbolname>
where
<symbolname> is the name of the part symbol (e.g.,
dil16,
sot23, etc.). The
Layout Editorr command
(see menu
) can be used to redefine the standard layout library path
(- input resets the library,
! and/or
.> input restores the library path defined through
LAYDEFLIBRARY).
The
LAYDEFLIBRARY also sets the standard library file name to be used for logical library definition queries with the
function of the
Schematic Editor.
LAYDEFELEMENT Command
The
LAYDEFELEMENT command is used to set the default element name used when the enter key only is pressed in response to the layout board
Element Name ? system prompt. The formal syntax of the
LAYDEFELEMENT command is
LAYDEFELEMENT ("<layout-elementname>");
where
<layout-elementname> is the default layout board element name. This command considerably simplifies the work with the BAE layout modules since on corresponding user queries the default layout element name can be specified just by pressing the return key
 .
PROJROOTDIR Command
The
PROJROOTDIR command is used to set the directory root path for the optional directory selection menus of the BAE file access functions. The directory popup menus display all subdirectories of the root directory specified with the
PROJROOTDIR command. The formal syntax of the
PROJROOTDIR command is:
PROJROOTDIR ("<rootdir>");
where
<rootdir> is the path name of the directory selection root directory. If there is no
PROJROOTDIR command defined in the setup file, then the current directory is used on default. Examples for
<rootdir> are
/ (root directory of the current drive),
d: (root directory of PC drive D:),
c:/cad_data (directory
cad_data on PC drive C:),
/pcb/projects (directory
pcb/projects of the current drive), etc. The
<rootdir> entry must not contain any special characters such as
. or
\.
WINMENUMODE Command
The Windows and Motif versions of the BAE software can be operated with either the BAE standard user interface with side menus or with the windows-like user interface with pull-down menus. The
WINMENUMODE command is used to activate the desired user interface. Use the following command to activate the BAE standard user interface with side menus:
WINMENUMODE (SIDEMENU);
Use the following command to activate the BAE user interface with pull-down menus (context menus through left mouse button, function repetition through right mouse button) for Windows and/or Motif versions of the BAE software:
WINMENUMODE (PULLDOWN);
Use the following command to activate the BAE user interface with pull-down menus (context menus through right mouse button, function repetition through left mouse button) for Windows and/or Motif versions of the BAE software:
WINMENUMODE (PULLDOWN_RMB_CONTEXT);
The BAE standard user interface is activated with the DOS and/or X11 versions of the BAE software or if the
WINMENUMODE command is omitted in the BAE setup file.
FRAMECOLOR Command
The
FRAMECOLOR command is applied for defining the BAE menu color setup. The formal syntax of the
FRAMECOLOR command is
FRAMECOLOR <screenarea> (<colornumber>);
where
<screenarea> designates the workarea of the BAE user interface and
<colornumber> defines the color for the corresponding workarea. The
<screenarea> choices for the user interfaces of the BAE graphic program modules (BAE Shell,
Schematic Editor,
Layout Editor,
Autorouter,
CAM Processor,
CAM View) are:
| Identifier | Workarea |
|---|
DIALAREA | status/input line |
LISTAREA | text output/graphic workarea |
MENUHEAD | menu header/info field |
MENUHEAD BACK | menu header/info field background |
MAINMENU | main menu |
MAINMENU BACK | main menu background |
SUBMENUA | menu/submenu |
SUBMENUA BACK | menu/submenu background |
EMENMARK | menu cursor enabled (system waits for input) |
EFILMARK | menu bar enabled (system waits for input) |
DMENMARK | menu cursor disabled (system is busy) |
DFILMARK | menu bar disabled (system is busy) |
POPMTEXT | popup menu text |
POPMBUTT | popup menu button |
POPMBACK | popup menu background |
POPMFRAM | popup menu frame |
POPMFILL | directory popup menu background |
The
<colornumber> value is an integer between 1 and 15. The following table lists the color to color number assignments.
| Color Number | Color |
|---|
| 1 | blue |
| 2 | green |
| 3 | cyan |
| 4 | red |
| 5 | magenta |
| 6 | brown |
| 7 | light gray |
| 8 | dark gray |
| 9 | light blue |
| 10 | light green |
| 11 | light cyan |
| 12 | light red |
| 13 | light magenta |
| 14 | yellow |
| 15 | white |
Examples
The following listing shows the contents of the BAE standard setup file stdset.def; this file resides in the BAE programs directory and is used as template for the user defaults:
SETUP
/* Bartels AutoEngineer Standard Setup */
/* Menu Layer Texts */
LAYMENUTEXT LINE 1 ("Layer &1 (Solds.)",1);
LAYMENUTEXT LINE 2 ("Layer &2",2);
LAYMENUTEXT LINE 3 ("Layer &3",3);
LAYMENUTEXT LINE 4 ("Layer &4",4);
LAYMENUTEXT TOPLAYER ("Layer n (Par&ts.)");
/* Documentary Layer Definitions */
LAYDOCLAYER 1 ("Insertion Plan",SIDE2,LOGICAL);
LAYDOCLAYER 2 ("Solder Mask",NONE,PHYSICAL);
LAYDOCLAYER 3 ("Drill Plan",BOTH,NOROTATE);
LAYDOCLAYER 4 ("Film Markers",BOTH,PHYSICAL);
LAYDOCLAYER 5 ("Floor Plan",BOTH,LOGICAL);
LAYDOCLAYER 6 ("Part DRC",SIDE2,LOGICAL);
LAYDOCLAYER 7 ("Pin Number",SIDE2,LOGICAL);
LAYDOCLAYER 8 ("Solder Paste (SMT)",SIDE2,LOGICAL);
LAYDOCLAYER 9 ("Measure/Notes",SIDE2,LOGICAL);
/* Pad Layer Query */
LAYPADLAYER (DISABLE);
/* Film Markers Doc. Level */
LAYPLTMARKLAY (4);
/* Group Load Display Doc. Level */
LAYGRPDISPLAY (5);
/* Standard Search Paths and Names */
SCMDEFLIBRARY ("/baelib/stdsym");
LAYDEFLIBRARY ("/baelib/laylib");
LAYDEFELEMENT ("s1");
/* Default User Measure Units */
USERUNITS (METRIC);
/* Windows/Motif Menu Type */
WINMENUMODE (PULLDOWN);
/* Standard Graphic Color Setup */
FRAMECOLOR DIALAREA (11);
FRAMECOLOR LISTAREA (14);
/* Side Menu Color Setup */
FRAMECOLOR MENUHEAD (10);
FRAMECOLOR MENUHEAD BACK (8);
FRAMECOLOR MAINMENU (12);
FRAMECOLOR MAINMENU BACK (8);
FRAMECOLOR SUBMENUA (10);
FRAMECOLOR SUBMENUA BACK (8);
/* Menu Cursor Color Setup */
FRAMECOLOR EMENMARK (2);
FRAMECOLOR DMENMARK (15);
FRAMECOLOR EFILMARK (8);
FRAMECOLOR DFILMARK (4);
/* Popup Menu Color Setup */
FRAMECOLOR POPMTEXT (3);
FRAMECOLOR POPMBUTT (14);
FRAMECOLOR POPMBACK (8);
FRAMECOLOR POPMFRAM (15);
FRAMECOLOR POPMFILL (1);
/* Text Programs Color Setup */
FRAMECOLOR DIALLINE (10);
FRAMECOLOR OUTLINES (14);
FRAMECOLOR HEADLINE (12);
END.
It is recommended to change the setup.def file to define required setup parameters such as library path settings, layer assignments, etc. Then apply the bsetup utility program to convert the setup file stdset.def to the bsetup.dat file as in
> bsetup stdset
Files
bsetup.dat -- Setup parameter file (in BAE programs directory)
stdset.def -- Setup file template
See also
BAE Shell, Schematic Editor, Layout Editor, Autorouter, CAM Processor, CAM View, Packager.
Diagnosis
The error messages issued by bsetup are intended to be self-explanatory.
7.3 BICSET (IC Design)
NOTE: The bicset utility program is only available in Bartels AutoEngineer IC Design!
Name
bicset - Bartels AutoEngineer IC Design Setup Utility
Synopsis
bicset setupfile
Description
The
bicset utility program is used for the definition and/or configuration of
Bartels AutoEngineer IC Design system parameters such as standard cell dimensions for automatic placement, layer assignments and layer menu definitions, DRC parameters, etc.
bicset accepts the setup file name
setupfile as argument (this file must have the extension
.def, however, this file name extension should be omitted in the command line).
bicset translates the setup file and stores the defined setup parameters to a file named
bsetup.dat in the current directory. These parameters are loaded and/or activated from the
bsetup.dat file in the BAE programs directory when starting any of the program modules of the
Bartels AutoEngineer IC Design system.
Input File Format
Start Data, End Data, Comments
The setup file format must start with the keyword
SETUP and must end with the keyword
END.. Commentary text can be placed between
/* and
*/.
Sorry, this information is currently being updated.
Examples
The
Bartels AutoEngineer IC Design system comes with the following setup file
(icset.def; see BAE programs directory):
SETUP
/* Bartels AutoEngineer IC Design Setup */
Sorry, this information is currently being updated.
END.
You can adapt the settings in
icset.def to your specific requirements and use the
bicset utility program to compile and activate these settings:
> bicset icset
Files
bsetup.dat -- Setup parameter file (in BAE programs directory)
icset.def -- Setup file template
See also
BAE Shell,
Chip Editor,
Cell Placer,
Cell Router.
Diagnosis
The error messages issued by
bicset are intended to be self-explanatory.
7.4 BLDRING (IC Design)
NOTE: The bldring utility program is only available in Bartels AutoEngineer IC Design!
Name
bldring - Bartels AutoEngineer IC Design Build Ring Utility
Synopsis
bldring ringdescriptionfile
Description
The
bldring utility program automatically creates a chip layout template from a description file. This file contains informationen about the cells used and sections for placing an outer (rectangular) ring with bonding pad cells and other arbitrary cell placements. Only the placement sequence of the bonding pad cells must be specified for each ring side. The actual bonding pad cell placement coordinates are automatically calculated from the cell macro descriptions and the ring dimensions. Ring sections which are not occupied by bonding pads are automatically filled with metal structures for carrying two power supply signals through. Fixed cell placement coordinate specifications can be relative to the ring outline, thus allowing for pre-defined structures to be used on chip layouts with different dimensions.
bldring expects the ring description file
ringdescriptionfile as argument (this file must have the extension
.rig, however, this file name extension should be omitted in the command line). The name of the output project file and the element name of the chip layout to be created are specified in the ring description file.
Input File Format
Start Data, End Data, Comments
The setup file format must start with the keyword
ring and ends when the end of the file is reached. Commentary text can be placed between
/* and
*/.
Sorry, this information is currently being updated.
Examples
Sorry, this information is currently being updated.
Files
See also
Chip Editor.
Diagnosis
The error messages issued by
bldring are intended to be self-explanatory.
7.5 CONCONV
Name
conconv - Connections Conversion Utility
Synopsis
conconv projectname libraryfile
Description
The
conconv utility program is used for transferring ASCII net list data to the
Bartels AutoEngineer. Supported net list formats are BARTELS, CALAY, MARCONI, and RACAL. Net lists from other systems can often be written in one of these formats providing a convenient link between other schematic systems and the powerful BAE layout facilities.
conconv accepts the net list file name
projectname as first argument. This file must have an extension of
.con but this extension must not be included with the command line.
conconv accepts the layout library file name
libraryfile as second argument. This file must have an extension of
.ddb but this extension must not be included with the command line. The
libraryfile is expected to be in BAE DDB (Design DataBase) format and must contain the layout part definitions referenced from the net list.
conconv reads the ASCII net list
<projectname>.con and checks all net list layout symbols with the corresponding entries in the layout library
<libraryfile>.ddb.
conconv generates the design file
<projectname>.ddb and a free list named
<projectname>.fre. The free list contains an unconnected pins report. After successful processing, an internal physical net list will exist in the design file named
<projectname>.ddb. A layout element can then be created in that design file, parts placed and traces routed.
Input File Format
Start Data, End Data, Comments
The net list file format must start with the
LAYOUT command and must end with the keyword
END.. Commentary text can be placed between
/* and
*/. The formal syntax of the LAYOUT command is:
LAYOUT <elementname> ;
where
<elementname> is the name of the net list and/or layout element to be created in the destination file.
Part List
The part list section is expected after the
LAYOUT command and must start with the keyword
PARTS. Each part is defined by a command in the form
<part> : <plname> ;
where
<part> is the part name (e.g.,
C1,
R1,
IC15, etc.), and <plname> is the physical library name of the package (e.g.,
DIL14,
SO20, etc.).
Net List
The net list section is expected after the parts list. Different net list formats are supported. A keyword preceding the net list information is used to designate the net list format type
(CONNECT for Bartels AutoEngineer format,
CALAY for CALAY format,
RACAL for RACAL format,
MARCONI for MARCONI format). Each net in the
Bartels AutoEngineer format is defined by a command in the form
<part>.<pin>=<part>.<pin>=...=<part>.<pin>
and/or
/<net>/ <part>.<pin>=<part>.<pin>=...=<part>.<pin>
where
<part> is the part name as defined in the part list,
<pin> is the pin name of that part, and
<net> is the net name. The BAE net list format supports optional net attribute definitions to be specified after the
"/<net>/" command in the following form:
PRIORITY(<prior>) MINDIST(<dist>) ROUTWIDTH(<width>)
The net attributes are used for controlling the Autorouting process.
<prior> is the net-specific routing priority,
<dist> is the net-specific minimum distance, and
<width> is the net-specific routing width. With each pin a pin-specific routing width can be defined optionally; this value must be enclosed in parentheses behind the
<pin> specification.
<prior> must be in positive integer units (the greater the value the higher the routing priority), all other net attribute values are assumed to be in positive mm units.
Each net in the CALAY format is defined by a command in the form
<part>(<pin>),<part>(<pin>),...,<part>(<pin>)
and/or
/<net> <part>(<pin>),<part>(<pin>),...,<part>(<pin>)
The CALAY format supports optional pin-specific routing widths (in mm units). The pin routing width specification must follow the
<pin> definition and must be separated from
<pin> by a comma character
(,).
Each net in the RACAL format is defined by a command in the form
.ADD_TER <part> <pin> <net>
.TER <part> <pin>
<part> <pin>
:
<part> <pin>
The RACAL net list must end with the keyword
.END.
Each net in the Marconi format is defined by a command in the form
<part> <pin> <part> <pin> ... <part> <pin> ; <net> /
Examples
Net list
(design.con) in
Bartels AutoEngineer format:
LAYOUT board;
PARTS
c1 : cap50;
c2 : cap75;
r1 : res;
t1 : tebc;
CONNECT
/net1/ c2.2=t1.3;
/net2/ c1.2(0.4)=t1.2=r1.2;
/gnd/ PRIORITY(2) MINDIST(0.4) t1.1=c1.1(0.4);
/vcc/ PRIORITY(1) ROUTWIDTH(0.5) c2.1=r1.1;
END.
Net list
(design.con) in CALAY format:
LAYOUT board;
PARTS
c1 : cap50;
c2 : cap75;
r1 : res;
t1 : tebc;
CALAY
/net1 c2(2),t1(3);
/net2 c1(2,0.4),t1(2),r1(2);
/gnd t1(1),c1(1,0.4);
/vcc c2(1,0.5),r1(1,0.5);
END.
Net list
(design.con) in RACAL format:
LAYOUT board;
PARTS
c1 : cap50;
c2 : cap75;
r1 : res;
t1 : tebc;
RACAL
.ADD_TER c2 2 net1
.TER t1 3
.ADD_TER c1 2 net2
.TER t1 2
r1 2
.ADD_TER t1 1 gnd
.TER c1 1
.ADD_TER c2 1 vcc
.TER r1 1
.END
END.
Net list
(design.con) in MARCONI format:
LAYOUT board;
PARTS
c1 : cap50;
c2 : cap75;
r1 : res;
t1 : tebc;
MARCONI
c2 2 t1 3 ; net1 /
c1 2 t1 2 r1 2 ; net2 /
t1 1 c1 1 ; gnd /
c2 1 r1 1 ; vcc /
END.
The net lists above can be transferred to BAE by applying the
conconv program as in the command
> conconv design laylib
which causes
conconv to read the ASCII net list
design.con, check the part list entries against the layout library definitions in
laylib.ddb, and store the net list named
board to the job file
design.ddb. After successful processing, the
Layout Editor can be started, a layout named
board (same name as net list for correct connectivity access) can be createdw and the net list parts can be loaded and placed using the
function from the
menu. For pin assignment correctness the same layout library as specified with the
conconv call must be used for loading the parts (apply the
function from the
menu to select the correct library file).
See also
netconv
Diagnosis
The error messages issued by
conconv are intended to be self-explanatory.
Warnings
Input file identifiers for part names, pin names or net names containing special characters
(-,
+,
/,
(,
=, ...) must be enclosed in single-quotes or double-quotes.
7.6 COPYDDB
Name
copyddb - Copy Design Database Utility
Synopsis
copyddb srcfile dstfile {-ms|-md|-mr}
{-a|-as|-al|-ac|-sp|-ss|-sl|-sm|-ll|-lp|-ls|-ld|-cl|-cc|-cp|
-drc|-llib|-gtab|-fnt|-sct|-lct|-ict|-ulp|-ull|-rule|-recover} [pattern]
Description
The
copyddb utility program copies selected database class entries and all their references from one DDB (Design DataBase) file to another.
copyddb can be used as a batch mode driven tool for merging libraries or updating job design files.
copyddb accepts two filenames as arguments.
srcfile and
dstfile are the names of the DDB source file and the DDB destination file (these files must be available with extension
.ddb unless file name extensions are explicitly included with the file name specifications).
copyddb copies elements from the source file to the destination file. The merge switch is used to control whether existing destination file entries should be replaced overwritten (source file is master) or not (destination file is master) or whether only existing destination file elements should be overwritten (replace).
copyddb optionally accepts a key
pattern string as argument. The pattern denotes the name(s) of the elements to be copied. Wildcards are allowed with the pattern specification. All elements of the selected class are copied if no pattern is specified. The object class of the element(s) to be copied is selected with the class switch.
Options
Merge Switch (required):
-ms | merge source (source file is master) |
-md | merge destination (destination file is master) |
-mr | merge replace (source file is master) |
Class Switch (required):
-a | all classes |
-as | all SCM classes (same as all -s? switches) |
-al | all layout classes (same as all -l? switches) |
-ac | all chip/IC design classes (same as all -c? switches) |
-sp | SCM plans (with part list and logical net list) |
-ss | SCM symbols (with logical library) |
-sl | SCM labels |
-sm | SCM marker |
-ll | layout plans (with physical net list and paths) |
-lp | layout parts |
-ls | layout padstacks |
-ld | layout pads |
-cl | chip/IC design layouts (with physical net list and paths) |
-cc | chip/IC design cells |
-cp | chip/IC design pins |
-drc | layout design rule check parameter blocks |
-llib | logical library entries |
-gtab | Gerber aperture tables |
-fnt | BAE font data |
-sct | SCM color tables |
-lct | layout color tables |
-ict | chip/IC design color tables |
-ulp | User Language programs |
-ull | User Language libraries |
-rule | Rule system definitions |
-recover | all classes (recovery mode for corrupt DDB files) |
Examples
To copy all layout symbols with element names matching
so1* (e.g.,
so14,
so16, ...) from
newlib.ddb to
laylib.ddb with
laylib.ddb supposed to be the master file:
> copyddb newlib laylib -md -lp so1*
To copy all schematic design data from
design.ddb to
redesign.ddb with
design.ddb supposed to be the master file:
> copyddb design redesign -ms -as
To update the padstack definitions matching
finger* in
design.ddb according to the definitions in
laylib.ddb:
> copyddb laylib design -ms -ls finger*
To copy all User Language libraries from
ulcprog.vdb to
ullibs.sav with
ulcprog.vdb supposed to be the master file:
> copyddb ulcprog.vdb ullibs.sav -ms -ulp
Replace layout parts in
design.ddb with corresponding parts from
library.ddb, i.e., update job-specific layout library in
design.ddb:
> copyddb library design -mr -lp
Files
bae.log -- logfile (written to current directory)
See also
listddb
The functionality for copying DDB file elements is also implemented through the
ddbcopyelem User Language system function.
Diagnosis
The error messages issued by
copyddb are intended to be self-explanatory.
Warnings
copyddb is a powerful tool for manipulating DDB file contents. Be aware of WHAT you are doing with
copyddb. Conflicts can occur when merging SCM and/or layout plans from different design files since the part lists, net lists, part attributes, etc. are merged, too (i.e., you might run into serious
Packager and/or
Backannotation problems, when using
copyddb inappropriately). We strongly recommend to check the destination file consistency after applying
copyddb!
7.7 FONTCONV
Name
fontconv - Font Conversion Utility
Synopsis
fontconv fontfile libraryfile
Description
The
fontconv utility program compiles standard ASCII format vector font data into a
Bartels AutoEngineer font file.
fontconv accepts the font description file
fontfile as first argument. This file must have an extension of
.fon but this extension must not be included with the command line.
fontconv accepts the layout library file name
libraryfile as second argument. This file must have an extension of
.fnt but this extension must not be included with the command line.
fontconv stores the translated font data to
libraryfile.
The
Bartels AutoEngineer standard font library file is named
ged.fnt. This file is stored to the BAE programs directory and contains the font(s) used by the
AutoEngineer.
Input File Format
The font description file must start with the
FONT command (for defining the name of the font) and must end with the keyword
END.. Commentary text can be placed between
/* and
*/. The font description file is structured according to
FONT <fontname>;
CHAR <ord>;
POLY (0, 0), (10, 10), (10, 0) ;
:
:
END.
where
<fontname> is the name of the font to be created, and where
<ord> is the ordinal ASCII number of the character (e.g., character
A would be number 65). The valid value range for
<ord> is 0..255. If the font description file contains multiple character definitions for the same
<ord> value, then
fontconv stores only the last of these definitions. Each character
(CHAR) is defined by a list of polygon lines
(POLY). Each polygon definition consists of a list of polygon corner point coordinates. The coordinates must be specified in positive integer units in a 32x48 point grid area. The [0,0] coordinate refers to the left bottom corner of the grid area. The valid value range for X coordinates is 0..31, and the valid value range for Y coordinates is 0..47. Each character definition can have a maximum of up to 32 corner points.
Examples
Font description file
test.fon containing definitions for
! and
" (with 4 corner points and 2 polygons each):
/* Library font name */
FONT test;
/* ASCII code 33 for '!' */
CHAR 33;
/* Lower vertical line */
POLY (16,5),(16,9);
/* Upper vertical line */
POLY (16,13),(16,45);
/* ASCII code 34 for '"' */
CHAR 34;
/* Left line */
POLY (12,40),(4,32);
/* Right line */
POLY (16,32),(24,40);
END.
The font description file listed above can be transferred to the font library file
ged.fnt by applying
fontconv as in
> fontconv test ged
Files
ged.fnt -- BAE font library file (in BAE programs directory)
See also
fontextr
Diagnosis
The error messages issued by
fontconv are intended to be self-explanatory.
Warnings
fontconv overwrites existing fonts in the destination file without any comment.
7.8 FONTEXTR
Name
fontextr - Font Extraction Utility
Synopsis
fontextr fontname libraryfile
Description
The
fontextr utility program analyzes BAE internal vector font data and generates an editable ASCII font description file.
fontextr accepts the font name
fontname as first argument. This is the name of the font to be extracted from the font file.
fontextr writes the ASCII font data to a file named
<fontname>.fon.
fontextr accepts the font library file name
libraryfile as second argument. This file must have an extension of
.fnt but this extension must not be included with the command line. The font library file is the file from which the user wants to extract font data.
The
Bartels AutoEngineer standard font library file is named
ged.fnt. This file is stored to the BAE programs directory and contains the font(s) used by the
AutoEngineer.
To find out which fonts are stored in a font library file apply the
fontextr call with a
<fontname> that does not exist in the font file and
fontextr lists the fonts in the file.
Output File Format
The font description file starts with the
FONT command (defining the name of the font) and ends with the keyword
END.. Commentary text can be placed between
/* and
*/. The font description file is structured according to
FONT <fontname>;
CHAR <ord>; /* 'ASCII character' */
POLY (0, 0), (10, 10), (10, 0) ;
:
:
END.
where
<fontname> is the name of the font and
<ord> is the ordinal ASCII number of the character (e.g., character
A would be number 65). The valid value range for <ord> is 0..255. Each character
(CHAR) is defined by a list of polygon lines
(POLY). Each polygon definition consists of a list of polygon corner point coordinates. The coordinates are specified in positive integer units in a 32x48 point grid area. The [0,0] coordinate refers to the left bottom corner of the grid area. Hence, the valid value range for X coordinates is 0..31, and the valid value range for Y coordinates is 0..47. Each character definition has a maximum of up to 32 corner points. At the end of each character definition header line a comment is printed for showing the ASCII representation of the character.
Examples
To extract the data of font
standard from the font library file
ged.fnt (font data output is directed to ASCII file
standard.fon):
> fontextr standard ged
Files
ged.fnt -- BAE font library file (in BAE programs directory)
See also
fontconv
Diagnosis
The error messages issued by
fontextr are intended to be self-explanatory.
7.9 INSTALL
Name
install - Bartels AutoEngineer Installation Utility
Synopsis
install
install [-c] srcfile[pattern] dstfile[directory\*]
Description
The
install utility program is applied for installing the
Bartels AutoEngineer PC software (or parts of it) to the PC hard disk.
install can also be used for packing (compressing) and/or unpacking (decompressing) selectable files.
The
install utility program is the one and only tool feasible for performing a correct PC installation since the BAE PC software files are stored in compressed format on the disks of the BAE install media.
Modes of Operation
BAE Software Installation
The BAE PC software installation process can be started with the
install
command, where the current directory must contain the contents of the BAE install media, i.e., either floppy disk 1 of the BAE install kit or the BAE CD-ROM must be mounted, and the working directory must be set to the corresponding drive. The
install program comes up with a self-explanatory dialogue, where the user (amongst other parameters) has to specify the install mode. The install mode is used to select the file set to be installed. Standard install modes copies all software files. Update install modes does not replace certain system files ending on
.dat,
.def and
.fnt. I.e., update install mode should be selected to prevent the
install program from overwriting existing user-defined setup data, color tables, font definitions, aperture tables, etc. The
install program also prompts for the destination directories. The directory default names can be accepted by pressing the return key
. Each destination directory path name can be edited or can even be deleted to suppress installation of the corresponding component(s) of the software. Any of the destination directories not yet existing is automatically created with user verification.
Compress/Decompress Files
The formal
install syntax for compressing and/or decompressing selectable files is
install [-c] srcfile[pattern] dstfile[directory\*]
where option
-c activates compression and decompressing is applied by omitting that option. Wildcards
(pattern) can optionally specified with the
srcfile source file argument. The
\* string is required at the end of the destination directory specification when selecting multiple files with wildcards.
Examples
Decompress all
.ddb files from floppy/drive A and store the decompressed files to directory
baelib on hard disk drive C:
> install a:\*.ddb c:\baelib\*
Decompress the file
ged.fnt from floppy drive B and store the decompressed file to directory
bae on hard disk drive D:
> install b:\ged.fnt d:\bae
Compress the file
design.ddb and store the compressed file to
design.cmp:
> install -c design.ddb design.cmp
Diagnosis
The error messages issued by
install are intended to be self-explanatory.
7.10 LISTDDB
Name
listddb - List Design Database Utility
Synopsis
listddb ddbfile listfile
Description
The
listddb utility program lists the contents of a DDB (Design DataBase) file to an ASCII file.
listddb accepts the DDB file name
ddbfile as first argument. This file must be available with extension
.ddb unless a file name extension is explicitly included with the file name specification.
listddb accepts the listing file name
listfile as second argument. This is the name of the ASCII destination file for the listing.
Examples
To list the contents of DDB file
laylib.ddb to ASCII file
laylib.lst:
> listddb laylib laylib.lst
See also
copyddb
Diagnosis
The error messages issued by
listddb are intended to be self-explanatory.
Warnings
The listfile argument is the name of the ASCII file to be created by
listddb.
listddb does not perform any file existence check, and the destination file is overwritten without any comment. It is strongly recommended to refrain from specifying existing file names unless the destination file is not needed any more.
7.11 LOGLIB
Name
loglib - Logical Library Maintenance
Synopsis
loglib loglibfile libraryfile
Description
The
loglib utility program compiles an ASCII text file containing the relationship between logical symbols and physical parts into a Design DataBase (DDB) file. The information transferred by
loglib includes assignment of SCM symbols to layout parts, logical to physical pin mapping, pin/gate swap definitions, predefined power supply pins, fixed part attributes, etc. This information is required by the
Packager for translating logical net lists (generated by SCM) into physical net lists (processed by the layout system), and it is also required by
for transferring net list changes (pin/gate swap, part name changes) from the layout to the schematic circuit.
loglib accepts the loglib file name
loglibfile as first argument.
loglibfile is an ASCII file containing logical library part definitions. This file must have an extension of
.def but this extension must not be included with the command line.
loglib accepts the layout library file name
libraryfile as second argument. This file must have an extension of
.ddb but this extension must not be included with the command line. The
libraryfile is expected to be in BAE DDB (Design DataBase) format and should contain the layout part definitions.
Usage
The
loglib utility program must be used to update the logical library whenever a new SCM symbol is added to the library or when an SCM symbol and/or a layout part definition has been modified in a way that changes the relationship between them (e.g., change of a pin name). Usually the SCM symbol is the first to be designed (or edited). Then the layout part will be defined (if not yet existing). Finally, the loglib file is created and the logical library definitions herein are translated to the layout library using the
loglib program.
Input File Format
Start Data, End Data, Comments
The
loglib input file format must start with the keyword
LOGLIB and must end with the keyword
END.. Commentary text can be placed between
/* and
*/.
part Command
The
part command is applied for assigning an SCM symbol to a layout symbol. The formal syntax of the
part command is:
part <llname> : <plname>
where
<llname> is the logical library name (i.e., the name of the SCM symbol) and
<plname> is the physical library name (i.e., the layout package type). Keyword
default can optionally be set before
<plname> to enable different (non-default) layout package assignment by setting a value for the
$plname attribute at the corresponding SCM symbol:
part <llname> : default <plname>
The
part also supports alternate package type definitions which can be assigned during part placement in the Layout system. The
part command syntax for defining alternate package types is:
part <llname> : [default] <plname>[,<plname>,...,<plname>]
where
<llname> specifies the name of the SCM symbol, and the
<plname> entries specify the list of valid part package types. The first
<plname> entry is used as default package type. The subsequent
<plname> entries define the list of alternate package types for the corresponding part. Alternate part package types can be assigned using the
function during part placement in the
Layout Editor. The sequence of the alternate package type menu entries provided by the
function corresponds with the sequence of
<plname> entries specified with the
part command. Note however that any package type assignment defined with
$plname attribute settings override
assignments.
The
class keyword can be used to assign the part to a part class:
part <llname> : class <partclassname> [default] <plname>
Part class assignments are used by the
Packager to check whether alternate part definition assignments through the
$rlname (Requested Logical Library Name) attribute are permitted.
The following
part command format is used for deleting part assignments from the logical library:
delete part <llname> ;
The
part command provides special format
part <llname> : virtual ;
which does not reference any physical part. This is applied to avoid errors when symbols have been used in the schematic that don't relate to parts in the PCB (e.g., company logos, drawing borders, etc.). This format is also used for setting net attributes (see below).
The
part command also allows for the definition of pure logical parts by using the keyword
logical as in
part <llname> : logical ...
Logical parts do not have a physical package assignment and can be used for generating logical (e.g., EDIF) net lists for PLD and/or LCA design.
Some parts have elements that require different symbols, for example relays. The symbol for the relay's coil is very different from that of the contacts and springsets and these may well need to appear on different sheets of the schematics. One symbol is chosen to be the main symbol and given a logical library name whilst the other symbols are given other logical library names. The relationship between the symbols is defined using the keywords
mainpart and
subpart as in
part <mainllname> : mainpart <plname>
:
part <subllname> : subpart <mainllname>
Note that the
subpart definition provides a link to the logical library name of the
mainpart
(<mainllname>) instead of a
<plname>. This feature can also be applied for providing power supply symbols.
The relationship between the pin names in the SCM symbol and the pin names in the physical part definition could be 1:1. I.e., the pin names of a resistor could be
1 and
2 and these could translate to
1 and
2 in the physical part. In this case only the relationship between the names of the SCM symbol and the physical part need to be defined as in
part <llname> : <plname> ;
where the semicolon is used to complete the
part command. In most cases however additional information is required (such as pin/gate swap definitions, fixed part attributes, power supply pins, etc.) with must be provided with part
<commands> as in
part <llname> : <plname> { <commands> }
net Command
The
net command is used to define pins that don't appear in the symbol but need to be connected to particular signals or nets (e.g., power supply pins). The
net command syntax is
net "<netname>" : ( <pinlist> ) ;
where
<netname> is the signal or net name to connect and
<pinlist> is a list of the physical pins (separated by commas) connected to the net. Each pin name containing special characters must be enclosed with quotes.
By preceding the net name with a dollar sign
($), the
net command allows for the definition of net name attributes as in
net "$<netname>" : ( <pinlist> ) ;
With this feature it is possible to assign a part-specific power supply by assigning a variable net name attribute value (such as
vcc or
+5v) for the net name attribute (e.g.,
$powernet) to the desired SCM symbol/part of the SCM sheet.
In some cases more than one pin is connected to a particular signal but only one connection is desired in the symbol. The syntax of the
net command for defining internal pin connections is:
net internal : ( <pinlist> ) ;
where
<pinlist> is a list of physical pin names (separated by commas) that are to be linked together but only one of these pins needs to appear in the SCM symbol.
bus Command
The
bus command allows busses to be defined directly on a symbol making multiple connections a single operation. The formal syntax of the
bus command is:
bus ( <buspinlist> ) ;
where
<buspinlist> defines a list of bus connection pins
<buspin> (separated by commas) in the SCM symbol. Subsequently
pin and/or
xlat commands (see below) can be applied to define bus signals using special pin name specifications as in
"<buspin>.<bussignal>"
where
<buspin> is the name of a pin in the
<buspinlist> and
<bussignal> is one of the signal connections on that bus pin.
pin Command
The
pin command is used to define SCM symbol pin names. This command is not normally required since the pin list can be defined with the
xlat command as well. It is mainly used to provide additional information in cases where 1:1 pin mapping applies, i.e., where the pin names otherwise can not be shown in the loglib file. The formal syntax of the
pin command:
pin ( <pinlist> ) ;
where
<pinlist> contains a list of pin names defined on the SCM symbol.
The
<startpin>-<endpin>[:<step>]
pin name range pattern can be used for specifying pin lists. This allows for definitions such as
pin(a1-a4); for
pin(a1,a2,a3,a4) or
pin(c2-c10:2) for
pin(c2,c4,c6,c8,c10). It is also possible to include multiple pin name ranges such as
pin(a1-a32,b1-b2,c1-c32) within a single command. Pin name range patterns are only pin list aliases, the system still saves and displays (function
) the complete pin name lists.
The
pin none ;
suppresses automatic 1:1 assignments of symbol to layout pins for missing pin commands to allows for, e.g., the definition of mainpart symbols without pins for general use.
xlat Command
The
xlat command is used to define the relationship between the logical pin names and the physical pin names. It can be used to translate one set of logical pin names to one or more sets of physical pin names, i.e., the
xlat command is used to define the logical gates of a physical part. The formal syntax of the
xlat command is:
xlat ( <lplist> ) to ( <pplist> )
or ( <pplist> ) or ... or ( <pplist> ) ;
where
<lplist> is a list of the logical pin names on the SCM symbol and
<pplist> are the corresponding physical pin lists. The logical pin name set can translate to more than one physical pin name set to provide gate definition features. The number and sequence of the pin name definitions must match.
xlat commands with alternations (i.e.
xlats with
or options for gate specifications) automatically introduce cross-part gate
swap definitions if no explicit
swap internal command is defined with the corresponding part.
swap Command
The
swap command defines the way in which pins and gates can be swapped when working in the layout system. I.e., the definitions stored with the
swap command is used by the BAE layout system to check whether particular pin/gate swaps are allowed or not. The formal syntax of the
swap command is:
swap <swapdefinition> ;
where
<swapdefinition> defines the relationship between pins and gates. These definitions use brackets to identify the swap hierarchy as in
( Part Swap ) |
([ Pin Group Swap ]) |
([( Gate Swap )]) |
([(( Pin Swap ))]) |
where the square brackets can be omitted if no pin group exists. Optionally, the
internal keyword can follow the
swap keyword to forbid swaps between different parts.
newattr Command
The
newattr command enables information to be included in the physical net list data that can subsequently be extracted with
Bartels User Language or the
userlist utility program. It sets up user-definable attributes associated with the physical part. These fixed library attributes could be for such information as cost, company part number, internal stock number, etc. The formal syntax of the
newattr command is:
newattr "$<attname>" = "<attvalue>" ;
where
<attname> is a user-defined attribute name and
<attvalue> is the attribute value assigned to the attribute of the corresponding part. Attribute value assignments can be shown in the BAE layout system by defining the
"$<attname>" text on the corresponding layout part (e.g., on a documentary layer).
The
newattr command optionally allows for the definition and assignment of pin-specific attributes as in
newattr "$<attname>" = "<attvalue>" to ( <pplist> ) ;
This feature can be used for specifying arbitrary pin-specific attributes such as pin types or pin fanouts for electronic rule checks (ERC) or for generating net list interfaces to simulators such as PSpice.
The
Packager evaluates
$pintype pin attribute settings to perform electrical rule checks (ERC). It is recommended to assign fixed ERC pin types through the logical symbol/part definitions. The following pin type attribute value settings are supported:
$pintype | Pin Type |
|---|
in | Input Pin |
out | Output Pin |
bidi | Bi-directional Pin |
anl | Analog Pin |
sup | Power Supply Pin |
The ERC issues a warning message such as
Net 'netname' has only inputs! if a net with one or more input pins has no (normal, bi-directional or power supply) output pin. A warning message such as
Driver collision on net 'netname'! is issued if a normal output pin is connected to another output pin, a bi-directional pin or a power supply pin.
The syntax of the
newattr command also allows for the
assignment of variant-specific attributes by specifying a comma-separated variant number after the attribute name quotes. This allows for the assignment of different fixed attributes to different predefined project variants such as
110 Volt and
230 Volt or
deutsch and
english.
newattr attribute values without variant number specification are assigned to the default/base variant.
The
newattr command can be used to trigger automatic ID attribute value generation by the
Packager through the assignment of
?id?,
?symid?extension and
?partid?extension values.
?id? creates consecutive ID values (id1,
id2 etc.). The
?symid?extension and
?partid?extension values append the specified extension with underscore to the schematic symbol name and/or layout part name
(?partid?diffpair1 results in
ic1_diffpair1, ic2_diffpair1, etc.). Automatic ID generation is useful if a
newattr command refers to multiple pins, as this allows to create a reference between pins as required for differential pair indication.
The
newattr command accepts special
!unique! attribute value settings which prompt the
Packager to assign gates to layout parts with matching
!unique! attribute values only. The
swap commands adhere to such assignments and swap gates only between layout parts with matching
!unique! attribute values. I.e., the
!unique! setting can be used to control the packaging of gates with different attribute values without using
$rpname attributes. This is useful for certain part types such as resistor arrays:
part ra_so16r : so16r {
newattr "$val" = "!unique!";
pin (1-16);
swap internal (
(( 1,16)),(( 2,15)),(( 3,14)),(( 4,13)),
(( 5,12)),(( 6,11)),(( 7,10)),(( 8, 9))
);
}
The following example illustrates the application of the
!unique! value in the definition of an opamp with power supply assignents through attribute values:
part op_lm324 : dil14 {
pin (/i,i,o);
net "$vplus" : (4);
net "$vminus" : (11);
newattr "$vplus" = "!unique!";
newattr "$vminus" = "!unique!";
xlat (/i, i, o)
to ( 2, 3, 1)
or ( 6, 5, 7)
or ( 9,10, 8)
or (13,12,14);
swap internal ((2,3,1),(6,5,7),(9,10,8),(13,12,14));
}
netattr Command
The
netattr command can be used for the design of special SCM symbols for setting net attributes. The formal syntax of the
netattr command is:
netattr <netatt> "$<attname>" : ( <pinlist> ) ;
where
<netatt> is the name of the net attribute,
<attname> is the name of the part attribute to be mapped to the net attribute, and
<pinlist> is the list of logical pin names. Arbitrary net attribute names can be set with
<netatt>, but the following keywords have special meaning for the control of the Autorouting process:
routwidth | net-specific routing width (in mm units) |
powwidth | pin-specific routing width (in mm units) for the signals and/or pins defined with the net command (see above) |
mindist | net-specific minimum clearance (in mm units) |
priority | net-specific routing priority (in positive integer units; the greater the value the higher the priority) |
The
route.ddb SCM library file is provided with the
AutoEngineer.
route.ddb contains virtual SCM symbols for setting net attribute values. The corresponding loglib file
(route.def) includes the following definitions:
loglib
part att_rw : virtual
{
pin (x);
netattr routwidth "$val" : (x);
}
part att_pw : virtual
{
pin (x);
netattr powwidth "$val" : (x);
}
part att_md : virtual
{
pin (x);
netattr mindist "$val" : (x);
}
part att_pr : virtual
{
pin (x);
netattr priority "$val" : (x);
}
end.
With each of the above listed net attribute symbols a pin named
x and a net attribute is defined. Net attribute setting then is applied by connecting the desired net to the net attribute symbol's pin and setting the corresponding attribute value.
With arbitrary user-specific net attribute definitions additional net information can be processed for special purposes. Such net attributes can be used for controlling the layout process (maximum/minimum allowed trace length, parallel routing restrictions, layer assignments, etc.) or they can be evaluated for subsequent simulator processes, run-time analysis, checking ECL/EMC rules, etc. Tools for accessing and evaluating user-specific net attributes can be provided with
Bartels User Language programs.
The
netattr command can be used to trigger automatic ID attribute value generation by the
Packager through the assignment of
?id?,
?symid?extension and
?partid?extension values.
?id? creates consecutive ID values
(id1,
id2 etc.). The
?symid?extension and
?partid?extension values append the specified extension with underscore to the schematic symbol name and/or layout part name
(?partid?diffpair1 results in
ic1_diffpair1, ic2_diffpair1, etc.). Automatic ID generation is useful if a
netattr command refers to multiple nets, as this allows to create a reference between nets as required for differential pair indication.
call Command
The
call command is used for hierarchical SCM design in order to assign SCM blocks to SCM symbols for later reference on SCM sheet level. The formal syntax of the
call command is:
call <blockname> ;
where
<blockname> is the name of the SCM block, and the corresponding part must be defined
virtual. The block symbol pins are assigned to the name-corresponding module ports of the SCM block.
architecture Command
The
architecture command can be used to define
virtual logical parts consisting of different arbitrarily connected SCM symbols and/or layout parts. The formal syntax of the
architecture command is:
architecture { <partlist> }
<partlist> contains the list of used symbols with comma-separated pin lists in parenthesis, where each pin specification has the following format:
<pinname:connection>
<connection> can be the name of a pin of the
<architecture> symbol. A connection to a global net can be established with
<net netname>.
<net & intnetname> or
<& intnetname> specifications can be used to refer to a local net of the
<architecture> symbol.
Examples
Loglib file
example.def containing two part definitions:
loglib
/* Example Loglib File */
part 74ls00 : dil14, so14
{
newattr "$partnumber" = "A-NAND-X11B82";
newattr "$pintype" = "in" to (1,2,4,5,9,10,12,13);
newattr "$pintype" = "out" to (3,6,8,11);
newattr "$pintype" = "sup" to (7,14);
pin (a,b,y);
net "vcc" : (14);
net "$groundnetname" : (7);
xlat ( a, b, y)
to ( 1, 2, 3)
or ( 4, 5, 6)
or (13,12,11)
or (10, 9, 8);
swap (((1,2),3),((4,5),6),((13,12),11),((10,9),8));
}
part tx27 : default sot23;
part tr_bc547 : class "npn-transistor" default to92
{
pin (e,b,c);
xlat (e,b,c)
to (1,2,3);
}
end.
The example above shows the definition of the gate
74ls00 which can be packed up to 4 times into a single
dil14 package. The logical pins (a,b,y) can be assigned to either of the pin sets (1,2,3), (4,5,6), (13,12,11) or (10,9,8). Within the layout system, this package type assignment can be changed to
so14. A fixed attribute named
partnumber has been assigned with attribute value
A-NAND-X11B82. A fixed pin-specific attribute named
pintype is assigned to each pin, thus designating the pin type to be either
in (input pin),
out (output pin) or
sup (supply pin, i.e., power or ground). Pin 14 of the
dil14 package is a pre-defined power supply pin on signal
vcc, whilst pin 7 can be connected to a signal net by assigning the desired net name (such as
vss) to the
$groundnetname attribute of the
74ls00 symbol on SCM level. The
swap command is applied to define the following pin/gate swaps:
Pin Swap: (1,2) and/or (4,5) and/or (13,12) and/or (10,9)
Gate Swap: (1,2,3) with (4,5,6) or (13,12,11) or (10,9,8)
Part Swap: (1,2,3,4,5,6,13,12,11,10,9,8)
The example loglib file above also contains the
tx27 and
tr_bc547 part definitions.
tx27 is assigned to default
sot23 package with 1:1 pin mapping. The
tr_bc547 definition includes an assignment to part class
npn-transistor.
To compile loglib file
example.def and store the result to DDB file
mylib.ddb:
> loglib example mylib
The following example illustrates the use of
mainpart and
subpart for assigning different SCM symbols (relay part with two contacts and one coil) to the same package:
loglib
/* Relays part */
part rel2 : mainpart dilrel
{
xlat (a,b) to (1,7) or (8,14);
swap ((1,7),(8,14));
}
part rel2sub : subpart rel2
{
xlat (p,m) to (2,6);
}
end.
The following example shows the definition of part
buspart with busses
b1 and
b2 including the bus signals
0,
1,
2 and
3 (the corresponding SCM symbol must have pins
b1 and
b2 defined for connecting and tapping the bus):
loglib
/* Bus part definition */
part buspart : sot8
{
bus (b1,b2);
xlat (b1.0,b1.1,b1.2,b1.3) to (1,2,3,4);
xlat (b2.0,b2.1,b2.2,b2.3) to (5,6,7,8);
}
end.
The following example illustrates how to define a virtual part for hierarchical circuit design. This applies for the assignment of SCM symbol
dff to SCM block
dff with pin names
s,
r,
q and
/q referring to the module ports defined on the corresponding SCM hierarchy block element/sheet:
loglib
/* Hierarchical D-Flip-Flop */
part dff : virtual
{
pins (s,r,q,/q);
call dff;
}
end.
The following example shows a synthetically generated symbol definition. The
delay SCM symbol consists of four internally connected
74ls04 inverters.
loglib
/* Synthetically generated Inverter/Delay Circuit */
part delay : virtual
{
pin (in,out);
architecture
{
part "74ls04" (a:in,y:&connect1);
part "74ls04" (a:&connect1,y:&connect2);
part "74ls04" (a:&connect2,y:&connect3);
part "74ls04" (a:&connect3,y:out);
}
}
end.
Files
The symbol and part library directory installed with the
Bartels AutoEngineer software contains the
loglib(*.def) files for alle SCM library files. All
loglib files of the software are already compiled into the
laylib.ddb layout library file.
See also
Packager.
The functionality for compiling Logical Library definitions is also implemented through the
con_compileloglib User Language system function.
Diagnosis
The error messages issued by
loglib are intended to be self-explanatory.
Warnings
Input file identifiers such as part names, pin names or net names containing special characters
(-,
+,
/,
(,
=, ...) must be enclosed in single-quotes or double-quotes.
The
Packager copies logical library definitions from the specified layout library to the project file when first referenced. Certain SCM or layout symbol modifications from the project file such as pin name changes must be reflected by a logical library definition update. I.e.,
loglib must be applied to the project file if the original logical library definition has already been transferred to the project file during an earlier
Packager run. The
Packager issues error messages such as
Part not found in library!,
Part not defined! or
Pin not found! loglib definitions are wrong or missing.
7.12 NETCONV
Name
netconv - Logical Netlist Conversion Utility
Synopsis
netconv projectfile
Description
The
netconv utility program is used for transferring logical (i.e., unpacked) net list data from BAE ASCII format to internal
Bartels AutoEngineer format ready for processing with the BAE
Packager.
netconv accepts the net list file name
projectfile as first argument. This file must have an extension of
.net but this extension must not be included with the command line.
netconv converts logical ASCII net list data from input file
<projectfile>.net to a BAE logical net list with the name
netlist in a DDB (Design DataBase) file named
<projectfile>.ddb. This internal logical net list can be converted to a physical net list with the
Packager, in the same way as information from the BAE schematic. It will, as a result, be possible to perform pin and gate swaps in the subsequent layout process.
Input File Format
Start Data, End Data, Comments
The net list file format must start with the keyword
NETLIST; and must end with the keyword
END.. Commentary text can be placed between
/* and
*/.
Part list
The part list section is expected after the
NETLIST command and must start with the keyword
PARTS. Each part is defined by a command in the form
<part> : <llname> ;
where
<part> is the part name (e.g.,
C1,
R1,
IC15, etc.), and <llname> is the logical library name of the part (e.g.,
74LS08,
OP_LM211,
i80386sx, etc.).
Net List
The net list section is expected after the parts list and must start with the keyword
CONNECT. Each net is defined by a command in the form
<part>.<pin>=<part>.<pin>=...=<part>.<pin>
and/or
/<net>/ <part>.<pin>=<part>.<pin>=...=<part>.<pin>
where
<part> is the part name as defined in the part list,
<pin> is the pin name of that part, and
<net> is the net name.
Examples
ASCII net list (design.net):
NETLIST;
/* Part list */
PARTS
ic1 : 74ls00;
ic2 : 74ls00;
c1 : c;
/* Net list */
CONNECT
ic1.a = ic2.y;
ic2.a = ic1.y;
/vcc/ c1.1;
/vss/ c1.2;
END.
To convert the logical ASCII net list
design.net to an internal logical net list named
netlist in BAE DDB file
design.ddb:
> netconv design
The command above causes
netconv to read the ASCII net list
design.net, and store the net list named
netlist to the job file
design.ddb. After successful processing, the
Packager can be used to convert this net list to a physical net list ready to be processed by the
BAE Layout Editor.
See also
conconv,
loglib,
Packager.
Diagnosis
The error messages issued by
netconv are intended to be self-explanatory.
Warnings
netconv converts logical net lists to the
Bartels AutoEngineer. In cases where pin/gate swap or part name change is applied in the corresponding layout the physical net list data must be backannotated to the schematics, i.e., special tools might be required for transferring the assignments file information generated by
BAE back to the original SCM system.
Input file identifiers for part names, pin names or net names containing special characters
(-,
+,
/,
(,
=, ...) must be enclosed in single-quotes or double-quotes.
7.13 REDASC
Name
redasc - REDAC ASCII Input Interface
Synopsis
redasc projectname [libraryfile]
Description
The
redasc utility program converts layout data from Redac MAXI systems.
redasc transforms layout symbols, part lists, net lists, placement information, etc. from CDI format to internal BAE DDB (Design DataBase) format.
redasc accepts the CDI file name
projectname as first argument. This file must have an extension of
.cdi but this extension must not be included with the command line.
redasc optionally accepts the layout library file name
libraryfile as second argument. This file must have an extension of
.ddb but this extension must not be included with the command line. The
libraryfile is expected to be in BAE DDB (Design DataBase) format and must contain the layout part definitions referenced from the net list. The required layout library symbols are expected to be defined in the CDI file if the
libraryfile argument is omitted.
redasc converts the CDI file
<projectname>.cdi to a BAE DDB design file with the name
<projectname>.ddb. The generated layout element is named
<projectname> and contains the placed parts and the net list connectivity.
redasc also generates a free list named
<projectname>.fre which contains an unconnected pins report.
See also
conconv
Diagnosis
The error messages issued by
redasc are intended to be self-explanatory.
Warnings
redasc does not convert traces from the CDI format. Use the
CAM View facility to read in routing data via Gerber format to reconstruct the PCB.
7.14 RULECOMP
Name
rulecomp - Bartels Rule System Compiler
Synopsis
rulecomp srcfile [-l]
Description
The
rulecomp compiler is used for translating Bartels Rule Specification source code.
rulecomp accepts the rule specification source file name
srcfile as first argument. This file must have an extension of
.rul, but this extension must not be included with the command line.
rulecomp translates the rule specification source file and stores the defined rules and/or rule sets to a file named
brules.vdb in the BAE programs directory. These rules can be applied by certain in-built BAE system functions and/or customer-defined
User Language programs.
Options
Command line options of the Rule System Compiler consist of the dash
(-) start character followed by the option specification. Single-character option specifications optionally followed by a mode or toggle number are often known as switches or flags.
Listing Option [-l]
The
-l option is used to control the listing file output. Omitting this option suppresses listing output. The
-l option generates a rule compilation listing file. The listing output file name is derived from the corresponding source code file name, with the original file name extension replaced by
.lst. The listing file is for user information purposes only, i.e., it is not required by system.
Examples
Compilation of the rules defined in
routstd.rul; the compiled rules are stored with the name
routstd to the
brules.vdb file of the BAE programs directory:
> rulecomp routstd
Compilation of the rules defined in
routstd.rul with listing file output (to
routstd.lst); the compiled rules are stored with the name
routstd to the
brules.vdb file of the BAE programs directory:
> rulecomp routstd -l
Files
brules.vdb -- BAE rules data file (in BAE programs directory)
See also
Bartels AutoEngineer User Manual - Chapter 6
Diagnosis
The error messages issued by
rulecomp are intended to be self-explanatory.
Warnings
rulecomp is a powerful software tool for implementing rules for automatically generating and/or manipulating
Bartels AutoEngineer design data. It is strongly recommended to test each new rule in a non-critical environment (test software installation, test jobs, backup of real jobs, etc.) until confidence in the rule is established for unrestricted use on real designs.
7.15 ULC - User Language Compiler
Name
ulc - Bartels User Language Compiler
Synopsis
ulc [-wcon|-wcoff] [[-S[ource]] srcfile...]
[-lib libname...] [-dll libname...]
[{-cp|-cl} [dstname...]]
[-I[nclude] includepath...] [-D[efine] macroid...]
[-O[0|1]] [-e[0|1]] [-w[0|1|2|3|4]] [-t[0|1]]
[-l[0|1|2|3|4|5]] [-ld listingdirectory name]
[-dp prgname...] [-dl libname...]
[-ulp prgfilename] [-ull libfilename]
[-log logfilename]
Description
The
Bartels User Language Compiler
ulc translates
User Language source code into
User Language machine programs and/or
User Language libraries. User Language machine programs can be executed by the
User Language Interpreter.
User Language libraries usually are generated from frequently used source code.
User Language library machine code can be linked to other
User Language machine code (programs or libraries). Library linking can be done either statically (at compile time by the
User Language Compiler) or dynamically (at runtime by the
User Language Interpreter). As an advantage of the
User Language library concept, frequently used source code needs to be compiled just once and can subsequently be referenced through linking, which is much faster than compiling.
Options
Command line options of the
User Language Compiler consist of the dash
(-) or slash
(/) start character followed by the option specification. Single-character option specifications optionally followed by a mode or toggle number are often known as switches or flags. Such special options can be grouped as in
/l2Ow3 or
-O1w3l2, which both select listing mode 2, activate the optimizer and set the warning severity level to 3.
Wildcard Option [-wcon|-wcoff]
The wildcard option is used to activate or deactivate wildcard processing at the specification of file and/or element names. On default wildcard processing is activated, i.e., omitting the wildcard option leaves wildcard processing activated. Option
-wcon can be used for explicitly activating wildcard processing. With wildcard recognition activated, the character
? can be used for matching any arbitrary character, and the character
* can be used for matching an arbitrary number of arbitrary characters. Option
-wcoff can be used to turn off wildcard processing. Wildcard recognition must be deactivated for explicitly processing names containing wildcard characters such as
scm_? or
ged_*.
Source File Option [[-S[ource]] srcfile...]
This option is used for specifying the file name(s) containing the source code to be compiled. File name specifications can contain a directory path, i.e., the source file names need not reside in the current directory. Wildcards are supported with the source file name specification if wildcard recognition is activated (see option
-wcon above). Source file names can be specified with or without file name extension. On source file name specifications without extension the Compiler automatically assumes and/or appends file name extension
.ulc. I.e., source file names with non-default extension must be specified with their extension, respectively. It is possible to, e.g., generate
User Language libraries from include files usually named with extension
.ulh. The type of User Language machine code to be generated is designated with either option
-cp
(User Language programs; see below) or option
-cl (User Language libraries; see below). The name of the machine code element to be generated is derived from the source file name by stripping the directory path and the file name extension from the source file name. Non-default destination program and/or library element names can be specified with options
-cp and
-cl (see below). The
-Source and/or
-S option keywords are not required with source file specifications where file names cannot be intermixed with other name specifications, e.g., if source file names are the first names specified on the ULC command line. However, the
-Source (and/or
-S) option can be used for explicit source file specification to avoid ambiguities in case where source file names are not the first name specifications on the ULC command line. At least one source file specification is required if neither option
-dp nor option
-dl (see below) is specified.
Static Link Option [-lib libname...]
The static link option
-lib requires one or more library name specifications and at least one valid source file specification (see option
-Source above). The machine code of the libraries specified with the
-lib option must be available in the
ulcprog.vdb file of the BAE programs directory, i.e., the required libraries must be compiled before they can be linked. The built-in linker of the
User Language Compiler binds the machine code of these libraries to the machine code currently to be translated.
Dynamic Link Option [-dll libname...]
The dynamic link option
-dll requires one or more library name specifications and at least one valid source file specification (see option
-Source above). The machine code of the libraries specified with the
-dll option must be available in the
ulcprog.vdb file of the BAE programs directory, i.e., the required libraries must be compiled before they can be linked. The built-in linker of the
User Language Compiler stores dynamic link request information with the machine code for the
User Language Interpreter to perform dynamic linking of the requested libraries at runtime.
Create Program/Library Option [{-cp|-cl} [dstname...]]
The create option can be used to designate the type of machine code to be generated. The
User Language Compiler can create either
User Language programs or
User Language libraries. On default program generation request is assumed, i.e., omitting both the
-cp and the
-cl option defaults to
User Language program creation. Option
-cp explicitly selects program generation whilst option
-cl selects library generation; both options must not be used together. On default, the destination element name is derived from the corresponding source file name; both the directory path and the source file name extension are stripped from the source file name to generate destination element name. The
-cp and
-cl options allow for the specification of non-default destination program and/or library names. Only one source file specification (see option
-Source) is allowed when explicitly specifying destination element name(s) with options
-cp and
-cl. The machine code generated by the Compiler is stored with the specified destination element name to
ulcprog.vdb file of the BAE programs directory. Wildcards are not supported with destination element name specifications. Multiple destination element name specifications are supported in order to store the machine code of a single source under different names, e.g., to generate programs
scm_st,
ged_st, etc. from a single source file named
bae_st.ulh.
Include Path Option [-I[nclude] includepath...]
The
-Include (and/or
-I) option is used for specifying multiple alternate include paths for include file name search. At least one include path argument is required. When encountering an
#include preprocessor statement the Compiler first checks the current directory for include file access and then searches the include paths in the sequence as specified with the
-Include option until the requested include file is found.
Define Option [-D[efine] macroid...]
The
-Define (and/or
-D) option is used for defining macros at the
User Language Compiler call. At least one macro identifier is required. This option corresponds with the
#define preprocessor statement, i.e., macros defined with the
-Define option can be checked with the
#ifdef or
#ifndef preprocessor statements, thus giving more control on conditional compilation to the Compiler.
Optimizer Option [-O[0|1]]
The
-O option is used to activate or deactivate the optimizer of the
User Language Compiler. On default the optimizer is deactivated, i.e., omitting this option leaves the optimizer deactivated. Option
-O or
-O1 activates the optimizer. Option
-O0 explicitly deactivates the optimizer. The optimizer frees the machine code from redundancies, and modifies it to make it more efficient. Optimizing machine code significantly reduces disk space and main memory requirements, and the resulting machine code can be loaded and executed much faster. It is strongly recommended to activate the optimizer.
Error Severity Option [-e[0|1]]
The
-e option is used for setting the error severity level. On default the error severity level is set to 1, i.e., omitting this option selects error severity level 1. Option
-e0 sets error severity level 0. Option
-e or
-e1 explicitly sets error severity level 1. Error severity level 1 compiles all specified sources; error severity level 0 causes the Compiler to stop the compilation process on any errors occurred during a single source compilation.
Warning Severity Option [-w[0|1|2|3|4]]
The
-w option is used for setting the warning severity level in the range 0 to 4. On default, the warning severity level is set to 0, i.e., omitting this option selects warning severity level 0. Omitting explicit level specification with this option as with
-w defaults to warning severity level 3. Each type of warning defined with the Compiler is assigned to a certain warning severity level. The Compiler only prints warnings with a warning severity level less than or equal the level selected with the
-w option since higher warning severity levels denote less importance. With this option, it is possible to suppress less important warning messages.
Top Level Warnings Only Option [-t[0|1]]
The
-t option controls whether warning messages related to the compilation of include files are omitted or not. On default (i.e., if this option is not specified or if its value is set to 0), warning messages related to the compilation of both top level source code files and include files are issued. Setting this option value to 1 prevents the
User Language Compiler from issuing warning messages related to the compilation of include files, thus simplifying the analysis of warning messages when working with standard include files containing functions and variables which are not used by every program.
Listing Option [-l[0|1|2|3|4|5]]
The
-l option is used to control the listing file output. Listing modes 0 to 5 can be specified. Mode 0 won't produce any listing output and mode 5 produces the most detailed listing. On default, listing mode 0 is selected, i.e., no listing is generated if this option is omitted. Omitting explicit listing mode specification with this option as with
-l defaults to listing mode 5. The listing output file name is derived from the corresponding source code file name, where the original file name extension is replaced with extension
.lst. The listing file is for user information purposes only, i.e., it is not required by system.
Listing Directory [-ld listingdirectoryname]
The
-ld option allows for the specification of an alternative output directory for the listing files created with the
-l option. This option is useful when applying
make utilities for automatically compiling modified
User Language programs as it allows to keep the source directories clean. With the BAE software, a
makefile is provided in the
baeulc directory. This
makefile defines the dependencies between
User Language programs and include files and works with listing files in a subdirectory
(lst).
Delete Program Option [-dp prgname...]
The
-dp option is used for deleting previously compiled programs from the
ulcprog.vdb file in the BAE programs directory. At least one program element name is required. Wildcards are supported with the program element name specification if wildcard recognition is activated (see option
-wcon above). Warnings are issued when trying to delete non-existent programs. Program deletion is always processed before any source code compilation in order to avoid compilation process conflicts such as deleting a program immediately after it has been compiled with the same ULC call.
Delete Library Option [-dl libname...]
The
-dl option is used for deleting previously compiled libraries from the
ulcprog.vdb file in the BAE programs directory. At least one library element name is required. Wildcards are supported with the library element name specification if wildcard recognition is activated (see option
-wcon above). Warnings are issued when trying to delete non-existent libraries. Library deletion is always processed before any source code compilation in order to avoid compilation process conflicts such as deleting a library immediately after it has been compiled with the same ULC call.
Program Database File Name Option [-ulp prgfilename]
On default, the
User Language Compiler stores
User Language programs to a file named
ulcprog.vdb in the
Bartels AutoEngineer programs directory. The
-ulp option can be used to select a different
User Language program database file.
Library Database File Name Option [-ull libfilename]
On default, the
User Language Compiler stores
User Language libraries to a file named
ulcprog.vdb in the
Bartels AutoEngineer programs directory. The
-ull option can be used to select a different
User Language library database file.
Log File Option [-log logfilename]
The
User Language Compiler prints all messages to standard output and to a log file. Log file output is generated to save long message lists which could be generated at the compilation of different sources. On default the log file name is set to
ulc.log (in the current directory). The
-log option can be used to specify a non-default log file name.
Examples
Compilation of the
User Language program contained in
ulcprog.ulc with optimization and warning message output; the produced machine program is stored with the name
ulcprog to the
ulcprog.vdb file of the BAE programs directory:
> ulc ulprog -Ow
Compilation of the User Language program contained in
ulcprog.ulc with listing file output (to
ulcprog.lst); the produced machine program is stored with the name
newprog to the
ulcprog.vdb file of the BAE programs directory:
> ulc ulprog -l -cp newprog
Deleting the
User Language programs named
ulcprog and
newprog and all
User Language libraries with names starting with
test and ending on
lib from the
ulcprog.vdb file of the BAE programs directory:
> ulc -dp ulprog newprog -dl test*lib
Generate
User Language library
libsll from source file
libbae.ulh (optimizer is activated; listing output is directed to file
libbae.lst):
> ulc libbae.ulh -cl libsll -l2O
Compile all current directory files with extension
.ulc and statically link the generated program machine codes with library
libsll (macro
USELIB is defined for controlling conditional compilation; optimizer is activated):
> ulc *.ulc -Define USELIB -lib libsll -O
Generate libraries
libstd and
stdlib from source file
std.ulh (optimizer is activated, warning severity level is set to 2):
> ulc -w2 -O -cl libstd stdlib -Source std.ulh
Generate library
liblay from source file
\baeulc\lay.ulh with library
libstd dynamically linked (optimizer is activated, warning severity level is set to 3, Compiler messages are directed to log file
genlib.rep instead of
ulc.log):
> ulc /wO -cl liblay -S \baeulc\lay.ulh -dll libstd -log genlib.rep
Generate programs
laypcr and
tracerep from source files
laypcr.old and
tracerep.ulc with library
liblay dynamically linked (optimizer is activated):
> ulc laypcr.old /dll liblay /cp -O /S tracerep
Files
ulcprog.vdb -- BAE User Language database (in BAE programs directory)
See also
userlist,
User Language Interpreter,
Bartels User Language Programmer's Guide
Diagnose
The error messages issued by
ulc are intended to be self-explanatory.
Warnings
ulc is a powerful software tool for implementing programs for the manipulation of DDB file contents and for generating CAM data. Even the BAE user interface can be considerably changed and/or extended with
User Language programs. It is advisable to test each new
User Language program in a non-critical environment (test software installation, test jobs, backup of real jobs, etc.) until confidence in the program is established for unrestricted use on real jobs. It is also strongly recommended to ensure security, e.g., to prevent foreign persons from implanting destructive
User Language programs to
ulcprog.vdb.
7.16 User Language Interpreter
Description
The
Bartels User Language Interpreter is used for executing
Bartels User Language programs which have been compiled with the
Bartels User Language Compiler. The
Bartels User Language Interpreter is integrated in most of
Bartels AutoEngineer modules. I.e.,
Bartels User Language programs can be called from each of these BAE modules.
Starting User Language Programs
When calling a
User Language program, the name of the program to be executed must be specified, and this program must be available in the
ulcprog.vdb file of the BAE programs directory. The program name can be specified either explicitly or implicitly. An explicit
User Language program call is applied with the BAE menu item
from the
menu of one of the interpreter environments
Schematic Editor,
Layout Editor,
Autorouter,
CAM Processor,
CAM View or
Chip Editor. After activating the
function the name of the required program must be typed in; on empty string or question mark
(?) input or on mouse-click to the program name query a popup menu with the available
User Language programs is displayed for selecting the required program with mouse-pick.
User Language programs can also be called by keystrokes, i.e., by pressing a standard key
(0,
1, ...,
9,
a,
b,
c, ...) or a function key
(F1,
F2, ...,
F12). This implicit program call facility is available with the BAE function menu active, i.e., this type of program call is possible at any time unless another interactive keyboard input currently is requested. The keystroke program name is build from the currently active
User Language Interpreter environment
(scm for Schematic Editor,
ged for Layout Editor,
ar for Autorouter,
cam for CAM Processor,
cv for CAM View,
ced for Chip Editor), an underscore and the name of the pressed key. E.g., the program named
scm_f4 is called when pressing function key
F4 in the
Schematic Editor,
cam_8 is called when pressing digit key
8 in the
CAM Processor,
ged_r is called when pressing standard key
r in the
Layout Editor,
ar_# is called when pressing standard key
# in the
Autorouter.
The
User Language Interpreter only performs an automatic keystroke program calls if the corresponding program is available in
ulcprog.vdb.
A special method of implicit
User Language program call is provided with the startup sequence of the interpreter environment. This feature automatically executes a
User Language program with a predefined name when starting an interpreter environment
(scm_st in Schematic Editor,
ged_st in Layout Editor,
ar_st in Autorouter,
cam_st in CAM Processor,
cv_st in CAM View), thus, e.g., allowing for automatic system parameter setup.
Bartels User Language also provides system functions for performing key programming and menu assignments. Using these functions (e.g., in
User Language startup programs) provides a convenient way of dynamically changing the
Bartels AutoEngineer user interface. Another special
User Language system function is provided for calling
User Language programs from other
User Language programs.
Examples
Call the User Language program named
ulprog:
| File |  |
| Run User Script | |
| Program Name ? | ulprog |
Files
ulcprog.vdb -- BAE User Language database in BAE programs directory
See also
User Language Compiler,
Schematic Editor,
Layout Editor,
Autorouter,
CAM Processor,
CAM View,
userlist,
Bartels User Language - Programmer's Guide
Diagnosis
The error messages issued by the
User Language Interpreter are intended to be self-explanatory.
Warnings
The
Bartels User Language Interpreter is a powerful tool for starting programs for the manipulation of DDB file contents and for generating CAM data. Even the BAE user interface can be considerably changed and/or extended with
User Language programs. It is advisable to test each new
User Language program in a non-critical environment (test software installation, test jobs, backup of real jobs, etc.) until confidence in the program is established for unrestricted use on real jobs. It is also strongly recommended to ensure security, e.g., to prevent foreign persons from implanting destructive
User Language programs to
ulcprog.vdb.
7.17 USERLIST
Name
userlist - User Programmable List Generator
Synopsis
userlist scriptfile projectfile jobname
Description
The
userlist utility program is a user-programmable ASCII list generator.
userlist interprets the user-defined
userlist script
<scriptfile>.usf, analyzes the net list named
<jobname> from the requested job file
<projectfile>.ddb, and produces a text output listing file named
<projectfile>.<ext>. The listing file extension
<ext>, the output format and the type of net list information to be extracted are defined in the
<scriptfile>.usf
userlist script.
Input File Format
Start Data, End Data, Comments
The
userlist script file must start with the definition of the output file name extension which is defined with the command
EXTENSION = "<ext>";
where
<ext> is the file name extension (a maximum length of up to three characters is allowed). The
userlist script must end with the
ENDSPEC keyword. Commentary text can be placed between
/* and
*/.
FOR Command
The
FOR command is used for selecting elements of a certain class. The formal syntax of the
FOR command is:
FOR (ALL <class> ) { <commands> }
where
<class> specifies the class of the objects to be scanned. Valid classes can be selected with the keywords
NETS,
PARTS,
PINS,
ATTRIBUTES or
<attname>.
NETS iterates the net list object class,
PARTS iterates the part list object class,
PINS iterates pin lists and
ATTRIBUTES iterates attribute lists.
<attname> is used for scanning the attribute value list of the attributes named
<attname>. The command list
<commands> is processed once for each element of the specified object class.
FOR commands can be nested to give more control. The nested
FOR loop in
FOR (ALL NETS) { FOR (ALL PINS) {...}}
would for example find the first net, and then for all pins of that net perform
<commands>. It would then repeat the operation on the second net and so on until it has completed processing of all nets.
Output Commands
The output commands are
PRINT and
PRINTFOR. The formal syntax of the
PRINT command is:
PRINT(<parameters>);
where
<parameters> specify the list of output items separated by commas. Output items enclosed in quotation marks are printed as literal text.
QUOTES keyword can be used to print quotation marks. The
TAB keyword prints a tab character. The
CR keyword prints a newline. Other output items can be specified with attribute names (as listed below) followed by
:<length>:<decimals>
where
<length> is the output length and
<decimals> is the output precision for the corresponding number and/or string value. Negative
<length> values apply for left-aligned output, and
%<length>:<decimals>
will include leading zeros. Default values are 3 for
<decimals> and output item length for the
<length> value. The
<length> value is adjusted to the output item length if necessary. Distance values can be converted to mm or inch units by appending
" MM" or
" INCH", respectively. The
PRINT command can be applied as in
PRINT(QUOTES,PINWIDTH:7:3,QUOTES); /* output: " 3.756" */
PRINT(QUOTES,PINWIDTH%7:3,QUOTES); /* output: "003.756" */
PRINT(QUOTES,PINWIDTH:-7:3,QUOTES); /* output: "3.756 " */
The
PRINT command syntax allows for uppercase and/or lowercase name and/or attribute value outputs by adding blank-separated
UPPER or
LOWER keywords after name or attribute specifications.
The
PRINTFOR command is used to scan through a particular object class and print a list of elements with a defined separator. The formal syntax of the
PRINTFOR command is:
PRINTFOR (ALL <class>) SEPERATOR(<sep>),ELEMENTS(<elements>);
where
<class> is the object class to be scanned (as defined in the
FOR command),
<sep> is the separator to be used (e.g.,
",",
"CR", etc.), and
<elements> are the elements to be listed. The syntax of the parameter lists in
<sep> and
<elements> is the same as for the
PRINT parameter list. If
PRINTFOR is nested in a
FOR loop, then the output is automatically restricted to the current element of the
FOR loop.
IF Command
The
IF command allows commands to operate conditionally. The formal syntax of the
IF command is:
IF (<expr>) { <commands> }
and/or
IF (<expr>) { <commands> } ELSE { <commands> }
The formal syntax of the
IF expression <expr> is given either by
? <attr>
or by the comparison expression
<attr> <operator> <attr|constant>
The
? <attr> expression is used to check whether the attribute specified by
<attr> is available. Available operators for comparison expression are
= (equal),
<> (not equal),
< (less than),
> (greater than),
<= (less than or equal),
>= (greater than or equal).
Counter
The commands
CLEARCOUNTER;
and
COUNTUP;
are used for controlling an internal counter.
CLEARCOUNTER sets the counter value to zero.
COUNTUP increments the counter value. The current counter value can be accessed via the
COUNTVALUE attribute (see also below).
Attributes
The following attributes can be accessed:
| Net Data | NETNAME | Net Name |
NETPINCOUNT | Number of Pins connected to Net |
PRIORITY | Net Priority (for the Router) |
MINDIST | Net Minimum Clearance (for the Router) |
NETNUMBER | Net Number |
| Part Data | PARTNAME | Part Name |
PINCOUNT | Number of Pins defined on Part |
FREEPINS | Number of unconnected Pins in the Part |
PARTATTRIBCOUNT | Number of Attributes in the Part |
$attributname | Value of selected Attribute in the Part |
| Pin Data | PINNAME | Pin Name |
PINWIDTH | Pin Routing Width |
| General Data | PROJECTNAME | Project and/or Design Name |
ATTRIBCOUNT | Number of Attributes matching current Name/Value Combination |
ATTRIBNAME | Name of selected Attribute |
ATTRIBVALUE | Value of selected Attribute |
COUNTVALUE | Current Counter Value |
Examples
Net list generator
conconv.usf:
/* Connection List Generator */
EXTENSION = ".con";
PRINT ("LAYOUT ", PROJECTNAME, ";", CR);
PRINT ("PARTS",CR);
FOR (ALL PARTS)
{
PRINT (" ",PARTNAME," : ",$plname,";",CR);
}
PRINT ("CONNECT",CR);
FOR (ALL NETS)
{
PRINT (" /", NETNAME,"/ ");
PRINTFOR (ALL PINS)
SEPERATOR ("="), ELEMENTS (PARTNAME,".",PINNAME);
PRINT (";",CR);
}
PRINT ("END.",CR);
ENDSPEC
The
userlist script
conconv.usf can be applied as in
> userlist conconv design board
where net list
board of the job file
design.ddb is analyzed, and the output net list file
design.con with the following contents is produced:
LAYOUT board;
PARTS
ic1 : dil14;
ic2 : dil14;
ic3 : dil16;
CONNECT
/gnd/ ic1.1=ic2.2=ic3.9;
/vcc/ ic1.11=ic2.5=ic3.7;
END.
The part list generator
partlist.usf
EXTENSION = ".ptl";
FOR (ALL $plname)
{
PRINT (ATTRIBCOUNT," ",ATTRIBVALUE,CR);
}
ENDSPEC
would create output file
<job>.ptl with the following contents:
3 cap50
4 dil14
2 dil16
1 r75
Diagnosis
The error messages issued by
userlist are intended to be self-explanatory.
7.18 VALCONV
Name
valconv - VALID to Bartels Conversion
Synopsis
valconv projectname
Description
The
valconv utility program converts part lists and net lists from VALID format (i.e., VALID schematic output) to a BAE DDB (Design DataBase) file.
valconv accepts the BAE DDB destination file name
projectname as first argument. This file is created with extension
.ddb, but this extension must not be included with the command line.
valconv reads the VALID part list file
pstxprt and the VALID net list file
pstxnet. These files are generated by the VALID system and must reside in the current directory when calling
valconv.
After successful processing, a logical (unpacked) net list will exist in the BAE DDB file named
<projectname>.ddb. This internal logical net list can be converted to a physical net list with the
Packager, in the same way as information from the BAE schematic. A layout element can then be created in that design file, parts placed and traces routed, and it will also be possible to perform pin and gate swaps.
Files
pstxprt -- VALID part list
pstxnet -- VALID net list
See also
netconv,
Packager,
loglib
Diagnosis
The error messages issued by
valconv are intended to be self-explanatory.
Warnings
Input file identifiers for part names, pin names or net names containing special characters
(-,
+,
/,
(,
=, ...) must be enclosed in single-quotes or double-quotes. Please contact our technical support for guidance if you want to transfer a net list format different from the description herein .
Utilities
© 1985-2025 Oliver Bartels F+E • Updated: 26 January 2007, 17:23 [UTC]
|
