CoreDoc.tioga
Copyright Ó 1987 by Xerox Corporation. All rights reserved.
Bertrand Serlet, July 18, 1987 6:37:26 pm PDT
Barth, July 31, 1986 2:53:50 pm PDT
CedarDummy, September 18, 1986 3:13:54 pm PDT
Bland, April 23, 1987 10:02:51 am PDT
Core
CEDAR 7.0 — FOR INTERNAL XEROX USE ONLY
Core
Bertrand Serlet
Abstract: Core is a common set of interfaces for exchanging information between different DA tools. It is also used to capture the designer's intents at a high level.
Created by: Bertrand Serlet, Mike Spreitzer and Rick Barth
Maintained by: Barth <Barth.pa>, Serlet <Serlet.pa>, Spreitzer <Spreitzer.pa>
Keywords: ChipNDale, Design Automation, Tools Integration
XEROX  Xerox Corporation
   Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, California 94304

For Internal Xerox Use Only
Design
Traditionally design aid systems have used a computer's file system to communicate design information between the various tools which make up the system. Each tool typically has its own file format which results in a massive file conversion problem and low bandwidth communication between tools. We have chosen to communicate design information through a data structure, called the Core data structure, which is stored in a computer's main memory. This results in much tighter coupling between the tools and, because of the elimination of the code which reads and writes files, substantially reduces the complexity of writing and maintaining a tool.
The Core data structure represents a hardware design as a hierarchical decomposition into primitive elements. For integrated circuits the primitive element is the transistor and thus the Core data structure is describing a transistor net list. The Core data structure is easily extended to allow a user to capture his design at whatever level of abstraction is appropriate for the design. Procedural translation from abstract descriptions into transistor net lists allows the designer to introduce new abstraction mechanisms without introducing the new abstraction into each tool in the design aid system.
We cannot use a text editor to directly enter a design since Core is not a document file format but a data structure. Instead we have supplied a procedural interface so that a program can be written, by using a standard text editor, which generates the Core data structure. We also prefer to describe much of a hardware design graphically, using an existing graphics editor, rather than textually with programs. We have built a tool which allows graphical and program descriptions of a design to be freely intermixed so that the one which most clearly describes a portion of a design can be chosen.
Package Structure
The most interesting interfaces to look at are:
Core.mesa, which defines the basic data structure
CoreOps.mesa, which defines functions for working on Core data structures
CoreClasses.mesa, which defines the standard classes of Core objects
CoreProperties.mesa, which defines the framework for Core properties
CoreCreate, which is some sugar for designers who create a program generating Core
CoreFlat, which defines functions for flattening a hierarchical description
CoreIO, which defines functions to save Core data structures on file.
CoreDirectory, defining libraries of Core objects, and a global name space for libraries.
BitOps, for standardizing manipulations of bits in the DA system.
Additional Documentation on the Core Data Structure
[DATools]<DATools7.0>Core>CoreDescription.tioga contains a detailed description of the core data structure. It includes sections on each of the data types that make up Core and discusses the mechanisms used for the inheritance of properties.
IO Principles
No truth goes on a Core file! Core IO is just a speed up for saving the result of some computation, and reading it later without paying again all the cost of the computation. ChipNDale and Tioga are the only way to save source information.
Editing / Modification Principles
Core does not supply any editor. Input is ChipNDale, plus some Core program able to make sense out of a ChipNDale picture, such as an extractor. There is in Core no primitive to propagate changes and modifying in place objects such as Wires and CellTypes should be restricted to property list changes. Names have a special status in the sense that some functions require caches in order to obtain decent efficiency, and that means that changing names requires flushing some caches.
Interface Documentation
This section contains documentation which should be folded into the interfaces someday.
CoreOps.Print should mention it knows how to print SymTabs.
Test of the package [for maintainers only]
The program TestCore.mesa (started with TestCore.cm) shakes a bit Core functions. As new functionnality are added (or removed!) in Core, it is hoped that some code to test them will appear in TestCore.mesa. A test file tests separately the IO (TestCoreIO.cm).