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 -- all further contents encoded with TokenIO xChipndaleFile: TokenIO.INT = 12121983; -- describes "TokenIO-File as a Chipndale .dale file" xVersion: TokenIO.INT = 0; -- describes version of Chipndale's encoding technology-key: TokenIO.ATOM; technology-name: TokenIO.ROPE; -- all further contents encoded according to implementation of technology list of technology's prefixes as encoded by the Technology the actual design, standard encoding, augmented by the Technology Design's Cell directory Design's contents pushFlag[key of object] popFlag XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Chipndale's TokenIO Module This module does NOT import Chipndale, but Chipndale imports TokenIO. DIRECTORY IO, Rope; TokenIO: CEDAR DEFINITIONS = BEGIN Mark: TYPE = REF MarkRep; MarkRep: TYPE; WritingStopped: SIGNAL; StopWriting: PROC [] = INLINE {stopWriting_TRUE}; stopWriting: PRIVATE BOOL; 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 [ kind: TokenType, ref: REF_NIL -- either ATOM, Rope.ROPE, REF INT or NIL (Rope.ROPE or NIL if error) ]; ReadToken: PROC [] RETURNS [Token]; ReadAgain: PROC []; EncodingError: ERROR; ReadInt: PROC [] RETURNS [INT]; ReadAtom: PROC [] RETURNS [ATOM]; ReadRope: PROC [] RETURNS [Rope.ROPE]; ReadPushFlag: PROC [] RETURNS [ATOM]; ReadPopFlag: PROC []; 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 []; 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 ´--defaultExt is appended to name, if name does not already has an extension --encoding of typical object --encoding of objects internal data ...... encoded according to object own implementation -- TokenIO.mesa -- by Christian Jacobi August 24, 1983 3:10 pm -- last edited by Christian Jacobi January 31, 1984 11:29 am -- causes next call of Write or Update to signal WritingStopped -- (inside monitorlock; may be resumed or aborted) -- AttachWriter invalidates a call of WritingStopped -- inline for speed reason only -- kind = atom => ISTYPE[ref, ATOM] -- kind = int => ISTYPE[ref, REF INT] -- kind = rope => ISTYPE[ref, Rope.ROPE] -- kind = pushFlag => ref=NIL or ISTYPE[ref, ATOM] -- kind = popFlag => ref=NIL -- kind = endOfStream => ref=NIL -- kind = error => ref=NIL OR ISTYPE[ref, Rope.ROPE] -- cause next call of ReadToken to get the same value as the last read -- works only one level deep (reads again only the last value returned by ReadToken) -- all read procedures ERROR EncodingError if read token is not as expected -- Attaching TokenIo to STREAMS -- while TokenIo is attached to a stream no other operations on this -- stream should occur -- also invalidates marks -- 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 ʹ˜Jšœ ˜ J˜0J˜J˜J˜J˜JšÐbx$˜$J˜J˜LJ˜qJ˜J˜æJ˜J˜ˆJ˜Jšœµ˜µJ˜J˜AJšÏbA˜AJ˜J˜ýJ˜J˜¨J˜J˜AJšž˜J˜J˜J˜1JšœJ˜JJšœV˜VJ˜J˜AJšž ˜ J˜J˜äJ˜š œ Ïn œÏkœ œ œ œ˜UJšœK™K—J˜J˜AJšœ˜Jšž˜J˜J˜óJ˜Jšœ œG˜YJšœ œ.˜@˜JšÏc,œ˜-Jšœ œ  œ6˜]Jšœ œ œ,˜GJšœ œ˜Jšœ œ˜˜Jš¡Iœ˜JJ˜:J˜A˜J˜J˜˜Jšœ™˜Jšœ#™#Jšœ5™5—J˜———J˜—J˜J˜AJšž˜J˜EJ™Jšœ™Jšœ.™.Jšœ<™