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.

The most interesting interfaces to look at are:

[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.

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.

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.

This section contains documentation which should be folded into the interfaces someday.

CoreOps.Print should mention it knows how to print SymTabs.

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).