Table of Contents
Toped is driven by TELL input commands, described in the following chapters. There is a functionality however, specific to the editor, like session log files, script debugging, undo, etc. which is often executed behind the scene, but is important for the editor performance. The current menu and dialog boxes are not described, because their purpose is supposed to be obvious.
-
$TPD_GLOBAL -
Should point to the installation directory where the additional data
from the package is installed. Toped will search for glf font files
in
$TPD_GLOBAL/fontsdirectory. If a font files are not loaded in the begining of the session the program might be unstable. -
$TPD_LOCAL -
Should be user specific and should point to an existing directory.
All log files will be stored in directory
$TPD_LOCAL/logif it exists or in the current directory if it doesn’t. See session logs for further information. Toped will issue a warning message in the begining of the session if this variable is not defined. -
$TLL_INCLUDE_PATH - Defines the search paths of the parser. Directories where included TELL files are located can be added using this variable. The recognised format is the same as for similar path variables in gcc compiler
Example 1. Define Toped environment
TPD_LOCAL=/home/myusername/toped_local TPD_GLOBAL=/usr/local/toped export TPD_LOCAL TPD_GLOBAL TLL_INCLUDE_PATH=/opt/toped/tll:/home/myusername/toped/local/tll export TLL_INCLUDE_PATH
The command line format is pretty simple. Apart from the parameters described below the user can set a tell file which will be executed immediately after the tool boots-up.
![[Tip]](images/tip.png) | toped [parameters] [<tell_file>] |
|---|---|
List of parameters
|
Both versions of the -D parameter can be submitted many times.
For the proper editor functionality, it’s important to have valid layout objects. To achieve this, Toped checks and validates all layout objects as soon as they are added to the database or edited by some of the TELL operations. Invalid objects are divided into two categories:
- critical - rejected with an error message in the log window.
- recoverable - can be automatically converted into equivalent shapes on the spot, or marked as invalid shapes, but allowed into the database. The latter can be stored in the GRC DB and later converted to valid objects.
Validation implies also internal optimization of the layout object, which is done silently. Checks executed for each layout object type are listed below. No checks are implemented for text objects.
| Acute angles |
|---|---|
In the early versions of Toped all polygon angles < Pi/2 were considered illegal. In ver. 0.8 the validation checks were lightened up and acute angle checks were removed. It is assumed, that control of acute angles is not a subject of the layout editor. |
- optimization
- Box is always represented by two corner points - bottom left and top right strictly in this sequence.
- rotated boxes - converted internally to a polygon.
- validation
- null area (critical)- box will be rejected if the X or Y coordinates of the corner points coincide.
Toped considers that polygons are always closed. This means that when polygons are added the first and last points of the polygon description don’t need explicitly to coincide.
- optimization
- identical neighboring vertexes are cleared, including start/stop points
- midline points are removed - if the angle between two polygon edges is 0 or Pi, the common vertex is removed.
- box conversion is performed if possible, e.g. if the polygon forms a valid box
- anticlockwise winding - polygon vertexes are stored always in anticlockwise order, so input points are reordered if necessary.
- validation
- null area (critical)- polygon should cover an area bigger than zero
- self crossing (recoverable) - none of the polygon edges should cross each other. They can coincide though - partially or fully.
- optimization
- identical neighboring vertexes are cleared
- midline points are removed - if the angle between two polygon edges is Pi, the common vertex is removed.
- validation
- null area (critical)- wire should cover an area bigger than zero
- wide wire (critical)- wire width is bigger than the maximum allowed (currently 0x0FFF_FFFF)
- self crossing (recoverable) - none of the wire central lines should cross each other. They can coincide though - partially or fully.
- short end segments (recoverable) - wire end segment is shorter than half the wire width.
There is no particular optimizations for cell or array references
- validation
- circular references (critical) - not allowed.
Undo is a powerful engine build into Toped for all internal functions which modify the layout database. For user defined functions, undo works on a step by step basis, e.g. to undo a single call to a user function, one might have to repeat undo command multiple times. The depth of the undo stack is not limited, however for long sessions it might take significant memory resources. That’s why an additional field is provided in the Toped options menu, so that the user can limit the depth of the undo stack.
| Undo scope |
|---|---|
Undo doesn’t deal with TELL variables and Toped user interface, but only with internal Toped functions. If a TELL variable has been defined or its value has been changed, this can’t be undone. Every change in the Toped layout database however should be reversible. |
At the beginning of every session, Toped normally creates a file called tpd_session.log where all successfully executed TELL functions are recorded. When the session is exited normally, the file is renamed to tpd_previous.log. The program is always trying to put the log files in directory $TPD_LOCAL/log. If $TPD_LOCAL is not defined or $TPD_LOCAL/log does not exists, then the log files are placed in the current directory. A warning message will appear in the console.
| log file and Toped console |
|---|---|
The contents of the log file is not the same as the contents of the Toped log window. The latter is the main program console and all messages are also displayed there. The Log file contains only commands. No TELL variables or Toped messages. |
In case the session crashed or was aborted abnormally tpd_session.log file will remain in the current log directory. The next program session will find the file and will ask for permission to recover previous session. After a successful recovery, tpd_session.log will be updated with the commands executed in the current session.
If recovery was declined, tpd_session.log will be renamed to crash_<YYMMDD_HHMMSS>.log where YYMMDD_HHMMSS is the time stamp of the current session. Crash files are not cleaned-up by Toped.
Recovery normally doesn’t need any manual corrections in the log file. If this has to be done though, beware that when in recovery mode Toped executes all TELL commands in a single thread. This implies that log files don’t contain any interactive commands which usually require miltithreading (e.g. getpoint()). There are no such restriction for regular tll files.
For log and recovery purposes, time stamps are introduced in the TDT files, log files and TELL commands. A time stamp in TELL is represented by a string formatted as described below.
| time stamps |
|---|---|
"
|
There are no script debugging tools at present. Run time error policy still has to be clearly defined. The only function that can be helpful here is the echo( .. ) function, that takes a single argument of any type and prints its value on the log window.