ChangesFrom2.8To3.0.Tioga
Last Edited by: Spreitzer, May 8, 1985 5:41:28 pm PDT
Changes from Rosemary2.8 to Rosemary3.0
Major Changes
There are two major changes, and a host of consequences (all good, it says right here):
The simple behavioral model (i.e., the stuff that's not switch-level) has been enhanced so that each cell says how hard it is driving on each simple port.
The node type checking rules have been changed from name equivalence to structural equivalence.
Due to the large number of small changes, this document only attempts to describe what's visible from ordinary use of Rosemary through the Translator. For more detail, talk to a Wizard.
The New Simple Behavioral Model
In addition to an IO record, each cell additionally has a drive array. The array is subscripted by an enumerated type whose elements are the names of the ports. Each element of the array is a RoseTypes.DriveLevel = {test, see, ignore, chargeWeak, chargeMediumWeak, charge, chargeMediumStrong, chargeStrong, chargeVeryStrong, driveWeak, driveMediumWeak, drive, driveMediumStrong, driveStrong, driveVeryStrong, input}. The first two drive levels are for use by test procedures. The third, ignore, says the cell is not driving at all. The next few are not likely to be used by cells, as they represent node capacitance ranges. The next few, driveWeak through driveVeryStrong, represent various strengths with which cells may drive the nodes they're connected to. The last drive level, input, is used to implement top-level inputs to a simulation.
A simple node now takes on the value assigned to it by the cell which is driving it most strongly. If more than one cell drives it with the same maximal strength, they must all assign it the same value. Alternatively, if no cell drives the node with a strength stronger than the node's capacitance, the node retains its most recent value.
In eval procedures, the drive array is accessed by the name "drive".
The New Node Type Checking Rules Model
A node may be connected to a port if the type of the node and the type of the port "conform". Two node types conform if they have the same structure. There are two kinds of structure available. Atomic structure is characterized by a Cedar ATOM. That is, two atomic node types conform if they have the same ATOM. All of the NumTypes, SwitchTypes, and EnumTypes have the same ATOM ($DigitalWire). BiasTypes have a different ATOM ($BiasWire). Array structure is characterized by a length (NOT starting and ending indices) and an element node type (which must be atomic). Thus, it is now possible to connect an 8-bit integer node directly to an 8-element switch-level port.
Minor Changes
For each cell type, there are now two different IO record types: simple, and switch. The simple record type contains fields whose types are the Cedar representations of simple node types; the switch record type contains contains fields whose types are the Cedar representations of switch node types. Most ports will have a field in both record types. This is used to implement Transducers, which are now automatic.
Test procedures now have to deal with two instructions records: one of the simple IO type, and one of the switch IO type. The two instructions record instances available in a test procedure body are named simpleInstr and switchInstr; simpleInstr is OPENed.
Test procedures can now interact in the simple behavioral model with switch-level ports of the cell under test. In fact, they can interact in either model on any port. Indicate which by asserting either (SimpleInstructions) or (SwitchInstructions) on the port (default is SimpleInstructions). Then be sure to manipulate the field of the appropriate instructions record.
Test procedures now have a way to indicate that the simulator should check the results obtained against expected results. The drive array element for a checked port should be set to test. Before calling Eval, set the instructions field for that port to be the expected results. At the end of Eval, for all such ports, the actual results will be compared against the expected results. Alternatively, if the drive element is set to see, this means that the test procedure is volunteering to do the checking. In this case, no comparison is done, but the actual results are copied into the instructions.
EnumTypes used to have atomic structure; they now have array structure.
There is now .rose syntax for split/joiners (see RoseGrammar.Tioga). It is, of course, a new kind of ExpansionStatement: SplitJoin. Here are the relevant productions:
SplitJoin: EQUIVALENCE NodeExpression, NodeExpression
NodeExpression:
ID |
denotes a node, in its entirety
NodeExpression [ CedarInteger [ .. CedarInteger] ] |
denotes selecting an element or subrange of an array structured node
[NodeExpression ( , NodeExpression)*] |
constructs array structure
NodeExpression cat NodeExpression
catenates two array structures
The names of the various records accessible in evals procs, initializers, and test procs have been made more consistent. The names used are always:
state: state record
drive: drive array
args: args record for cell type's generating function
newIO, sw: simple and switch IO records
simpleInstr, switchInstr: instruction records