RosemaryDoc.tioga
Rick Barth, February 11, 1987 1:01:51 pm PST
Jean-Marc Frailong December 26, 1987 7:28:25 pm PST
ROSEMARY
CEDAR 6.1 — FOR INTERNAL XEROX USE ONLY
Rosemary
Rick Barth
© Copyright 1985, 1986 Xerox Corporation. All rights reserved.
Abstract: Rosemary is a simulator.
Created by: Rick Barth
Maintained by: Barth <Barth.pa>
Keywords: Simulation
XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
For Internal Xerox Use Only
Introduction
Rosemary is a simulator. It depends upon the Core structural description mechanism. I really ought to write some good documentation about it some day. In the meantime here are a few scratches to help out.
Rosemary is split into two pieces represented by the interfaces Rosemary.mesa and RosemaryUser.mesa. Rosemary is the interface to the simulation engine and RosemaryUser provides procedures for creating a user interface. People who do not like to have RosemaryUser control their simulations may still make use of the facilities for displaying values and the typescript.
Simulation Algorithm
The basic simulation algorithm is the same as MOSSIM II as described by Bryant in "A Switch-Level Model and Simulator for MOS Digital Systems", July 28, 1983. It has been enhanced to allow behavioural models to be written in Cedar. Each time Rosemary.Settle is called, either directly by client code or indirectly by a call to Eval in a RosemaryUser.TestProc, the simulator attempts to find a steady state solution to the set of fixed point equations implied by the network described by the source Core. It will continue to do so until a solution is found or the process is aborted. RosemaryUser provides an additional mechanism for aborting an oscillating simulation.
Behavioural procedures can be written to model abstract blocks. A state initialization procedure may be provided and an evalution procedure must be provided. The evaluation procedure must compute a combinatorial function of the inputs and the old state to produce the outputs and the new state. On each call to an evalution procedure Rosemary supplies a port containing the current value of each of the wires to which the block is connected and a REF ANY. The REF ANY is whatever was returned by the initialization procedure. The job of the evaluation procedure is to fill in the port with a current strength and voltage level representing the value the block wants on wire.
The following algorithm expresses in pseudo code what Rosemary does when the start test button is pushed for a simulation created using the Extract And Rosemary menu selection.
For every Rosemary wire:
Initialize the Rosemary wire to X.
If the wire is atomic then insert it into the wire perturbed list.
For every abstract block:
Initialize the port from the InitPort data.
If an Init proc is supplied call it.
Insert the block into the abstract block schedule.
Call the test procedure.
For each call of Eval in the test procedure:
Copy the tester port into the simulation port.
Call CleanUp with the simulation port.
Until the abstract block schedule and wire perturbed list are both empty:
Until the abstract block schedule is empty:
Take an instance from the schedule.
Call its simple evaluation procedure.
Call CleanUp with the instance's port
Initialize the recomputed list to empty.
Until the wire perturbed list is empty:
Take a wire from the perturbed list.
Find all wires which are channel connected to this wire.
Remove all such wires from the perturbed list.
Compute the new levels on all such wires using the current values and the combined strength and level of the wire due to abstract blocks.
Add all such wires to the recomputed list.
For all wires in the recomputed list:
If the new value is not the same as the current value:
For all transistors whose gates are attached to this wire add the wires connected to both channels to the perturbed list.
Make the current value the new value.
Call UpdateReaders with this wire.
Check that all wires with boolean ports have not settled to X.
Check that all force and expect values in the tester port match the values in the simulation port.
CleanUp:
For each leaf of the passed port:
For each Rosemary wire which is connected to part of the port:
If the part of the port for this wire does not have the same value as it did on the last call to CleanUp then:
If the wire is atomic compute the combined strength and level of the wire due to abstract blocks and insert it into the wire perturbed list
else recompute the value of the wire. If the value is different from the old value call UpdateReaders with this wire.
UpdateReaders:
Insert all abstract blocks connected to this wire into the abstract block schedule and update their ports. If a port is boolean and the value is X then retain the old value in the port.
Instantiation Time
What's a cutset?
When does flattening stop?
Default behaviour
Default class name
Infinite wires
Don't use them for anything but Vdd and Gnd
Ports
What they are
Their use in behavioural procs vs. test procs
Ports.InitPort vs. Ports.InitTesterDrive
What happens during a test
Initialization
Test Proc is called
On each Eval
test port copied
settle invoked
test port compared to simulation port
Viewer
The Rosemary tester viewer is divided into 2 major areas:
1. The simulation control area provides the following buttons and informations:
1st line:
StartTest: start the simulation using the currently selected test procedure
Run State: feedback indicating the current simulation state
Evals Since Start: number of evals completed since simulation initiation
2nd line:
Abort: kill current simulation
Interrupt: interrupt curent simulation at end of current Eval
Single Eval: perform a single Eval step in simulation (must be interrupted or not yet started)
Proceed: resume current simulation (up to the value specified in Until if specified). Simulation must be interrupted.
Until: enter a number in this field to indicate the Eval at which simulation should be interrupted
Optional:
If there is more than one test procedure specified, a list of buttons (one per test procedure) appears here. Only one may be selected at a time, and it specifies which procedure should be used to start simulation using StartTest.
3rd line:
Trace: trace all internal Rosemary events on the simulation log (mostly to debug circularities)
Record: a choice button indicating what level of information should be recorded for later plotting:
Evals => record values at the end of each eval (normal mode)
MosSim steps => record value changes at the MosSim step level. This is useful to detect transitory signals or debug circularities. Using this option may result in a large amount of disk usage...
Nothing => nothing is recorded, precludes use of plotting/value display facilities. Use only if disk space is critical...
Plot: a choice button indicating the style of plot:
Evals => plot values as they are at the end of each eval; all signals change values simultaneously at the end of the eval, independently of the internal evaluation order (usual mode)
MosSim steps (all graphs) => display all values recorded (not only the last value for each eval) and show them with a time position correcponding to the MosSim step number at which they were first obtained. This permits to see the Rosemary evaluation order on the plot, and to access transitory values if recording used MosSim steps.
MosSim steps (waves only) => MosSim steps (all graphs) makes the values of non-waveforms signals almost unreadable due to overlapping. `Waves only' behaves as `all graphs' on signals displayed as waveforms, but shows only the last computed value in each Eval for signals displayed in hexadecimal format (thus hiding transitory values if any).
4th line (optional):
This line allows to control state checkpoints in Rosemary simulations. The code for this functionality has not been tested extensively...
2. The wire value area allows to see the values of certain wires (the list is defined at tester creation time) at the current Eval and provides shortcuts to typescript commands:
1st line:
Update: this button refreshes the wire value display if it becomes corrupted
2nd, 3rd line:
Instantiation Path: a prefix to all CoreFlat cell paths typed on the typescript
Current Wire: a prefix to all CoreFlat wires typed on the typescript
The effective arguments are obtained as:
flat cell == <Instantiation Path><Command argument>
flat wire == <Instantiation Path><Current Wire><Command argument>
3rd line and following:
A list of pairs (wire name, current wire value). The wire values are displayed when the Update button is clicked, or when the simulation is interrupted. The wires displayed in this area are defined at simulation instantiation time, and cannot be modified later.
When a tester is created, it is sized to show only the first area. You will need to adjust it to see the second area. In the case of client controlled simulation (no tester), the viewer will be opened to show only line 1-3 (and 1-4 if present).
Names
Rosemary uses the CoreFlat notion of names. The grammar for such names can be found in CoreFlat.mesa. Here are a few simple examples:
/0(CrossRAMPadFrame)/2(DifferentialInputPad) -- names an instance
/0(CrossRAMPadFrame).public.Address.0 -- names a public wire
Read -- names a top level internal wire
The instance paths have a list of instance names or indicies, followed by the cell type name in parantheses, seperated by slashes. The wire names have path names first followed by wire names or numbers seperated by dots.
Some commands take instance paths and others take wire paths. Those which take instance paths concatenate the Instantiation Path field with what is typed before parsing it with CoreFlat. Those which take wire paths concatenate the Instantiation Path field, the Current Wire field and what is typed before parsing.
Generally the only names which must be typed in are top level names. From there the commands in the typescript can be used to traverse the network with the use of secondary selection so it is not really important for the syntax to be easy to remember and concise, although the shortcuts which CoreFlat allows, but which are not documented, in fact make the syntax both memorable and concise.
Typescript
The typescript is a read-eval-print sort of user interface. It is also used to print messages which are asynchronously generated by the simulator. The prompt is not properly maintained in this case so you may have to hit carriage return occasionally to get your prompt back. Only the first letter of the command should be typed and it must be lower case. Each command expects a wire or instance path name to be typed after the command letter. If you type a command that it does not recognize it will print out a list of available commands. Here is a bit of explanation of some commands:
celltype - given a path name the procedure invokes CoreOps.PrintCellType on the celltype of the named instance.
value - print the current value of the named wire.
ports - print the current value of the wires connected to the named instance. A null path means the top level cell type. The port information used to determine the port types is also used to determine at which level of granularity to print the wire values.
trace - print the cell instances which are attached to the named wire, followed by the transistors which have a channel connection to it, followed by the transistors whose gate it connected to it. Each channel connected transistor prints the transistor type, followed by the wire connected to the other channel, followed by the wire connected to the gate. Each gate connected transistor prints the wires connected to both channels. When a wire is printed its name and current value are printed.
drivers - prints the same information as trace but includes all the information which Rosemary uses to evaluate. Normally this information is only useful to wizards.
state - given a path name the corresponding port and state record for the named instance are found, a process forked and a signal is raised to create a debugger window with the parameters "port" and "state" defined. Unfortunately all those wonderful little NAT's defined in the global frame of your simulation procedures are not available for expressions such as "port[Vdd].b". Such is life.
add - add the named wire to the wires displayed in the plot viewer. Currently only atomic wires may be displayed this way.
remove - remove the named wire from the wires displayed in the plot viewer.