dale.tioga

Christian Jacobi March 19, 1984 4:43:16 pm PST

Chipndale and Integrated Design Aids

I think it is well spend effort to try to integrate different design tool.

Chipndale does have some specific needs for communication, it might also offer some ideas for other design tools.

The main concern on any file-format used by Chipndale is Chipndale's technology independence. A technology (like NMos, or PC-Boards...) implements its own type of objects which must be representable on a design file. On the other side, the routines to generate output or to read in designs (.dale files) are in the technology independent part of chipndale.

Interchange of designs between programs is possible on file level or by importing modules. (At the present time?), however, it is a bad idea to access the design files of chipndale without using chipndale's IO routines to do it. The file format is finally defined by the implementation of different objects, which can not be frozen at any time (since new technologies can be implemented).

It might be worthwhile to split chipndale to separate the IO routines; however this split also goes through technologies, and what finally could be removed from the minimal environment would be only some parts executing user commands and the modules communication with the viewer package. This might be a nice exercise to improve the structure, but it wont result in a minimal configuration of chipndale which is anything like small.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

An open area where Chipndale could benefit from integration work:

Until now Chipndale suffers from the restriction that every cell of a design must be loaded with the design. I would like to extend chipndale in the sense that an object can be referenced which actually sits in a different file. (like a pad-library....)

Maybe it could be made similar to mesa: A definition file contains cells, sizes and pins; The actual cell with its structure could be found in an implementations file.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Files used by Chipndale

.dale files containing designs

.chip files containing designs in chipmonk format

.CDColorMaps files (in chipmonk's format) containing RGB values of colors

.CDColorPatterns files (in chipmonk's format) containing stipples to represent layers.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

File-Names

To generate a unique model about filenames and extensions, Chipndale uses always the same procedure to compute filenames from user typed filenames; (this procedure's implementation is 24 lines long, handles version numbers....).

CDExtras.AppendExt: PROC [name, defaultExt: Rope.ROPE] RETURNS [filename: Rope.ROPE];

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Format of a .dale file

The solution of reading unknown objects is to use flags to encode whenever an object representation on a file starts or ends. These flags contain the type of the object, which then allows proper reading of the object. To guarantee that the flags are properly recognized, even if an unknown object has to be skipped, all the information is encoded. Data and Flag can always be distinguished. Since an encoding is used anyway, we can use the encoding to represent common objects with short representation on files. (Chipndale's .dale files are slightly shorter than Chipmonks .chip files for the same design, even if Chipndale uses 32 bit numbers and Chipmonks only 16 bits.) The encoding is about how I did expect it to be good, but is not yet tuned.

xTokenIOCode: BYTE = 237; -- describes to TokenIO that this file is really a TokenIO-File

xVersionCode: BYTE = 1; -- describes version of TokenIO encoding

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Chipndale's TokenIO Module

This module does NOT import Chipndale, but Chipndale imports TokenIO.

-- TokenIO.mesa

-- by Christian Jacobi August 24, 1983 3:10 pm

-- last edited by Christian Jacobi January 31, 1984 11:29 am

DIRECTORY

TokenIO: CEDAR DEFINITIONS =

BEGIN

Mark: TYPE = REF MarkRep;

WritingStopped: SIGNAL;

StopWriting: PROC [] = INLINE {stopWriting←TRUE};

WriteInt: PROC [i: INT];

WriteAtom: PROC [a: ATOM];

WriteRope: PROC [r: Rope.ROPE];

WritePushFlag: PROC [a: ATOM←NIL];

WritePopFlag: PROC [];

MarkAndWriteInt: PROC [value: INT] RETURNS [Mark];

UpdateMark: PROC [mark: Mark, value: INT];

TokenType: TYPE = {atom, int, rope, pushFlag, popFlag, endOfStream, error};

Token: TYPE = RECORD [

ReadToken: PROC [] RETURNS [Token];

ReadAgain: PROC [];

EncodingError: ERROR;

-- all read procedures ERROR EncodingError if read token is not as expected

ReadInt: PROC [] RETURNS [INT];

ReadAtom: PROC [] RETURNS [ATOM];

ReadRope: PROC [] RETURNS [Rope.ROPE];

ReadPushFlag: PROC [] RETURNS [ATOM];

ReadPopFlag: PROC [];

-- Attaching TokenIo to STREAMS

-- while TokenIo is attached to a stream no other operations on this

-- stream should occur

Error: ERROR[why: Err, explanation: Rope.ROPE]; -- only on Attach or Release

Err: TYPE = {alreadyAttached, wrongVersion, other};

AttachReader: PROC [stream: IO.STREAM];

ReleaseReader: PROC [];

AttachWriter: PROC [stream: IO.STREAM];

ReleaseWriter: PROC [];

-- the routines may generate some standard IO signals and errors, however,

-- as few as possible

-- the Rope NIL and the Rope "" may read back correctly or exchanged

-- the ATOM NIL reads back correctly;

-- the ATOM "$" may be read back correctly or as NIL ATOM

END.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Modules of chipndale which could be of interest to other design tools

TokenIO: described above

TerminalIO: Procedures for input and output to the terminal

PopUpMenu: as name says