 |
|
|
|
JELIB files are text-readable files. Each line of a JELIB file starts with an identifying character that distinguishes the line. Blank lines, and those that start with the comment identifying character (#) are ignored. There is no limit to the length of a line of text.
After the identifying character at the start of a line, there are a set of fields. All of the fields are separated by the separator character (|) except for the first field, which begins immediately after the identifying character. No blank spaces are allowed on a line (that is, any blank spaces are treated as valid characters). Control characters (such as the identifying characters) must be upper case. In order to insert a '|' or '\n' or '\r' into a field, it must be enclosed in the quotation mark characters ("). Backslash character can be used inside enclosed strings to denote special characters:
Each of the different types of lines in the file has a fixed set of fields that must appear. Some line types also allow additional fields at the end to add variables (attribute/value pairs, see Section 10-4-1).
The JELIB file has 3 parts: the header, cells, and trailer.
The header has these elements:
| H | Header information; variable fields are allowed |
| V | View information |
| L | External library information |
| R | External cell in the above external library |
| F | External export in the above external cell |
| T | Technology information; variable fields are allowed |
| O | Tool information; variable fields are allowed |
The cells have these elements:
| C | Cell header; variable fields are allowed |
| N | Primitive node information in the current cell; variable fields are allowed |
| I | Cell instance information in the current cell; variable fields are allowed |
| A | Arc information in the current cell; variable fields are allowed |
| E | Export information in the current cell; variable fields are allowed |
| X | Cell termination |
The trailer has this optional element:
| G | Group information |
Everything in the file is completely ordered. There is an ordering to the external libraries, cells in those libraries, technologies, tools, cells, nodes/arcs/exports in a cell, etc. Even the extra variables on a line are ordered. The ordering is usually a name sort. By ordering everything in the file, the exact same file is generated every time, and text comparison operations will accurately find differences between two files. Note, however, that the JELIB reader does not require any sorting, and can handle the data in any order.
In order to enable CVS version control (see Section 6-13) Electric also has a "delib" format. This format is actually a directory (with the ".delib" extension) that contains multiple "jelib"-format files. Each of the files in a "delib" directory contains a single view of a single cell (although it may contain multiple versions of that cell). Instead of naming these files with the "jelib" extension, they use the cell name for their file name and the cell view for their file extension.
The cell-files in a "delib" directory have no "V" (views), "T" (technologies), "O" (tools), or "G" (group) lines
(see above).
Instead, these lines appear in a separate file called "header",
which also has a copy of the "H" line.
Where "C" (cell) lines should appear, the "header" file contains this text:
C____SEARCH_FOR_CELL_FILES____
For example, assume that library "X" has cells A{lay}, A{sch}, and two versions of cell B{lay}: B{lay} and B;1{lay}. When written as a "jelib", all four of these cells will be stored in the file "X.jelib". When written as a "delib", there will be a directory called "X.delib" with the files "A.lay", "A.sch", "B.lay" (with two cells in it), and "header".
When a cell is deleted from a library, its "delib" file is not deleted, but is retained for archival purposes. To mark it as deleted, however, it is renamed so that it has the extension "deleted."
 |
Previous |  |
Table of Contents | Next |  |