Close slide viewer and open viewer with /Dragon/Dragon7.0/Top/MemoryController.df MemoryController.dale IOAddressMatch-A.sch specification and an almost completed implementation in it. Circle specification. Here is the specification for the block of logic we'll use to demonstrate low level design capture using graphics: a register address decoder. The address consists of four fields; point the high order bits are unused; point the next field encodes the static device type; point the next the dynamic device number; point and the last the specific register within the chip. I've begun the design already, let's continue. Copy 3 input AND gate from Logic, draw the output wire and name it Match. This simple sequence of actions demonstrates many of the basic concepts of the system. Let's have Rick explain them.

Cut to programmer at white board with and3 icon, properties, and schematic. Have icon wires and picture in different colors. Louis drew the AND gate by selecting it from a library. This library has no special status in the system, it is just a particularly handy collection sharedby many designers. Louis can create his own logic symbols quite simply. Each logic symbol consists of a visible portion, which indicates its functionality and connection points, and some invisible properties, which tells the interpreter how to convert the graphical item into a net list. The AND gate has the IconFor property, which indicates a procedure that converts schematics into net lists. This procedure looks for another property on the icon which names the schematic that describes the implementation of the AND gate. This schematic contains a number of symbols which we'll return to in a second.

Pan to next section of whiteboard which has wire with name. First lets look at the wire Louis drew and named. This introduces the concept of a text satellite. Our editor has a general notion of attaching text to specific graphical items but it knows nothing about the interpretation of that text. That job is left to the interpreter which converts pictures into net lists. By convention the interpreter converts a simple sequence of characters into a name since that is the most frequent use of text.

Pan back to AND schematic. In this schematic we see five pieces of text. Four of them are names but the fifth has the back arrow or assignment character in it. The interpreter recognizes this special character and passes the whole piece of text to a general purpose expression evaluator which assigns the value three to the variable n.

Pan to another section of whiteboard which has n input and gate with its hidden properties. If we look at the properties which control the conversion of the n input and gate into a net list we see that instead of the IconFor property this graphical item has a CodeFor property with the value Logic dot And of n. This is the manner in which graphical pieces of the program describing our circuit can invoke textual pieces of the program written in an ordinary programming language. In this case we are invoking the And procedure in the Logic package and passing the value of n to it. The procedure will compute the net list for our 3 input nand gate. Its possible for the And procedure to invoke the graphical interpreter again so that the program bounces back and forth between text and pictures, using the most natural mode of expression at each level in the hierarchy. Since it is possible to call an arbitrary procedure to convert a graphical item into a net list this mechanism also provides for extending the system in arbitrary ways.

Pan back to AND schematic. The last graphical item in this schematic is this large black box which we call a composer. Its function is to compose simpler wires into more complex collections. In this case it is composing three atomic wires, or wires which consist of single electrical nodes, into a composite wire which matches the structure of the input wire of the 3 input and gate. The procedure which translates schematics into net lists makes a single pass over the source, calling the procedures for each graphical item which convert them into wires or cells and on the fly the rectangles of each wire are intersected to establish the connectivity of the cell. The final result is the production of a single cell in a hierarchy of net lists.

Zoom out to include programmer's face. We've seen how the 3 input AND gate is converted into a net list representation. The recursive evaluation of program fragments made out of pictures or text is the fundamental paradigm of this system. Everything else is embelishments of this idea. Lets return to the register decoder example.

Cut to finished schematic on screen. While you've been gone I've finished drawing this schematic. Let me point out a few more examples of handling wires and then we can try executing the program represented by this block to produce a net list. point Over here are examples of wire extractors. These are graphical items that pick a single wire out of a composition. point This wire extractor is a range extractor. Rather than a single wire it selects a set of wires from a composition. point This little black dot tells our static checker that its ok for the low order 10 bits of this bus not to be connected to anything.

Invoke space-O Sisyph extract. Let's convert this block into a net list. Extract and wait cue. Cut to terminal viewer with IOAddressMatch-A: Record Cell Type at top. This is a textual representation of the net list. We rarely look at this so it is a bit hard to read but it is important that you have a clear idea of the result. Pending delete select IOAddressMatch-A: Record Cell Type. At the top we see the name of the cell and its type. A record cell is somewhat similiar to a Pascal record type in that it collects together cells of arbitrary types. Pending delete select the public wire. Every cell has a public wire which indicates the wires which must be bound when the cell is instantiated. We can see the two input wires, DevNum and Address, and the output wire, Match. Pending delete select the internal wire. Record cells also have internal wires which are those that are used to wire together the instances inside of it. Scroll and pending delete select the instances. Finally we see the instances of subcells such as pending delete select the and3 instance and3 and the binding of its public wires to the internal of the current cell, for example the binding of X which is the output of the and3 cell, to Match, which is the output of the parent cell.

Zoom out to see designer with screen in background. Lets shift our attention to a block which is more naturally expressed by code. Zoom into screen. Louis changes it to focus on the map cache fifo controller and selects the Logic.Driver icon. This icon represents a buffer which takes a parameter that specifies the number of unit loads which must be driven. Cut to following cleaned-up code from LogicSimpleImpl.Driver.

The implementor of the parameterized buffer decided that its implementation need only consider four cases. point The first is when the number of loads was not specified. In this case the designer is simply given an error message. point The second and third cases handle 1 to 4 or 5 to 8 loads respectively and they are implemented by simply calling the extractor recursively on schematics which are not parameterized. The last case uses another parameterized schematic whose parameters are the number of parallel unit inverters for each of the first and second stages. The first stage uses the square root of the number of inverters in a single second stage. This sort of case analysis followed by the computation of parameters clearly requires standard programming language control constructs. Rather than try to invent a graphical language which reimplements these ideas we chose to use an existing language.

Zoom out to designer face. This completes our description of low level design capture. It has demonstrated the need for both graphic and textual descriptions and shown how viewing these descriptions as executable programs rather than static net list descriptions allows parameterized designs and allows the system to be easily extended.

Zoom in to screen as designer displays cache fifo controller centered on the screen. The simple net list which we showed you is not the whole story. Actually it is decorated with properties that link the net list back to the original graphical representation. We will use simulation as an example application which demonstrates what can be done with these links.

This is the control logic for a fifo. It has the obvious read counter and write counter implementation plus a counter to keep track of the amount of data in the fifo. Move oracle cell to center. This cell is used to test the fifo controller. It has the fifo controller icon in it, a clock generator, and a special cell called an oracle. An oracle is just a cell which emulates an integrated circuit tester.

Show FifoCtrl.oracle. This is the file which provides a simple test of the fifo controller. When fed with these inputs point on the left, the circuit under test should produce the expected outputs point on the right.

Cut back to oracle cell. Lets convert this schematic into a net list and make a simulation. Invoke space F Rosemary Create Simulation. Wait cue.

Cut to simulation control panel. Here is the simulation control panel. It mostly does the obvious thing you would expect a simulation control panel to do so lets just push Start Test push start test, wait for evals to hit 5, interrupt it push Interrupt and then demonstrate the capability to do "source level" debugging.

Cut to pushed in fifo control schematic. V left click on NewRqst. I'll invoke a key sequence which means post the selected wire on the oscilloscope display.

Cut to sillyscope display with selection viewer above it. We can see by cycle 5 that new request has made only one transition. But there is another viewer that was created by posting this wire. Let's have Rick tell us about it.

Cut to Rick in front of whiteboard. There is diagram similiar to the first one he used to give the overall system model on the board with a DAG with at least one node that has indegree greater than one. The source also has multiple pointers to nodes in the DAG which have only one in-pointer. Well just as the simple action of dropping down an and gate took us into a discussion that exposed some complex functionality, the simple action of posting a wire also invokes a complicated mechanism. When a particular rectangle is selected the corresponding electrical node in the flattened representation of the circuit is potentially ambiguous. point The cell in the net list DAG (is that a well-known term, Rick?) may be instantiated more than once. point Or the net list cell may only be instantiated once but the same graphical piece of program generated multiple cells. relax In either case some additional information is required to disambiguate the choice. Disambiguation is the purpose of the additional viewer which popped up when Louis posted his wire.

Fundamentally disambiguation means choosing a unique path from the root cell of a DAG to some subcell. point For instance this cell is only used once in this design; it has a single path from the root cell to it. point This cell is used twice in this design; it has this path point; and this path point. Choosing a unique path amounts to picking a particular out-pointer from the root cell. Cut to viewer on display. In the viewer each cell in which the designer might have to pick an out-pointer is given a line. point Each line contains the name of the cell and the name of each instance, or out-pointer, in the cell. click an instance The designer selects a particular instance by clicking on its name.

Zoom out to face shot. An alternative method to pick a specific path through the hierarchy is to follow the graphical hierarchy. This mechanism could completely eliminate the need for the disambiguation viewer if every instance had a graphical instance. Of course this is not so, consider having to draw a schematic instance for every instance of a ram; that simply is not reasonable; it is easier for the designer to give the index of the ram bit in the manner that the disambiguation viewer presents it.

This is probably as clear as mud. Even though this may be difficult to conceptualize it turns out to be easy to use.

Well that's enough about simulation and the relationship between the design source and the flattened design representation. The other major use of the common data structure is layout generation.

Turns to screen. Follow him and zoom into screen. It has a tristate driver with a 4 bit bus runing up to it and another at its output. The first abstraction we will consider is the sequence cell. Suppose that I have a 4 bit tristate bus. I could individually draw the extractors that pick out each of the 4 bits from each bus and draw 4 tristate drivers. It would be much simpler to draw a single tristate driver and then indicate that I want 4 of them. Draw the four wires and put sequencing slashes on the input and output. In our system this is done by drawing wires for each of the connections on the tristate driver and then graphically indicating which of them are to form a bus by putting this sequencing slash on them. The wires that do not have these marks are assumed to all be connected to a single electrical node. Drag in a finished cell with Seq in it and border mode on. Here is the finished cell with the special marker that indicates that this cell represents a sequence of the base cell. Rick can give us a more detailed model of what is happening here.

Cut to Rick at whiteboard with series of boxes and single box above to represent the base cell. What we are doing is inventing a terse graphical language for an operation which is common in custom integrated circuit logic design, that of repeating a cell in a linear sequence. point This is a sequence of some point arbitrary cell. It could have a wire in the direction parallel to the axis of repetition draw such a wire all the way through the cell or it could have wires perpendicular to the axis draw a pin out of the top and bottom. When a wire is parallel all of the wires in the subcells are connected together in the sequence cell draw this. When a wire is perpendicular the collection of wires in the sequence cell form a bus draw this. relax More complicated variations of this idea are possible. Sketch each example. Each cell might tap the nth wire of a bus draw 4 horizontal wires above the cells and draw a wire down to each cell or wires might flow from one cell to another in a stitch fashion, possibly flowing through some intermediate cells. relax Treating all of these cases so that the picture unambiguously describes the intended semantics has proven to be a difficult job. Of course all of the facilities which are available graphically also have a textual expression as well.

Pan to a DAG with a node that is connected by a dotted line horizontally to another. In addition to reducing the size of the design description capturing higher level abstractions allows tools to work more efficiently. A sequence cell is not only a design capture abstraction, point it is also has a better representation in the common data structure. Since the designer has explicitly declared that the cell is to be repeated it is simple to use the Array layout operator to construct the layout. However explicit recognition of the sequence cell may not be any advantage for many tools. Such tools should not have to know of the existence of this abstraction; otherwise each additional abstraction would require modification of all of the tools. To avoid this we have introduced the notion of procedural conversion of abstractions like a sequence cell into a simpler representation that all tools are required to handle. point Whenever a tool encounters a cell of a type not know to the tool it invokes this procedure and then trys again with the simpler representation. With this mechanism every tool in the system only has to know about a few base types and the rest are interpreted only if the tool needs to deal with that abstraction.

Cut to designer in front of terminal. Lets turn to a mode of description which is substantially further away from physical design, that of finite state machines. Zoom into screen which has CompDecTopDown.dale ArrayArbiter. This machine is used to arbitrate access to a RAM array between two competing state machines. The most notable thing about this picture is that anybody who has studied the classical finite state machine literature is instantly able to interpret it. The states are point these octagons; each state has point a name; beneath the states are point the outputs; these arrows are point the transitions and are labeled point with the transition expressions.

Put /Dragon/Dragon7.0/SmallCache>Code>SmaleCachePmCodeFSMImpl.mesa up. Scroll to IfState[HMReturn2PC]. Zoom on only that state. Another classical description of a finite state machine, this time textual instead of graphical, is that of a microcoded machine. In this case the outputs are associated with the transitions rather than the states. Select IfState[HMReturn2PC]. Here we see the declaration of a state. Select all of the If statements. It is followed by 4 transitions which are a function of 2 variables, NonFBTIP and TimeOut. Select AddOut. Here are the outputs associated with a transition. Select JmpState. And here is the definition of the next state.

Put ArrayArbiter back on screen. Lets run a simulation of the graphical state machine. space F Rosemary Create Simulation; push Start Test. Push into oracle cell; select outputs and plot them. In this simulation we can see the state machine running. However, we have to infer the state of the machine from its outputs. That's no problem for this state machine, where each state is uniquely identified by the outputs, but that is not always the case. Another extensible mechanism in our system is the recording of the state of abstract blocks. In the case of a state machine the abstract state of the cell is the current state name. select state machine icon; space F Rosemary Plot Cell State; We can see here that the state names are plotted. This is far easier then inferring the state from the outputs and eliminates any ambiguity.

Zoom out to face shot. If the logical description of this arbitration state machine were embedded in a standard cell layout the designer has nothing more to do. An algorithm synthesizes the feedback and output equations from this specification; converts the equations into a multilevel logic network, including the feedback latches; and casts all the logic in terms of standard cells. The physical design is then handled by the standard cell system. In many cases the equations are best implemented as a PLA structure and so that method of physical implementation is available as well.

Many significant advantages accrue from high level design capture. Tedious, error prone work is dramatically reduced. The design is more easily understood by both the original designer and others. The choice of target technologies is wider; for instance the same state machine could be implemented as a PLA on a custom chip, or programmed into a set of PALs. Simulation can take advantage of the higher level of abstraction to go faster, thus increasing the amount of design verification which can be performed.

Cut to whiteboard. It has rows of functional blocks, 4 columns wide, labeled with functions such as Xor, tristate driver, latch, and. There are horizontal wires going all the way through and vertical wires sharing tracks which are repeated in each column. The final example of design description that we'll cover is the data path. We assume that a data path has a point regular two dimensional layout with rows of functional elements of various heights. The purpose of the data path operator is to wire these low level components together in a more efficient manner than is possible with an ordinary standard cell system. The data path operator relies on a set of predesigned cells just as a standard cell system does. These cells are carefully designed so that power distribution can be easily accomplished. In his schematic the designer supplies the point cell placement information, the point order of wires in the vertical channels, and the point places where horizontal channels occur to supply connections to the data path along its height, or to permute the wiring from the cell above to the cell below. relax When multiple data paths have lots of bit level interconnection the designer can specify that the data paths be interleaved at the bit level, eliminating the routing of buses as wide as each data path, thus converting an order n squared layout problem into an order n problem. Functional blocks may be synthesized algorithmically so that functions such as multiplexors which vary greatly from one data path to another can be generated from a terse graphical description. Lets look at a piece of a datapath to make this discussion more concrete.

Cut to screen with /Dragon/Dragon7.0/IFUSch/IFUSch.dale on it pushed into PCFormBot with focus on PCAltPipe1A including one blue box on top and two below. This is a portion of a 32 bit data path taken from an instruction fetch unit. point Each vertical wire you see represents 32 wires. point Each horizontal wire represents a single wire which controls all 32 bits of the data path. point at 3rd channel from left Vertical channels can be occupied by more than one wire. Each blue or green box represents a function that occupies a row in the data path. Here we see three types of functions; point tristate driver, point multiplexor and point latch. Cut to layout of this portion of the data path. Here is the resulting layout. We see the 6 vertical channels, the set of tristate drivers and latches, along with the synthesized multiplexor.

Zoom out to face shot. The datapath operator is a good example of requiring a designer to specify only the minimal amount necessary to optimize his design adequately. Since the system is easily extended the designer can find out half way through a design that some particular piece of logic requires tighter manual control over its optimization and he can fix it within the framework of the system rather than having to start over.