RosemaryDoc.tioga
Rick Barth, February 11, 1987 1:01:51 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 viewer which is put up by RosemaryUser is divided into 4 horizontal sections, not all of which may appear.
The first stripe controls the simulation. Start Test causes the selected test procedure to be called. Interrupt causes the simulation to halt after the completion of the next call to Rosemary.Settle. Proceed causes simulation to continue after it has reached the Interrupted state for some reason. Abort causes the test to be aborted. Log is a boolean button that causes each transition of a wire to be printed in the typescript when enabled. This is very useful for determining the cause of oscillating simulations. Single Eval allows the test procedure to generate one more test vector, calls Rosemary.Settle, and then stops. The Proceed Until text field can be filled with a number of evals at which the simulation is to be interrupted. The Run State field indicates if the simulation is running or has been interrupted. Note that the Run State will still say Running when the debugger has fielded an event which caused the simulation to be halted. If the viewer was created by a call to RosemaryUser.DisplayViewer then this stripe does not appear.
The second stripe allows selection of a test procedure. If there is only one test procedure then this stripe does not appear.
The third stripe displays the value of wires which were selected for display when the viewer was constructed. This stripe does not appear if no wires were selected.
The fourth stripe has the Update button which forces the wire values in the third stripe to be updated. This is particularly useful when the simulation is halted because the debugger has fielded an event. This stripe always appears.
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.