Search
»»»Home «««
Framework
Screenshots
FAQ
»»»TELL «««
Types
Operators
Functions
Example
»»»Toped «««
Database
Cells
Add
Select
Edit
Properties
Rendering
GUI
Miscellaneous
»»»Ifaces «««
GDSII
OASIS
CIF
DRC

Toped reference

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.

Environment variables

$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/fonts directory. 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/log if 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

Command line

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]toped [parameters] [<tell_file>]

List of parameters

-ogl_safe
forces the usage of the basic renderer (See rendering)
-I<path>
Expands the search paths of the parser. Multiply parameters of this kind are acceptable. Each of them shall contain a single path. The parser gives priority to the paths set by this command line parameter over the contents of the $TLL_INCLUDE_PATH
-D<macro>
Defines a preprocessor macro Equivalent to define macro in the code
-D<macro>=<replacement>
Defines a preprocessor macro Equivalent to define macro replacement in the code

Both versions of the -D parameter can be submitted many times.

Validation

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.

[Tip]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.

Box

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.

Polygon

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.

Wire

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.

References

There is no particular optimizations for cell or array references

validation
  • circular references (critical) - not allowed.

top

Undo

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.

[Tip]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.

top

Session logs

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.

[Tip]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.

top

Crash recovery

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.

top

File time stamps

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.

[Tip]time stamps

"DD-MM-YYYY HH:MM:SS"

DD
day
MM
month
YYYY
year
HH
hours
MM
minutes
SS
seconds

Script debugging

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.

top