[Indigo]<Dragon>DBus>DBus.mesa!2

DBus.mesa

Barth, December 17, 1986 12:58:49 pm PST

DIRECTORY Core, CoreFlat, Rosemary;

DBus: CEDAR DEFINITIONS = BEGIN

Theory

This program adds the proper wires to a Core structure so that a DBus is properly wired.

Treats any cell type having the property $DBusData as a leaf state cell. If the wires referenced by DBusDataRec are not already public they will be added to the public of the leaf state cell.

A cell type having the property $DBusControl must be reachable from the root cell type. This cell must have the property $DBusData.

This program wires the control wire of the cell with $DBusControl to the control wire of all leaf state cells. It is willing to accept an arbitrarily structured wire for the control wire.

If no order is supplied then the program wires the out wire of DBusControl to the in wire of the first leaf state cell it finds, the out wire of the first leaf state cell it finds to the in wire of the next leaf state cell it finds and so on until there are no more leaf state cells at which time it wires the out wire of the last leaf state cell to the in wire of DBusControl. If there are no leaf state cells then it wires the out wire of DBusControl to the in wire of DBusControl. Adds all the public and internal wires necessary to accomplish the job.

CAUTION! Since this program changes the public wires of cell types it must also fix the actual wires of every instance of a changed cell type. This means that all instances of any cell type which are changed by this program must be reachable from the root cell type passed to the wiring procedures.

If an order is supplied then the program wires the leaf state cells in the order of the enumeration.

It is legal for portions of the DBus to be prewired. When a cell type is found with in unwired and out wired the program will complete the stitch to the in wire and then follow the existing links until it finds a cell type with no out wire and then continues as stated above.

The Core which has the bus wiring must be preserved since it is only through this data structure that the order can be interpreted after manufacture. This means every time a chip with a DBus is fabricated a .core file should be archived in addition to a .dale file.

Problems and Notes

Change all the state containing icons in Logic to take DBusName as a parameter, default it to NIL, pass it down to Logic.FlipFlop which should generate in, out and control if not NIL.

What about tristate drivers controlled by state? During shift the random patterns could cause multiple drivers to come on with disastrous results. Somehow nDFreeze must be factored into the equasions for any buses where this matters.

The requirement for archiving a .core file means that some truth is being stored in a .core file. This contradicts the notion that a .core file is only a cache.

Given a .core file and the appropriate cutset a simulation can be generated that has a piece of state for every element of a DBus that can be loaded with just a few tweaks to the simulation procedures and some knowledge of the Rosemary data structure. Then the normal simulation value inquiry mechanisms can be used to explore the state. The .core file indicates the order of the DBus just by looking at the wires. No external DBus order data structure need be pickled.

Types

ROPE: TYPE = Core.ROPE;

Wire: TYPE = Core.Wire;

CellType: TYPE = Core.CellType;

DBusData: TYPE = REF DBusDataRec;

DBusDataRec: TYPE = RECORD [

name: ROPE ← NIL,

control: Wire ← NIL,

in: Wire ← NIL,

out: Wire ← NIL];

DBusContents: TYPE = REF DBusContentsRec;

DBusContentsRec: TYPE = RECORD [

bits: PACKED SEQUENCE size: NAT OF BOOL];

Wiring

WireDBusGivenOrder: PROC [root: CellType, busName: ROPE, orderProc: OrderProc];

OrderProc: TYPE = PROC RETURNS [CoreFlat.FlatCellTypeRec];

The enumerated cells are wired into a DBus in the order of the enumeration. The value of the DBusName and DBusControl atoms are checked against busName. If they are not Rope.Equal then an error message is issued.

WireDBusComputeOrder: PROC [root: CellType, busName: ROPE];

busName determines which DBusControl cell type to use for the root of the DBus and to select which leaf state cells are to be wired into the bus.

Examination

LoadSimulation: PROC [simulation: Rosemary.Simulation, contents: DBusContents];

Throw the contents into the simulation.

END.

The following was removed from the interface to discourage people from using the DBus for loading arbitrary constants. In the June87 machine this discouragment is good to avoid burdening the boot ROM with junk that could just as well be loaded via the DynaBus. These functions could be useful in the future if people want to build chips that are embedded in systems that do not provide a convenient method of programming chips and would like to put some sort of ROM someplace in the system to program these constants during reset. Commercial chips of this sort already exist.

Cells

SoftConstant: PROC [b: NAT, v: INT] RETURNS [ct: CellType];

"Vdd", "Gnd", Seq["Output", b], "LSSDCtl", "DIn"

This type of constant can be loaded via the DBus. It is merely a string of flipflops and so the last shift sequence prior to deasserting nDFreeze must leave the correct value in those flipflops. Soft constants allow the placement software to rearrange the order of their bits in the scan path. Bit 0, the high order bit, is shifted out first. The value supplied is used during reset.

FirmConstant: PROC [b: NAT, v: INT] RETURNS [ct: CellType];

"Vdd", "Gnd", Seq["Output", b], "DOut", "DIn"

This type of constant can be loaded via the DBus. It is merely a string of flipflops and so the last shift sequence prior to deasserting nDFreeze must leave the correct value in those flipflops. Firm constants do not allow the placement software to rearrange the order of their bits in the scan path. Bit 0, the high order bit, is shifted out first. The value supplied is used during reset. DOut is the high order bit of Output.

HardConstant: PROC [b: NAT, v: INT] RETURNS [ct: CellType];

"Vdd", "Gnd", Seq["Output", b], "DOut", "DIn", "Shift", "Execute"

The value of this type of constant is fixed by the fabrication of the device and can be read by the DBus. Execute enables loading the pattern into a series of flipflops which are part of the scan path. Shift causes those flipflops to shift. Hard constants do not allow the placement software to rearrange the order of their bits in the scan path. Bit 0, the high order bit, is shifted out first. DOut is the high order bit of Output.