Table of Contents
TopEd Layout Language - a C-like code for layout scripting. The initial idea behind TELL was to serve as a macro language to improve the interface and to facilitate the work with Toped. During the design of the layout editor the initial intentions evolved into the idea to create a script able to code the layout. Indeed a good amount of manual layout work can be relatively easily generalized and automated if the user possesses a convenient tool. Besides such a script would produce a layout according to a set of predefined design rules (DRC), thus minimizing human errors and reducing the design checks and the time for back end design operations in general. Having a similar tool the designer can parametrise the layout generation and to make it virtually (or at least partially) independent of the design rules.
The idea of course is not new - silicon compilers, parametrised cells etc. - all this sounds quite the same. TELL does not have the ambition to be a silicon compiler. It is rather trying to be the tool, that will bring some benefits in the manual layout process right now. In the same time the language seems to be able to evolve in order to serve as a bridge between the front end and back end design process. Routing algorithms, netlist parsers, logic synthesis, standard cell layout libraries - all of them can benefit from using a similar language.
- Script or language
- These two terms are used interchangeably throughout the documentation. In strict terms TELL is a script.
- Interpreted or compiled
- Being a script usually means that it is interpreted. The main reason for interpretation is actually the primary purpose of TELL - to serve as a macro language during manual layout operations. Despite this, all function definitions are translated into an internal intermediate code during the parsing phase. That code is executed when the function is called. If an error in the function body is found during the parsing, the function is not translated and can not be called. It is perfectly possible to store that internal code in the graphical database. This will be used to impliment parametrised layout cells.
- TELL and layout data
- It has to be clear that TELL is not a placeholder for layout data. TELL is a command script for generation and manipulation of such data, but it does not store it. You could look at it this way: TELL is like a broadband connection for a computer - it makes the whole process easier but ultimately it is a part of a larger picture. The TELL interpreter is build into the layout editor, and Toped is the one, that takes care of generated data. In the same time TELL is perfectly capable of referencing layout data from the Toped database via a dedicated type. Referenced data can be modified or used in any other convenient way. In result forward and backward connection between TELL and the layout database is ensured.
- Syntax and semantics
- One of the main ideas behind TELL was to create a script that looks familiar and is at least a bit intuitive, a script for everyday use with minimum learning time. A C-like syntax was chosen with very few additions and modifications. The main reason was that most of the designers have seen C or Perl and they don't have to learn a new syntax. The semantics however must serve well to the purpose of the language.So in brief TELL is a structured script with strict type-checking, introducing some layout specific build-in types.
- TELL parser
- As mentioned above the TELL interpreter is build into the layout editor. The parser itself is a separate module written on Bison (yacc). As a rule all TELL constructs are defined within function boundaries. No function code is executed during parsing - instead, the parser creates a sequence of internal instructions in the memory - like an object code - that is actually executed when the function is called. This code is created once - during the parsing phase - and is not destroyed until the editor is running. There is a single, but important exception to this rule - TELL constructs not belonging to any function are executed immediately and their code is destroyed after execution. The latter is to ensure the primary purpose of TELL - as a macro command language of the editor.
- Comment sequences can be two types
-
single line comment -
//Its validity is up to the end of the line. -
multiline comment - everything between
/*and*/
-
single line comment -
- Pre-processing
- only #include is available. No preprocessor variables and conditional parsing. Environmental variables in the file paths are recognized and properly expanded.
/*
The following lines demonstrate the use of prepocessor
include command which recognises environmental variables
*/
#include "topedmain.tll"
#include "$TPD_LOCAL/tll/seed.tll"
#include "$COMMON_POOL/opamp.tll"
// end of demo codeAll the keywords that are not describing a data type are listed below. The description is quite brief, because the behavior of the statements is supposed to be familiar.
The conditional statement working in the expected manner. Second part - else - is optional. The expression in brackets after if must be of type bool.
if (a == 1) {echo("test OK")} //
else {echo("test FAIL")};Forces a return from a function and might be used to transfer a value back to the calling routine. Return outside the function boundaries is illegal.
return ((0,0)); // return statement of a function of a type point return; // used in functions of type void only
![[Warning]](images/warning.png) | Warning |
|---|---|
Currently the parser is not flagging an error if some of the function exit paths does not contain return statement. The result of such code is unpredictable. |
Traditional pre-conditional loop. The conditional expression must evaluate to true in order to execute the operators block
real a = 10;
while (a > 0) {
echo(a); a = a - 1;
};Traditional post-conditional loop. This is an exception of the C syntax. Cycle loops until the conditional expression is true.
real a = 10;
repeat {
echo(a); a = a - 1;
} until (a > 0);