SexDoc.tioga
Louis Monier November 6, 1985 10:46:18 am PST
SCHEMATIC EXTRACTOR
CEDAR 6.0 — FOR INTERNAL XEROX USE ONLY
Schematic Extractor
Graphical Design of Logical Structures
Rick Barth, Louis Monier
© Copyright 1985 Xerox Corporation. All rights reserved.
Abstract: The schematic extractor allows graphical input of Core structures. It allows free mixing of algorithmically defined cells (StructureProc) and ChipNDale schematics cells.
Created by: Rick Barth and Louis Monier
Maintained by: Rick Barth <Barth.pa> and Louis Monier <Monier.pa>
Keywords: Schematic extractor, Core, ChipNDale
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304

For Internal Xerox Use Only
1. Concepts
Remember that we try to build a Core structure, or cellType, and that typing in the program which generates it is not fun. Hence a graphic description using ChipNDale CMosB technology to describe the simplest cells. More complex cells showing some algorithmic activity are described by a procedure, and everything is designed so that there is no difference between these two modes of description.
Every cell type can be represented in two ways: Schematic Cell or Structure Procedures.
Structure Procedures
Structure procedures create the implementation of cellTypes algorithmically. If a cell of the proper name cannot be found in the ChipNDale design then the extractor looks through the registry of structure procedures for one of the correct name and calls it. The name space for these procs is global and the table is part of CoreCompose.
StructureProc: TYPE = PROC [context: Context] RETURNS [cellType: Core.CellType];
Given a context (think of it as passing untyped arguments), it computes the implementation.
RegisterStructureProc: PROC [name: ROPE, proc: StructureProc] RETURNS [ROPE];
CreateStructure: PROC [name: ROPE, context: Context] RETURNS [Core.CellType];
For your enlightment, here is an example, the oh-so-famous shift register cell:
BigCell: ROPE = RegisterStructureProc[name: "BigCell", proc: CreateMyBigCell];
CreateMyBigCell: StructureProc = {
cellType ← CreateRecordCell[
name: BigCell,
context: context,
public: CreateWires[context, "Vdd, Gnd, ShRInput, ShROutput, Clock"],
onlyInternal: CreateWires[context, "wireInBetween"], -- not a public wire
instances: LIST [
-- Inverter has been defined already
[type: CreateStructure[name: "Inverter", context: context],
-- notice the implicit binding of Vdd and Gnd
actual: "Input: wireInBetween, Output: ShROutput"],
-- The pass transistor
[type: CreateTransistor[name: "Transistor", type: nE],
actual: "gate: Clock, ch1: ShRInput, ch2: wireInBetween"]]];
PWCore.SetAbutX[cellType: cellType]; -- order of instances is important here
};
Schematic cells
Schematic cells are definitions of Core cellTypes of the same name. Most of the time, they implement a record cell (or sequence cell).
A schematic cell contains instances of: rectangles, iconic cells (other ChipNDale cells), satellites (Text) and pins. They relate to the Core components as follows:
Rectangles
Rectangles (comment layer in CMosB) are used to describe wires. They follow the old Sil convention: two rectangles are connected if one end touches another rectangle anywhere, but crossing wires are not connected. Maybe we should have a dot (special symbol for contact).
A rectangle may carry a descriptor (rope on a satellite) which specifies the structure of the wire. The syntax of the rope is described in CoreCompose. Internal wires have declarative ropes, which explain how to make wires and how to name them. Actual and public wires have selective ropes, which describe which parts of existing internal wires to use to make them. Public wires must be connected to pins.
Connection by name: several non-connected sets of rectangles may represent the same wire if they have the same descriptor, or the same name, or connect to pins with the same name.
Pins
Pins of a schematic or iconic cell represent the public wire. Assuming that a public wire is always a record, one must find at least one pin with the same name per element of this record.
Satellites
Satellites are pieces of text attached to the instances; the binding is specified interactively. An instance and its satellites is called a group, and a special command allows the selection of a whole group. Satellites are turned into properties during the extraction, and various short-cuts are used to simplify the syntax, for example by playing with the font of the text or the class of the master in the group.
Iconic cells
Iconic cells are just a symbolic representation of a cellType. Think of it as the definition, the implementation being a cellType. The name of an iconic cell is not relevant, and a given cellType might have several iconic representations. An iconic cell carries a property $IconNameProp, which is either the name of a schematic cell in the same design, or the name under which a StructureProc has been registered. We could also use a trick on name, such as "FooIconic" being iconic for the cellType "Foo", but that's tacky.
Pins: The pins of an iconic cell must match the public wire of its cellType, with the usual conventions.
Parametrization: Since schematic cells can be parametrized, the satellites of an iconic cell are turned into properties during the extraction, attached to the instance under the property $ForContext, and added to the context during the extraction of the instance. They should be thought of as parameters of a procedure call. The object corresponding to an iconic cell instance is really a function of its IconNameProp and of the context at the time of the call.
Caching: (not yet implemented) Every instance of an iconic cell can also have a name (under $CacheName), which is an entry in a cache associating such names with cellTypes. If one wants to share several cellTypes, and "knows" that the contexts in all cases are similar enough (i.e. the extraction of each instance would lead to the same cellType), then one can use the same name. The name can also be generated by program. More ambitious: if every iconic cell or structureProc knew about which parameters it uses, the caching could be done automatically.
2. User Interface
Commands
The following commands are accessed through the <Space-P> Program menu.
AssociateIcon - just prompt for a name and put the property $IconNameProp on the object.
BindSatellites - one non-text instance (master instance) and any number of text instances are selected. This command binds the pieces of text to the master instance. Double link: the master has a property [$Satellite, LIST OF CD.Instance] and the satellites have [$IsSatelliteOf, CD.Instance].
Q: do we sometimes want to put satellites on objects instead of instances ?
SelectGroup - you select an instance (master or satellite), and this command finds all the other members of the group and displays them selected.
Extract - you select an instance of a schematic cell (why this restriction?), and this command returns the cellType. Any algorithmic definition should be running. The resulting cellType is attached to the instance under the property Sinix.extractedCoreProp
PutUnnamedPropOnInstance - puts property $UnnamedProp onto the selected instance with value the same as the "Value:" field in the control panel. Useful for properties whose value can be determined completely from context. Puts a text object in the design at the position the mouse was clicked. Inserts an association.
PutUnnamedPropOnObject - same as PutUnnamedPropOnInstance but indirects to object instead of applying directly to instance.
Graphical Display
Wire constructor
Bozzo!
Reserved properties and short-cuts
Some of the properties are predefined by the extractor:
$t: attached to a wire the value of this property is a rope which is the name of a ChipNDale cell that has a single public wire which is used as the type of the wire to which the property is attached.