Design of the Mosaic Processor Citation Lutz, Christopher (1984) Design of the Mosaic Processor. Master's thesis, California Institute of Technology. doi:10.7907/cs85-zs74. https://resolver.caltech.edu/CaltechTHESIS:04122012-093644670 Abstract No abstract. Item Type: Thesis (Master's thesis) Subject Keywords: (Computer Science) Degree Grantor: California Institute of Technology Division: Engineering and Applied Science Major Option: Computer Science Thesis Availability: Public (worldwide access) Research Advisor(s): Seitz, Charles L. Group: Computer Science Technical Reports Thesis Committee: Unknown, Unknown Defense Date: 1 May 1984 Other Numbering System: Other Numbering System Name Other Numbering System ID Computer Science Technical Reports 1984:5129 Record Number: CaltechTHESIS:04122012-093644670 Persistent URL: https://resolver.caltech.edu/CaltechTHESIS:04122012-093644670 DOI: 10.7907/cs85-zs74 ORCID: Author ORCID Lutz, Christopher 0000-0002-7993-4759 Default Usage Policy: No commercial reproduction, distribution, display or performance rights in this work are provided. ID Code: 6910 Collection: CaltechTHESIS Deposited By: Benjamin Perez Deposited On: 12 Apr 2012 18:18 Last Modified: 04 Nov 2025 20:21 Thesis Files Preview PDF - Final Version See Usage Policy. 4MB Repository Staff Only: item control page

Design of the Mosaic Processor Christopher Lutz Computer Science Department California Institute of Technology 5129:TR:84 Design of the Mosaic Processor by Christopher Lutz In Partial Fulfillment of the Requirements for the Degree of Master of Science May 1984 9129:TR:84 Computer Science California Institute of Technology Pasadena, CA 91125 The research described in this paper was sponsored by the Defense Advanced Research Projects Agency, ARPA Order number 3771, and monitored by the Office of Naval Research under contract number N0Q0014-"'9-C-0597. a No aranr o SP Ono WN Contents Introduction Top-level View Chronolagy Processor Organization Datapath Ports Controller Instruction Set Microcode From Version A to Version B . Sample Instruction Execution Memory . Circuit Design Design Tools . Testing Acknowledgements References APPENDIX A: Processor Version A Instruction Set Microcode Source Circuit Diagrams APPENDIX B: Processor Version B Instruction Set Microcede Source Circuit Diagrams APPENDIX C: Selected Layout oom wWNnN FY & 11 12 13 14 17 18 19 20 el ae a3 26 2g 48 55 59 Design of the Mosaic Processor’ 1. Introduction The Mosaic element is a fast single chip nMOS computer designed to be used in groups for concurrent computation experiments. Each elerment contains a 16-bit processor, 4 input ports, 4 output ports, and read-write memory. This thesis describes the design of the processor and ports in detail. The memory section, mentioned here only briefly, has been designed separately and will later be incorporated on the same chip with the proces- sor and ports. Myriads of Mosaic elements can be connected together by their ports in a variety communication plans, such as a tree, mesh, shuffle, chordal ring, or cuhe connected cycle, to farm a family of specialized, high performance, concurrent, and programmable computing engines. Mosaic is one of several system building experiments in concurrent computation underway at Cal- tech; a discussion of the rationale, programming style, and applications of these machines is offered in [Seitz84]. In addition to its end use as a com- ponent for experiments with concurrent computing engines, Mosaic has been an interesting vehicle for numerous adventures in VLSI design, design tools, and testing. The principle objectives in designing the processor have been speed, simplicity, and the flexibility to serve a wide variety of applications, antici- pated and not. 2. Top-level view It appears that most of the silicon area in multiple-instruction multiple-data (MIMD) ensemble machines should be devoted to memory for the best tradeoff between performance and generality. In cosmic cube, a larger grain size machine of similar style to Mosaic, the fraction of the ele- ment complexity devoted to memory is about 7o%. With the precondition that a complete Mosaic element fit on a single chip, and using today’s MOSIS nMOS fabrication with 1.5 micron lambda (3 micron feature size) on chips 6 mm square, the complexity of today’s Mosaic element is limited to 4000 by 4000 lambda, or 16 million square lambda (MSL). This area is apportioned with about 2.5 MSL for the processor and ports, 1 MSL for the pad frame, and 12 MSL (75%) for memory and its interconnect. . IfLute,Rabin,Scitz&Spock83] is a short preeurser to this thesis. Pads Processor 4K bits 4K brts 4K bits 4K bits 4K bits Pads 4K bits 4K bits 41K brts Figure 1: Mosaic Element Floorplan The floorplan of the Mosaic element places the processor and ports in _ one corner, and fills the rest of whatever chip area is available with copies . of 4096-bit memory modules arranged so that the address and data buses can be run in between. For a 16 MSL element, the chip has the floorplan showu in fiyure tL. 3. Chronology The original models for this project, from which everything else evolved, were (1) Sally Browning’s research on algorithms for a programmable tree machine [Browning80a, Browning80b, Browning&Seitz81], and (2) the “OM” described in [Mead&Conway80]. Mosaic started out as a tree machine ele- ment, but we have since come to see it as a building block for a variety of fine grain ensemble machines with connection plans up to degree 4. The influence of the OM layout style on the floorplan and many details of the ALU of the Mosaic processor will be apparent. Au early alleiipt Lo lay oul a less ambilious processor with a 4-bit path to off-chip memory used the prototype versions of Earl, a constraint solving geometry and composition tool [Kingsley82]. The early processor and early Earl served as mutual guinea pigs as they were growing up together, A major redesign followed the decision to incorporate Mosaic’s memory on-chip with the processor, rather than use commercially produced RAM -~-g- chips. Although specialized semiconductor processes provide higher storage density than processes suitable for the Mosaic processor, putting the storage on-chip with the processor offers the advantages of reduced pin-count, volume, signal energy, driver delay, and cost. A new processor, featuring a 16-bit data path intended to be connected to on-chip memory, was designed in the 1981-82 academic year, laid out and verified in the summer and fall of 1982, and sent to MOSIS for fabrication at a4 micron feature size in January 1983. It functioned nearly correctly and at 140 nsec cycle time on first silicon in February 1983. Appendix A con- tains the instruction set, microcode source, and circuit diagrams for this design, called version A. The processor was subsequently redesigned with additional functions and a faster control PLA; Appendix B describes this latest design, called version B. In the meanwhile, the on-chip memory sections have been designed, and processor chips have been assembled with fast off-chip memory to make some small prototype Mosaic elements. These elements will be used . for programming experiments and software development in anticipation of larger systems to be built with the fully integrated Mosaic elements. 4, Processor organization Figure 2 is the floorplan of the core of the processor, without the sur- rounding memory and pad frame. The processor’s organization is summar- ized by the detailed block diagram of figure 3. The processor has two princi- ple components: a datapath/port block, and a controller, each of which is a dense, regular block of layout. The datapath/port block is functionally cen- tered around the processor's single 16-bit internal data bus; it is controlled by signals issued by the PLA-based controller. The following sections describe these components (for version A) in detail. Then section 10 describes the changes that yielded version B. The instruction register (I) holds the current macroinstruction and can be latched from the memory data bus on command from the controller. Parts of the instruction register are distributed in several places in the pro- cessor depending on the bits needed locally: in the controller, near the flags, and near the register and port selectors. Some of the bits are dupli- cated in different places. The Mosaic element is synchronous, with 2 sets of 2-phase non- overlapping clocks supplied externally (figure 4). The clocks are nominally 7 volts (with Vdd = 5 volts) for reasons discussed in section 13. The primary clocks, called $1; and 2, have minimum high times of roughly 60 nsec and 30 nsec, respectively. The secondary clocks, #4], and ¥o9, are used -4- DATAPATH | OUTPUT | INPUT PORTS Registers | ALU | & <> E Ts a + HS z Ww c p- - Qa 29 = os us Loa = PORT CONTROL ; & SELECT Rec ister DRIVERS & ROUTING ROUTING INPUT NPUT [sictes QUT PUT LATCHES & DRIVERS LATCHES; ORIVERS DRIVERS N CONTROLLER INPUT OuTPUT CAND) (oR) PLANE PLANE ~< ISOOA Figure 2: Processor floorplan principally in the memory sections; version A processors do not use them at all. The memory cycle, processor microcycle, datapath operations, and serial communication cycle occur in parallel in one clock cycle. The processor design is the result of dozens of iterations through the design of the instruction set, microcode, floorplan, logic design, and circuit design. Thus the rationales for many of the design details are buried in a long history of shuffling and trial-and-error. While many of the design deci- sions are individually somewhat arbitrary, their justification is that they work well together. For example, the choice of a single internal data bus sometimes limits the performance, but a slower and more complex controller and address port ‘pads port pads ~ aq ga agg BUS lb ; - mat j Ps ty 5 12 4 4 16 output | inp yt : ports i pare $ registers Address De ~~ “Select” _— “select section 3 4 Hlaas s|<o Branch) ~ 3 3 7" oe) Ken0> | Ft PLA << C6:4 zg é F condition a S| + =n a 5{ 3 i 8) “| & Datapath interrupt © z Feedback Datapat Latch t E Reset ———""7 pF) sa { memory scan VV V y Weis:6>_\ “fe35 [wri é path > input CLT latches [ output latches path Controller PLA input plane output plane Figure 3: Processor Block Diagram version A only version B only section would be required to take much advantage of more busses. The pro- cessor opts for a more leisurely approach in which simple instructions take 3 cycles: enough to do instruction decode, operand fetch, and operand use on separate cycles. This keeps the per-cycle capabilities of the bus, ALU, controller, ports, address section, and memory are well matched. _ ALU oO p ERATE a f Bus \ TRANSFER aii aii f<---- Soc cpootcs cpt — ws ~ Pe ee ee —— ~ <— 1SO T= — 250 T—+he—2150T —>" ' 1 \4————— ONE MICROCYCLE aa) 100 nsec Figure 4: Externally Supplied Clocks >. Datapath The datapath contains those parts of the processor that communicate over the internal data bus. The bus is 16 bits wide and runs the length of the datapath. The functional blocks in the datapath are organized in a bit slice pattern, one bit of the bus running through each bit slice, with a bit slice pitch of 34 lambda. During 1 of each cycle the bus is precharged and the ALU/shifter computes a new result. 2 is used for the bus transfer and the ALU carry chain precharge. Except in the register section, the control signals, power, and clocks run (vertically) on metal perpendicular to the bus. The register section was more compactly laid out with vertical poly control signals and clocks, bus, and power run horizontally on metal. The datapath includes sixteen 16-bit registers which are used as gen- eral purpose registers in the macroinstruction set. In every cycle, one of the registers may be a bus source or bus destination. The register used is addressed by either the J field (bits 0 through 3) or the K field (bits 4 through 7) of the instruction register, as determined by a signal from the controller. The controller thus cannot specify a particular register directly. -~F- The array is composed of pseudostatic storage cells, refreshed on 1. The ALU/shifter performs in one cycle any of the arithmetic, shift, and logical operations required by the arithmetic instructions. The ALU operands are held in a pair of latches, called X and Y, that are loaded from the bus. The ALU is patterned after the ALU in the OM design [Mead&Conway80], with a pair of function blocks and a precharged pass transistor carry chain. Mosaic uses an exclusive-OR gate at the ALU output rather than the slower and needlessly general result function block used in the OM. Although the ALU does not use carry lookahead, it is optimized to the extent that. itis notin the critiaal timing path. The ALU result serves as input to a shifter, which uses pass gates to route correctly shifted data to the ALU/shifter output. The shifter can shift or rotate right one bit, rotate right by 4 bits (nibble rotate), or pass the ALU output through unchanged. The shifter could have been placed in parallel with the ALU, rather than in series with it, since the services of both are never required in the same cycle. However, the series organization is preferable because (1) it is simpler, since only one set of latches and flag interface logic is needed, (2) it costs nothing in speed, since computing the overflow flag is the slowest path. This is possible because the pass transis- tors in the shifter are carefully placed so that the capacitive loads on the most significant (last computed) bits out of the ALU are small when no-shift is performed. The processor maintains four flags in association with the ALU/shifter. These are the familiar Z (zero result), N (negative result), V (two's comple- ment overflow), and C (carry/not borrow). The C flag is also used as the shift in and/or assigned the shift out in 1-bit shift and rotate instructions. The controller does not sense the values of the flags directly. Instead, a fixed 3-bit field in conditional branch macroinstructions specifies one of eight branch conditions. These three bits, as well as the values of the four flags, are inputs to a small PLA that produces one bit of output, the ‘flag condition’’. This bit is an input to the controller, which tests it in perform- ing the conditional branch instructions. Thus the controller is not burdened with computing the flag condition itself. The branch condition codes were assigned carefully so the flag condition PLA requires only six implicants. Since the PLA is so small, it fits neatly next.to the flags in the corner of the processor, in a region formed by removing the top four bit slices of address generation. The 4 flags and 12-bit program counter form a 16-bit status word, conveniently located to communicate with the bus. Every cycle the address section emits a new memory address onto the 12 memory address wires that come out of the right edge of the datapath. The address generation section houses the program counter register (PC), the refresh address register (RA), the current memory address register (A) -§- and an incrementer. The microcode guarantees that the RA is incremented and issued to the memory at least once every 8 cycles. The processor's per- formance is not degraded by this refresh task because only memory cycles which would otherwise go to waste are used for refresh cycles. A 12-bit address is sufficient to address the number of words of memory we can currently place on-chip. If in the future more than 12 bits of address are needed, either the word length of the processor can be increased, or the flags can be moved to a new status word apart from the PC, and the address section lengthened to 16 bits. Neither solution is trau- matic. 6. Ports Mosaic processors communicate with each other through their ports. Each processor has 4 input ports and 4 output ports. Connecting an output port of one processor to an input port of another (not necessarily different) processor forms a two-word FIFO. That is, words can be removed by the processor with the input port in the order in which they are inserted by the processor with the output port, and as many as two more words can be inserted than have been removed. The communication between input and output ports is bit serial at the microcycle rate, about 10MHz. Mosaic'’s implementation of the ports requires only a single wire, called the port link, to connect an input to an output port. When a port is not ready to perform a serial transfer, because it is an output port with no data or an input port with unremoved data, it clamps the port link to ground. On the cycle when both ports are ready to perform a transfer, neither proces- sor grounds the port link and an external pullup resistor pulls it to Vdd. Both ports recognize this signal as the ‘start bit’ of a transfer, much as in Rs-23e2 data communications, The next 16 cycles pass the data serially on the port link, and then the ports revert to the clamp-if-not-ready state. This protocol allows multiple input ports to be connected to the same link: all input ports receive data from the output port beginning on the cycle when all the ports are ready. This feature went unnoticed until after the ports were completely designed. Each input port is based on a 17-bit serial-in, parallel-out shift register. The input port senses that a transfer is complete and that it should stop shifting when the ‘‘start bit’ reaches the 17th bit of the shift register. Then the first 16 bits contain the transmitted word. Each output port is based on an 17-bit parallel-in, serial-out shift register. The trailer bit is set to one when a word to be transmitted is loaded from the bus, and is used as a marker to determine when the last bit of the word has been shifted out. -~Q- Three bits select a port, always taken from a fixed field of the instruc- tion register (bits 4, 5, and 6). A bit from the ports, the ‘‘port condition’, indicates whether the selected port is ready to perform a bus operation. If an output port is selected, the controller can direct it to read a new word to transmit from the bus. If an input port is selected, the controller can direct it to drive the bus, or to ‘‘advance” (remove a word from the FIFO). The controller is responsible for issuing these signals only when the selected port is ready. The use of a single fixed port specifier field allows the hardware to be simple, but it made designing a clean instruction set difficult because it requires that all port references, whether for input, output, or testing the condition of a port, coincide in the same field of the instruction word. Early plans called for a 4-bit message number appended to each transmitted word, which the destination could test with its own input instructions. The message number was later deemed to be insufficient, the design to support it was distressingly complex, and the havoc it caused at the ficorplan level was unspeakable. Thus it was discarded, as were several other port designs. The present is the simplest of all designs considered, but the design as seen from the instruction set has several drawbacks: the number of parts is limited to four; there are no facilities for referencing ports indirectly (instructions must reference them explicitly); and functions such as block transfers, polling for ready ports, and message routing must be done in software at the expense of performance and code space. Furthermore, in this implementation the serial transfer rate is stuck at the processor cycle rate, which requires bounding the transfer distance or slowing the entire processor down to accommodate the slowest communication path in the ensemble. 7. Controller Each eycle the Mosaic controller computes a new set of signals to con- trol the datapath and ports in the following cycle. The original plans for the controller assume a rather conventional organization in which microcode words are fetched from a ROM, and a new ROM address is computed every cycle by a conglomeration containing an inerementer, multiplexers, and other miscellaneous logic. Most of this complexity disappeared with the realization that a PLA could be efficiently programed to perform most of the controller’s function. The controller now required no additional hardware -10- except input and output latches and an auxiliary PLA for controlling the ALU/shifter. This auxiliary PLA proved to be very troublesome because all the king’s horses and all the king’s men could not find a placement for it that did not result in large wiring channels and expanses of white space. The auxiliary PLA was finally eliminated by incorporating its fuuclion in Lhe main controller PLA. The controller became merely a @-plane PLA with latches. In most microprocessors the datapath is the most regular part, but in Mosaic the controller is even more regular than the datapath. The controller is complicated somewhat by a scheme to change its height to width ralio to belter ft the space allotted to it: for every con- troller output, the PLA OR-plane has two outputs and a 2-to-1 multiplexer. The multiplexers are controlled by bit 8 of the instruction register (I<&>), chosen because it allows a large reduction in the number of PLA implicants (outputs from the AND plane). This scheme doubles the number of outputs from the AND plane in return for a roughly 35% reduction in the number caf implicants. Programing this ‘‘folded’’ PLA is logically the same as program- ing a PLA in which implicants are paired, the input conditions of implicants in a pair differing only in bit I<&>. The AND-plane is split into two parts to make routing of inputs easier. (See the processor floorplan, figure 2.) This splitting requires implicants to be run on metal because poly or diffusion implicant wires would have far too much static voltage drop to allow the processor to work, no matter where the pullups were placed. The PLA outputs are run on diffusion; their pullups are placed opposite the end where the outputs are sensed so that the impli- cants’ static voltage drop does not appear at the sensed end. The controller also incorporates a shift register through all of its input and output latches. This ‘scan path’ has not been used, although it might have been useful as a diagnostic aid had anything been seriously wrong. It is controlled by auxiliary clocks called a and ?p which are held stable under normal processor operation. The controller has 17 inputs: {0 bits from the instruction register, the flag condition, the port condition, the processor reset, and 4 feedback bits (outputs from the controller clocked directly back to the controller input). So little feedback state is needed because much of the state is held in the instruction register (I), and the sequences to implement macroinstructions are short. Most of the 41 outputs from the controller go to clock-AND drivers (see section 13) that drive control lines into the datapath. Five outputs specify data bus sources; 6 specify bus destinations; 16 control the ALU/shifter and fiags: 6 contro] the address generation section: 4 are feedback terms: and 4 perform miscellaneous functions. -ji- 8. Instruction Set Appendix A specifies the macroinstruction set. All instructions are one word followed optionally by a word of immediate data. In the first instruc- tion word, the two 4-bit fields J and K can each be used to specify one of the general registers. In some instructions, the K field may specify one of the ports or a branch condition instead. All instructions fetch two eperands, X and Y, as specified by the 3-bit MODE field. The X and Y operands in fact correspond to the hardware regis- ters X and Y at the input to the ALU. Two of the MODEs involve ports; their meanings depend on whether feld K specifes an input or an oulput port. Instructions that write to an output port wait until there is room in the FIFO. Instructions that read from an input port wait until there is a word to read, and can optionally ‘‘advance’’ the port (remove the word from the FIFO). After fetching X and Y all instructions perform the operation specified by the 5-bit OP field. Sixteen compute some function of X and Y and assign the result to a destination as specified by the MODE. The RNR (Rotate Nibble Right) Arithmetic instruction allows access to nibbles (4-bit fields) within words, and performing two successive RNR instructions effects a byte swap. The remaining OPs include a compare, stores, stack manipulations, and flow control. For example, JUMP assigns X to the PC. PUSHJ performs a subrou- tine call by pushing the PC and flags on a stack, using any register as a stack pointer, and then assigning X to the PC. BRAT and BRAF assign X to the PC if the condition in field K is true (for BRAT) or false (for BRAF). These conditional branches can test the state of the ports individually, the flags individually, or signed and unsigned relations computed from the flags. The richness of this instruction set is justified largely by the code com- pactness it offers in its environment of scarce on-chip memory. Perhaps the greatest code space inefficiency is in the lack of short branches: branch instructions take a full word of immediate value to specify the address rather than a short offset, as in a PDP-11. Also, the lack of byte addressing requires the use of full words to store bytes, or emulation of byte address- ing. On reset, the processor begins executing instructions starting from memory location zero, which is assumed to contain ROM for an initialization program. -12- 9. Microcode The speed, simplicity, and compactness of this design owe much to the realization that the controller need be nothing more than an PLA with latches. A PLA is not merely sufficient; it is convenient and easy to program for an instruction set such as this in which microinstruction sequences are short but heavily branched based on varying fields in the input to the con- troller. Each implicant in the PLA is viewed as a word of microcode. More than one word of microcode can be active (that is, more than one implicant can be TRUE) in any given cycle. Usually only one word is active at a time, but there are important exceptions. In these cases, the outputs are partitioned into disjoint sets, such that each word has no TRUE outputs (transistors in the OR plane) outside its set. Thus this controller does not take advantage of ORing of the outputs for the active words, although we might reasonably have done so if it appeared to offer much advantage. The effect of multiple active words used in this restricted manner is like that of multiple disjoint - PLAs, but the physical layout retains the regularity of one PLA. In return for this restriction, the absolute true/complemented sense of the individual outputs is irrelevant, the microcode assembler and assembly language is simpler, and the microcode is easier to understand. An unpleasant feature of writing microcode for a PLA is that words which are active on the logical OR of input conditions (other than the con- junction implicit in don’t-care bits) must be implemented with multiple implicants, one for each condition being ORed, and the outputs duplicated for each implicant. Unless care is taken, implicant groups of this sort tend to hog the microcode space. Careful encoding of the macroinstruction set is a partial solution, and the problem is certainly less severe than if the con- troller had heen RON-based. A simple microcode assembler, written in SIMULA, reads the source microcode and assembles it into an runtime data structure. From here the assembler can output the code in any of several formats, including Earl source code, and a table of bits for visual checking. The whole process takes 10 CPU seconds on a DEC-20. The assembler also contains an ad hoc register-transfer level (and sometimes gate level) simulator of the proces- sor. This simulator served as an initial debugger for the processor design, and is still the initial proving ground for modifications in the processor and its microcode. -13- 10. From Version A to Version B The version A processor has been fabricated numerous times at various feature sizes. The version B processor has not yet been completely asserm- bled or fabricated, but is planned for future fabs. This section describes their differences. It illustrates the kind of change that occurred many times in the design history: simplifications or improvements that retain most of the original parts and techniques. This long history of incremental changes is largely responsible for the present design’s compactness, speed, and simplicity. The following changes lead from version A to version B: A special purpose register, the Multiplier/Product (M), is added to the datapath in association with the ALU. It allows the processor to perform a multiply step in one cycle. The multiplier, initially contained in M, is shifted out and tested by the controller one bit at a time. The least significant bits of the product are at the same time shifted into M. A 16-bit shift register also added to the datapath is used by the controller as an auxiliary finite state machine to count multiply steps. The multiply macroinstruction pro- duces a 32-bit unsigned product in 21 cycles. The controller circuit design is redone to use precharging and clock- AND drivers, rather than the static design which made the version A con- troller the speed-limiting component. The controller is logically simplified by eliminating the ‘‘folding’’ technique described in section 7. The con- troller now has 20 inputs, 49 outputs, and about 120 implicants. The instruction set is changed to include a set of MOVEs in which 3-bit fields specify any of 8 sources and 8 destinations. The two MODEs which involve the ports are eliminated to make room for the MOVEs. Now all port references must be made with MOVE instructions. The multiply and several additional single-cycle arithmetic instructions are added. The processor now handles simple external interrupts. When a one- cycle pulse appears on the interrupt pin, the processor completes the instruction in progress, saves the PC and flags in memory location —2, and takes the contents of location —3 as the interrupt service address. These interrupts can be used, for example, to provide an ensemble of processors with periodic interrupts. Periodic interrupts are useful for decoupling com- munications from procesing, (e.g., to implement automatic message roul- ing, and to buffer large blocks of data) and to give the processor a sense of time (e.g., for heuristic searches). Earlier plans called for an interrupt- generating counter to be placed in each processor. Although the design and layout of the interrupt counter were completed, it was replaced with the simpler and prohably more useful external interrupt. -14- If the interrupt pulse is at least 26 cycles (long enough for multiply to finish and the controller to note that the pulse is persisting longer than a cycle) the processor performs a “soft reset’, which completes the instruc- tion in progress, saves the PC and flags in location —1 and then sets the PC to zero, where reset ROM is located. Soft reset differs from hard reset in that soft reset allows the instruction in progress to finish, but cannot force the controller out of illegal states. Soft reset can be used to save the state of a Mosaic ensemble. The ensemble can be restarted later with the same state, except for the exact phase relationships of port transfers and instructions in different processors. This feature can be used as a diagnos- tic aid, to allow periodic checkpuinting of long-running tasks, or to swap tasks and thus allow time-sharing of an ensemble. In order to guarantee interrupt service in bounded time, the port-wait states must be interruptable. The microcode thus refetches and restarts any port input or output instruction that cannot be completed immediately. Since the instruction register (I) is now guaranteed to be latched periodi- cally, the pseudostatic cells of version A can be replaced with dynamic nodes. The flags are now also writable from the bus, in order to allow return from interrupt. The major additions yielding version B (multiply, new controller, com- plex MOVEs, and interrupts) are essentially independent and any subset of them could reasonably be implemented. They are lumped together as ‘‘ver- sion B’’ for convenience of presentation. 11. Sample Instruction Execution -In order to illustrate some features of the microcode programming style and processor timing, this section presents a long-winded blow-by- blow description of the execution of a sample (version B) macroinstruction. Figure 5 shows the assembly of the macroinstruction ‘ADD #7,R1,Re”", the 4 microcode words required to execute it, and the behavior of various parts of the processor in the vicinity of its execution. This instruction adds immedi- ate data 7 to the contents of register 1, and stores the result in register &. The instruction executes in 3 cycles, corresponding to the first, second, and last two microcode words (the last two are active simultaneously). The tokens ‘.deeode", ‘get’, and ‘.go” are mnemonics for feedback states: they appear both in the input conditions and in the next state out- puls. The first microcode word, '\DECODE:"', is in fact the firet word of every instruction. It becomes active any time the feedback state is ‘’.decode”’, no interrupt is pending (“INT=0"), and the processor is not being reset (an implied ‘‘RESET=0"). “I= *" indicates that all bits of the Instruction register A macroinstruction, assembly languages [ 14: ADD #7,R1,R2 A macroinstruction, binary code: 10: 443 12: 13s 14: 6110 1000 0010 0001 good 0000 C000 0111 Clast word of previous instruction] Cfirst word of instruction] Cimmediate value = 7] Cfirst word of next inetmuction) Cimmediate value for next instruction, or first word of instruction after next] The syntax for a source microcode word is: word <mnemonic>: <ijnputs> <outputs> Source microcode for executing the instructions word DECODE: .decode I= * INT=0 2 IN->I saveC RJ=> X Y DM RA+t+=>A wget word #,J3,K: .get Tm=011 ss PC++->A IN=> X -90 word ADD: «go I= * * * 01000 :: ALUONLY GP= 86 Cin=0 nosh setZNV setC word ALUe>K: .go I= 01% O* & & & s2 MOALIL PLtt~>A => RK -decade Processor timing in executing the macroinstruction: microcode| microcode memory ALU microm] word(s) | word(s) address memory memory function cycle | being controlling}; being address Gata and bus pumber| fetched | processor computed available Jtransfer Pe+t = 12 44 DECODE: eee Cimmediate CADD instr.) wee aon value) RAt1 12 ADD instr. 4 #,J,K3 DECODE: (new refresh| Cimmediate (Latch into R1=> address) value) I register)}| X,Y,M ADD: Pet) = 13 7 2 and #,J3,K: (1st word ofj (refresh Cimmedi ate ALU=>K: next instr.)} address) value? T=>X ADD: PC+i = 14 13 XtY~>W 3 BDECODE: and Cimmed. for | (1st word of ] (retresn ALU“>K: next instr.)] next instr.) data) =>R2 RA+1 14 eee DECODE: (new retresnf} Cimmed. for [Ctst ward of wae address) next instr.) [next instr.) Figure 5: Example macroinstruction, microcode, and timing -16- are don’t-cares. Previous microcode has ensured that a new macroinstruc- tion was fetched on the previous cycle. Thus “DECCDE:” latches it into the instruction register (“IN—>I’’) at the start of the cycle. The controller has not had time to branch based on the new instruction, but by #2 the J and K fields will have arrived at the register decoder; thus this microcode word fetches one of the registers to all of the destinations where it might be needed (‘‘RJ=> XY DM"). This ‘register prefetch’’ saves a cycle from most instructions. It is ton early to know what. to da with the next. memory cycle, so the microcode uses it as a refresh cycle (‘‘RAt++—>A”", a macro for “RA—>ine Addl inc—>A A—>RA”). The next microcode word “#,J,K:"" is conditional on the MODE field of the instruction register ("I= 011”) and corresponds to an instruction with an immediate value and a register as operands. In the complete microcode, there is also a microcode sequence conditional on each of the other possible values for the MODE, though they are sometimes longer than one cycle, e.g. for memory references. The MODE in this example specifies operand X is an immediate value, which is obtained via the bus from the memory data input ‘buffer (“IN=> X”). The PC is incremented past the immediate value (‘PC++—>A") in order to begin fetching the next instruction. The next state output ‘‘.go"' indicates that all operands have been fetched and the code for the operative part. of the instruction should take over. The last two microcode words, “ADD:"” and ‘‘ALU->K:" are active simul- taneously and complete the macroinstruction. In the “ADD: word the token ‘‘ALUONLY” indicates that this word specifies only ALU/shifter out- puts (ie. it has no transistors in the OR plane for other outputs) while “NOALU" in the ‘‘ALU—>K: " word indicates that this word controls the rest of the outputs. The ‘‘ADD:” word instructs the ALU/shifter to add its inputs, X and.Y, by specifying the appropriate Generate and Propagate codes (‘'GP= 86"), the carry-in ('Cin=0""), and the Lype of shifl (“‘mosh", for ‘uu shill”). The complete microcode contains similar words corresponding to the other arithmetic operations: subtract, increment, etc. These words are indepen- dent of the MODE field of the instruction but dependent on the OP field (in this example ‘I= ***01000", since the OP code for ADD is 01089), The ‘‘ALU-—>K:”"’ word deposits the ALU/shifter output in register K (‘W=> RK"). Other words in the complete microcode, dependent on the MODE but independent of the OP code, handle the other possible destina- tions. Thus the orthogonality in the macroinstruction set, arithmetic OPs versus MODES, is represented directly in the microcode. Only one micro- code word, “ALU >K:", is needed to handle two mode cases, sinos the MODEs have been carefully encoded so that one input condition (“I= 017 0”), decodes both cases. Careful encoding such as this throughout the instruction set helps to keep the microcode compact. In ““ALU—>K:"’ the PC -17- is incremented and used as the memory address (‘‘PC++—>A”), as it is in the last cycle of all instructions. This begins prefetching the word after the next instruction, in case the next instruction takes an immediate value and needs to use it in its second cycle. In this example, all three memory cycles are used: instruction fetch, immediate fetch, and refresh cycle. Typical memory cycle usage is perhaps 35% instruction and immediate data fetches, 25% refresh cycles, 10% data reads, 5% data stores, and 25% wasted cycles for discarded prefetches and null reads. i2. Memory The memory is partitioned into several smaller arrays, as suggested in section 8.5 of [Mead&Conway80]. Each array is 4096 bits, 64 by 64, organ- ized to interface with the processor as 256 16-bit words. The very small amount of read-only memory required for the initialization and bootstrap loader is implemented in a set of ‘‘maimed’’ RAM cells. The densest read-write memory we understand how to make with MOSIS mMOS technology is based on a 3-transistor dynamic memory cell, which must be refreshed periodically. This refresh function is accomplished by the processor by referencing consecutive memory locations during other- wise unused memory cycles. Commercial single transistor dynamic memories require dynamic node refresh every 2 msec. Systems using such devices typically use error detecting/correcting codes to bring soft errors to acceptable levels. We are depending on the use of 3-transistor cells with fairly large storage nodes, combined with the fast (50 microsecond) refresh rate provided by the processor, to produce sufficiently reliable memory. The memory cells, figure 6, use separate read-data and write-data busses. This allows simplified control circuitry and shorter cycle time because a read and a write may occur simultaneously. Each memory access starts with a word-line read followed almost always by a refresh write to the same word-line on the next cycle, in parallel with the next read. When a write is requested one of the 4 words read from the selected memory bank is replaced with write data from the processor. This write data is written in the next cycle. in parallel with the next read. (However, if the read is to the same word line as the pipelined write, it accesses stale data which should not be written back on the following cycle. For this rea- son the refresh write-back is disabled on the second cycle after a write eycle.) In this form of pipelining consecutive writes and write followed by read to the same address will fail. Consecutive writes do not occur in the microcode, and write followed by read to the same address can occur only -18- READ wRite SELECT SELECT READ . DATA WRITE DATA ~ Figure 6: 3-Transistor Dynamic Memory Cell by writing into the instruction stream. Steve Rabin is the principal designer for the memory section. 13. Circuit Design Some of the performance and layout simplicity of Mosaic is due to a “hot clock” design style in which the clock signals may switch between ground and a voltage in excess of Vdd. The simple clock-AND bootstrap driver shown in figure 7 is used extensively and in several variations both in the processor and memory sections. In the memory, the clock-ANU is used so extensively that depletion pullup transistors are completely absent. Although referred to as a ‘driver’, this clock-AND does not provide power amplification of the clock, but rather passes a replica of the hot clock input, whatever its HIGH voltage, to the output as gated by an enable signal of low energy. The clock signal typically switches between ground and 7? volts with Vdd = 5 volts, but the chips also work correctly ai reduced power and speed with 4 valt clocks and A volt. Vdd. The delay and power dis- sipation of these clock-ANDs is almost negligible, and so the clock driving problem, together with the power dissipation usually required in control sig- nal drivers, is exporled Lo outside the chip where it can be dealt with using special driver circuits. -19- te ad LL erable rn | SYMBOL: Aenable enabler] ¢ > Ar enable p!_ ‘| Figure 7: Clock-AND Circuit This hot. clock technique allows pass gates controlled by clock-AND out- puts to pass signals with a full 5-volt swing, and makes the chip’s perfor- mance much less sensitive to variations in the depletion threshold voltage than in conventional Mead-Comway designs. Precharging is also used extensively in this chip, both to save power and for speed. Mosaic layout uses Mead-Conway nMOS design rules, substituting buried contacts for butting contacts. Overlaid wires of diffusion, buried contact, and poly are used to produce low-resistance wires which we call ‘buried wires’. 14. Design Tools The layout and verification was done on a VAX-11/780 running (limping) Berkeley Unix, with design tools written in MAINSAIL and C. Circuit design and optimization relied primarily on tau-model calculations. SPICE was used to evaluate bootstrap effects, technology dependence, and critical tim- ing paths. Extensive SPICE simulations were used to size the ALU carry chain transistors, but the speed improvement over the initial tau-model siz- ings was only 10% of the carry propagation time, a mere 3% of the processor cycle time, Cells were laid out initially using colored pencils and graph paper, and then coded in Earl [Kingsley82], a constraint solving geometry and - 20 - composition tool. Although the parts are composed in a rectangular bound- ing box discipline, the geometry internal to cells includes arbitrary angles and approximations of circular arcs, a form of “Boston geometry” that can be specified easily in Earl. This unusual layout style saved about 10% in area over 45-degree angle geometry, and about 25% over Manhattan geometry, The layouts of the ALU, controller, and register array, due to Don Speck, have a visceral appearance characteristic of shameless indulgence in Bos- ton geometry (see appendix C). For design verification, much of the logic design was coded and simu- laled using Le lecuary swilch level siuulalor MOSSIM [Bryant83]} to verify logical correctness, After the layout was complete, raster extraction of lay- out using a Boston geometry circuit extractor produced a switch network that was used in MOSSIM II [Bryant82] simulations. 15. Testing First silicon, received on @ February 1083, only 34 days after the CIF was submitted to MOSIS, was tested immediately and found to run code ata 7? MHz clock rate at room temperature. Subsequent processors fabricated using a faster process (still with a 4 micron feature size) ran at up to il MHz at room temperature. A missing contact cut due to a late change was found (missing) before fabricated chips were returned. Subsequent testing revealed two more bugs: an instruction MODE was microcoded incorrectly, and a controller “output type” specified the wrong number of half-cycle delays, causing port read-with-advance to advance before reading. The latter bug escaped detection by the ad hoc simulator because it involved a fractional micracy- cle phase relationship not represented in the simulator. Our testing experiences have been quite similar to those reported by several other university groups, and point to two interesting developments in testing for design verification. First, verification tools have become so good that nearly the entire design verification task is now accomplished before first silicon. Second, chips that are systems rather than components turn out to be simpler to test by placing them in their systern environment than in a conventional tester. -e21- 16. Acknowledgements Thanks to: Chuck Seitz for management, design review, Earl coding, and patience Don Speck for circuit optimization, layout, and verification Steve Rabin for quality control, verification, and mernory section design Chris Kingsley for Earl Howard Derby for early design OM for good ideas - 22. 17. References [Browning80a] Sally A Browning Hierarchically Organized Machines Section 8.4 in [Mead&Conway80] [Browning80b ] nally A Browning The Tree Machine: A Highly Concurrent Computing Environment Computer Science Technical Report 3760:TR:80, Caltech, 1980 [Browning &Seitz81} Sally A Browning and C L Seitz Communication in a Tree Machine Proce. Second Caltech Conference on VLSI, January 1981 Computer Science, Caltech [Bryantas] Randy Bryant, Mike Schuster and Doug Whiting MOSSIM I: A Switch-Level Simulator for MOS LSI, User's Manual Computer Science Technical Report 5033:TR:82, Caltech 1982 {Bryant83] Randal E Bryant A Switch-Level Model and Stimulator for MOS Digital Systems Computer Science Technical Report 5065:TR:83, Caltech, 1989 [Kingsley82] Chris Kingsley Earl: An Integrated Circuit Design Language Computer Science Technical Report 5021:TR:82, Caltech, 1982 [Lutz,Rabin,Seitz&Speck83] Chris Lutz, Steve Rabin, Chuck Seitz, and Don Speck Design of the Mosaic Element Computer Science Technical Report 5093:TR:83, Caltech, 1983 alsa Proc. MIT Conference on Advaneed Research in VLSI, pp. 1-10 Artech Books, 1984 [Mead&Conway80] Carver A Mead and Lynn Conway Introduction to VLSI Systems Addison-Wesley, 1980 [Seitz84] Charles L Seitz Experiments with VLSI Ensemble Machines J. VLSI & CS vol 1, no 3, Computer Science Press, 1984 also Computer Science Technical Report 5102:TR:83, Caltech, 1883 we 23 = MOSAIC PROCESSOR VERSION A INSTRUCTION SET page 1 of 3 (1-JUN-83) PROCESSOR FEATURES: Sixteen lé~bit general registers: RO... R15 Memory addressed as l6~bit words 12-bit Program Counter (PC) contains address of next instruction Flags: CU -= Carry/Not Borrow Z-—- Zero (all 16 result bits zero) N -- Negative (bit 15 of result) V -~ Twos~complement overflow Ports: Four input ports Four output ports Connecting an input port to an output port forms a fifo two 16-bit words long. ALL LNSTRUCTLONS: | MODE | OPCODE | K fj I | | i | | | | | | | | | | | | | | j 15 14 13 12 11 10 9 8 7 6 5 4 3 2 l 0 followed optionally by one word of immediate value. When K specifies a port: { MODE | OPCODE j|Adv|Dir| pt | J | | l i | { | | | | | 1 | | | | | | 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 pe its Lhe poct uumber; specifies one of 4 ports Dir=0 for output port; Dir=1 for input port Adv=1 to advance port (remove word from fifo) after input port is read KEY: Rn is register number n. val is the an immediate value. @z is the memory word whose address is z. A | B is the concatenation of bit field A and bit field B. L<L> weans E-th bit of £ . f<i:j> means i-th to j-th bits of f. Bits are numbered from least to most significant. outport ic output port number pt- inport is input port number pt. If Adv=1 then the port is advanced after reading its value. SPECIAL CASES: RESET: (Reset pin goes HIGH) CIVINIZ[PC —> @{-1); O-> PC MOSAIC PROCESSOR VERSION A INSTRUCTION SET INSTRUCTION MODES: ~ 24 ~ page 2 of All instructions fetch operands X and Y as specified by MODE, then perform the operation specified by OPCODE. MODE Dir xX Y Dest Assembly language syntax 0 RJ RK RK <Mnemonicy RJ {, Rk} 1 val RJ RK <Mnemonic> #val , Rj {, Rk} 2 Q@RI RK RK <Mnemoniec> @R4 {, Rk} 3 @val RJ RK “Mnemonic> @i#val , Rj {, Rk} 4 0 RJ 0 outport <Mnemonic> Rj, Ppt 5 0 val RJ outport <Mnemonic> #val {, Ri} , Ppt 4 1 inport RJ RJ <Mnemonic> <input> , Rj 5 1 val inport RJ <Mnemonic> #val , <input> , Rj 6 @RJ RK @RI <Mnemonic> M @RZ {, Rk} 7 @val RJ @val <Mnemonic> M G#val {, Ri} <input> ::= Ppt= to read input port pt without advancing Pptt+ to read input port pt, then advance port Note: Modes 6 and 7 are defined only for instructions that assign a result to Dest. ARITHMETIC INSTRUCTIONS: Arithmetic Instructions are those which assign a result to Dest. All arithmetic instructions modify the Z, N, and V flags. (Some instructions always set V to 0. They are MOV, COM, RNR, RNR, ASR, LSR, AND, OR, and XOR.) CARRY FLAG OPCODE INSTRUCTION <Mnemonic> EFFECT MODIFIED? 0O MOVe MOV Xx ~> Dest no Ol bitwise COMplement COM “xX —~> Dest no 02 INCrement INC X+1 “> Dest no 03 DECrement DEC X=] -> Dest no 04 NEGate NEG ~X -> Dest yes 05 Rotate Nibble Right RNR X<3:0> | X<15:4> —> Dest no 06 ROtate Right ROR CixX —> Dest|c yes 07 ROtate Left ROL X+X+C -> Dest yes 08 Arithmetic Shift Right ASR X<1L5>]X “> Dest|C yes 09 Logical Shift Right LSR O1X “> Dest jC yes OA ADD ADD X+Y -~> Dest yes 0B ADD with Carry AppDc X+Y¥+C -> Dest yes OC 3 =SUBtract SUB Y-X -> Dest yes OD bitwise AND AND X and Y -> Dest no OE bitwise OR OR xX or ¥Y ~? Dest no OF bitwise eXclusive OR XOR X exclusive or Y — Dest no ~ 25 ~ MOSATC PROCESSOR VERSION A INSTRUCTION SET page 3 of 3 NON-ARITHMETIC INSTRUCTIONS: OPCODE INSTRUCTION <Mnemonic> EFFECT 10 CoMPare CMP modify Z,N,V,C based on X-Y 11 JUMP JUMP X<1i:0> ~> PC 1Z undetined 13. undefined 14 PUSH PUSH Y-l -> RK; X => @RK; modify Z,N,V based on X 15 sTOre X at y STOX X=-> GY; modify Z,N,V based on X 16 undefined 17 undefined 18 PSH Jump PUSHJ Yel ~> RK; CIVINIZIPC —> @RK: X<11:0> —> PC 19 S§TOre Y at x STOY Y =—> @X; modify Z,N,V based on Y 1A POP POP @RK -> RJ; RK+1 —> RK; modify Z,N,V based on RJ 1B POP Jump POPS @RK ~> PC; RK+1] => RK 1c BRAnch True BRAT If Condition k is True then A<1LL:0> => PC 1D BRAnch False BRAF If Condition k is False then X<11:0> -—> PC 1E undefined LF undefined BRANCH CONDITIONS: Alternate <Mnemonic> K Condition (implies OPCODE=BRAT) (implies UPCUDE=BKAF ) OOpt Output port number pt Not Ready BONR BOR (i.e. no room in port to do output) Olpt Input port number pt Not Ready BINR BIR (1.e. no word in input port to read) 1000 V [overflow] BVS BVC 1001 N [negative] BNS BNC 1010 ~C {Carry = 0] BCC or BLO BCS or BHIS 1011 WN xor V [signed < ] BLT BGE 1100 Z [zero] BZS or BEQ BZC or BNE 1101 Zor N [<= zero] BLEZ BGTZ 1110 Zor ~C [unsigned <=] BLOS BHI Liil Z or (N xor V) [signed <=] BLE BGT When <OF Mnemonic> is BONR, BOR, BINR, or PIR: pt may be specified by writing "Ppt" in place of "Rk" field. ee ee a ee ae re ae re i ard =~ 26 = Mosaic ver. A microcode page 1 of 3 Version 14-Mar-83 MACROS DEFINED IN ASSEMBLER: Cin=0 :: Cforce Cin=1 : Cforce Cvall PC+t=>A :: PC=>ine Addl ine=>A A=>PC RA++->A :3 RA~D>inc Addl ine=>A Am~>RA POW?PA i: PGwpine inc~?A A-YPC => :: GP= OC Cin=0 nosh W=> Y=> :: GP= OA Cin=0 nosh W=> RJ=> ¢: useJ R=> RK=> $2 R=> RJ 7: useJ R RK ss OR Y+1l=> :: GP= OA Cin=l1 nosh W=> Y~1=> :: GP= A5 Cin=0 nosh W=> saveC ¢3: rnib TESTA 33: GP= OC Cin=0 nosh setzNv All alu outputs no xistors: NOALU 1: GP= FF cforce setC saveC Isr ror asr rnib nosh Mietore only in alu outputs: ALUONLY :: RA=>ine PC=>inc IN=>I Advance Pt=> RJ=> RK=> Pt RJ RK .FbackF Feedback memonics begin witha ’.” . Word names end with a °:’ ‘I=’ starts instr register mask starting with I<L5>. Unspecified bits are °*’. When ‘I=’ not given in some row, that from last row is used. "RESET—0’ implied when ‘RESET=<1' not specified. ‘Word0’ initiates outputs used when I<8>=0. *“Wordl’ initiates outputs used when I<8>=l. ‘Word’ initiates outputs used independent of I<8>. ~ 2 = ! Mosaic ver. A microcode page 2 of 3 row RESET=1 I= * * * * k* * * * * Kk Word RESET: saveC PC->A PC=> D .reset2 ! Take FFFF off the precharged undriven bus as old PC destination. row .reset2 Word RESET?2: A A=>PC A=>RA -reset3 ! Take first instruction from location 0 (=FFFF+1) row .reset3 Word RESET3: Write PCti>A fetch row .tetch Word FETCH: PC++->A_ .decode ! All instructions begin with DECODE row .decode Word DECODE: IN->1 RJ=> X YD RAtH=>A_ .get ! Fetch operands for all instrs: Word name is "<First op>,<Second op>,<Dest>" row .get I= 000 Word J,K,K: saveC PC->A RK=> ¥ “go row .get I= 001 Word #,J,K: saveC PCtHt->A IN=> X D «Zo row .get I= * 1 0 Word @J,K: saveC RJ=> A sget3 row .get3 I= 010 Word @J,K,K: PC=>A RK=> Y -get4 row .get3 I= 11 0 Word @J,K,@J: RK=> ¥ eget4 row .get I= * 11 Word @,J: saveC PCH—>A IN=> X eget2 row .get2 Word @#,J2: K=> A eget3 row .get3 I= 011 Word @#,J,K: PC™=>A »get4 row .get3 I= 111 Word G#,J,@#: -get4 row .get4 I= * 1 * Word any@: IN=> XD ° ZO row .get I= 100 Word io;no#: saveC PC=>A »Lo row .get I= 101 Word ioswith#: saveC PCH+->A IN=> X ¥ D eio row -io T= 10% PortC=1 Word I/O wait: X=> X Y D RA+=DA -get? row .get2 I= 1 0 * Word wait2: PC=>A saveC .io row -io I= 10% * * * * * * Q PortC=0 Word Willsend: RJ=> Y¥ °Z0 row .io =100%* * * * * 0 1 PortC=0 Word Get: Pt=> X D 2Z0 row .io I=101%* * * * * Q 1 PortC=0 Word Get: pe > Y -go row .io =100%* * * * * 1] | PortC=0 Word GetAdv: Pt=> X D Advance .go row -io T=101%* * * * * J] 1] PortC=0 Word GetAdv: Peas Y Advance .go ! Arithmetic instructions. 2 rows active simultaneously. ! Rows to handle results: row .go I= 0 * * Q Word Alu~>K: PC+t->A NOALU W=> RK .decode row .go =10%* 0* * * * * 1] Word Alu~>J: PC+HR>A NOALU W=> RJ .decode row .go I= 10% 0 * * * * * Q Word Alu~>Out: PCH ->A NOALU W=> Pt .decode row .go I= 11 %* 0 Word Alu>>M: NOALU W=> D-~ .sto row .sto I= * * * % Word Alum~>M2: Write PC->A fetch ! Mosaic ver. A microcode ! Rowe to specify row row row row row row row row 2 Zo »go «20 -gZ0 2go T= kek O ke & O k*e* OQ 28 - page 3 of 35 ALU functions 0 0 0 WordO mov: 0 0 01 Wordl com: Word0O inc: Word! dec: Word0 neg: Wordl rnib: WordO ror: Wordl rol: Word0O asr: Wordl Isr; WordO add: Word!l addc Word subs: Wordl and: Word0O or: Word1 xor: oe ALUONLY GP= 0C Cin=0 ALUONLY GP= 03 Cin=0 ALUONLY GP= OC Cin=1 ALUONLY GP= C3 Cin=0 ALUONLY GP= 03 Cin=1 ALUONLY GP= OC Cin=0 ALUONLY GP= OC Cin=0 ALUONLY GP= CO ALUONLY GP= OC Cin=0 ALUONLY GP= OC Cin=0 ALUONLY GP= 86 Cin=0 ALUONLY GP= 86 ATITONT.Y GP= 99 Ctn=1 ALUONLY GP= 08 Cin=0 ALUONLY GP= OE Cin=0 ALUONLY GP= 0 Cin=0 ! COMPARE (set flags based on X-¥) and JUMP row ego I= * * * 1 0 0 * WordO cmp: Word1 jump: ! Pushes and explicit stores * * * 1 01 * WordO push: row .go I= row row row row Zo2 -go I= *** 1100 ~go2 «203 ! Pops row .go I= row row ! Conditional Branches row .go I= * ** 111% row .gn T= 2go2 -go03 row .go I= row .go I= Word1 stoX: Word0O push2: Wordl stoX2: WordO pushj: Wordl stoY: Wordl stoY2: WordO pushj3: Wordl stoY3: kek 1101 Ce a 2 kee LT LYS kee LILI ** PCHt->A GP= 49 nosh nosh nosh nosh nosh rnib ror nosh asr lsr nosh nosh nosh nosh nosh nosh setZNv setZNv setZNv setZNv setZNVv setzNv setZNv setZNv setzZNv setzZnv setZNv setZNv setZNv setZNv setZNv setZNv setC setC setc setC setC Cin-1 nosh setZNV setC decode X=> A A=>PC «fetch Yel=> RK A -g02 Y=> A -go2 Write PC=>A testX fetch Write PC=>A testX fetch PC=> D ogo2 Y=> D setZNV gZ02 WordO pushj2: Yel=> RK A ~go3 X=> A -903 Write X=> A A=>PC fetch Write PC=>A efetch Word pop(j): RK=> YA -g02 Word pop(4)2: PC=>A Y+tl=> RK +g03 WordO pop3: PCH->A IN=> RJ X «decode Word! popj3: IN=> A A->PC fetch * Q PortC=0 WordO BraT_Pt=0: PC+t->A -decode Word! BraF Pt=0: X=> A A=>PC .fetch QO PortC=1 WordO BraT_Pt=1: X=> A A=>PC .fetch Word] BraF Pt=l: PCtt->A -decode 1 FlagC=0 WordO BraT F1l=0: PC+t->A -decode Wordl BraF Fl=0: X=> A A~>PC .fetch 1 FlagC=1 Word0O BraT_Fl=1: X=> A A~>PC .fetch Wordl BraF Fl=1: PCH= >A .-decode Mosaic VersionA Cirevir DIAGRAMS 4-34 Pads (46): Ground Reset Address Pad(@... WP = Scan iim Pad +Vdd Write Date Pad (@...1S> — scan.out Rad ¢, vn TP Pad @...3 % OPPad G...3 Contro | Jer lnp uts (17): Resef T<G6...15> FCond FB<O...3>% (feedback) ~POond Controller Outputs (41): * indicates ty pe "raw" All others type "et", Bus sources’. Ws PC> IND> RZ PLS Bus destinotions: =X =>Y >D >R Pt =A [>F ver. B only] ALU/shifter: Pog® Pg Pig* Pit Gn* Gigk GyF - rnib* yvor* fsr* acr*® — nosh* sett* sefznv Cforce Tvai~ Address section’ A2RA A2PC RAINe PCrinc* incPA Add4 Misc. : advance write IN®I used FBCa..39 - 30 - Controller Mosaic ver, A 4-P4 SCanain Repeot for LK 4, bitte ea cin mpl icant vyyers A (52) INC?) 4. Scan.In Ike, buffers ‘ input >—_ di i vr <f, AIND T when in ut 18 INCIS...9, 7, 63 me v other wise Scan_out Scarin PAVE AAA te par meg oly Jee ca i i "4. if T Fes | ae t ~~ Repeat for each ovt pul) Repeat for each in put (16) scan. out Connect scan_in’s to Scan-outs. Firs} scan.m +o scariin Pac, Last scan-ovul to scan-_ovt Pad. - 31 - ALY —= Mosaic ver.A 4-24 Repeat foc t= © to IS! EADX te Xt ye | Y A=>Y Propagate Generate L function fonction ees AED, block _ block | Pei Gc SSss sss FPF rr TS a g 2 3 = alul<itl> f % ¢ A - _ bee fe = +r P<i> iT , | _. . reskorin aoe not | (i=0,3, 6,9 2s) 2 restoring | az y : Call other | aluC<o - 32 - 4 ohifter Mosaic ver-A 4-84 Bit 153 . fA rnib LL + alvovot <3>,. m1, f Aror _L Clog I-14 WA Lsr Grw? pe W<1S? aL + >____I™ 1— , , S~L Bus <157 , “ase d zerow aluvout <15>, YAnosh oo 7 Repeat for i= @ to I4: Carmb — iL alvout <o+4 Mop 1670-7 YA ror Le __f 4 alvovt iti, fo wi? »—I1__ Bus <i? . . zecoW ¥, A nosh —_t ~ ~_ j — aluout CL - 33- Carry flaq (and ALU Carry In) Mosaic ver.A 4-94 | Se ee ee ee ee ee ALU Carry in Cfla | a —t Cvall Gasavec % (ef armb) YA Pe Fs Se a frie <1? I vss | Plog renCflag (= ©) ? AsetC YaAaror —_—— LL _L aluCddé6> or STL PA se LL ver, Wy . ASF ' f Aosr ! ao | i — <®> - 34 - Bus<12), PL Bus<i3? V, Nand Z flags Mosaic ver.A ‘1-84 Bus<i42 F—L_! rm SLs Bosc 1 2 _ 1 SetZNV >V + \ e alvC<i6> ver. B only at. | alu C<i59 1 i t ADF | faPc> } 1 | PAdEI Wiis) gg @ arcs ts! _L an Bus¢12), 1 — 1 JL» Bes <2) a a ea I a co a nee oe amnion e ~~ = zeroW - 35 - Flag Condition PLA Mosaic ver. A 4-4 T<6é) (¢(5) ISH) — preF Cond g @O @ V $ @ | N [<9] v) | 7) C [unsigned <] Oo | | N@V [ signed <] 1 @ @ Z l=9] | @ | ZYN (<ol | | yj zvc { unsigned SJ | | | Z¥(Nev) [signed <] preFCond = ( 146) AZ) v ( Tien Tesya 144) AV) v ¢ T<S)AT) AN ) v( 15,4 T¢4) AT) v ( TéspaTd) AN AV) v ( T4syaTeHy = AN AV) Use PLA te compute NoR- NOR form of oreFCond 2) —_—___— LL preF Cond —1|>— FCond (from PLA) Ge controller) - 36 - Address Section Mosaic ver. A 4-84 Repeat for (= @ to 11: RN apbinc me A 4 | poet Do Address Rad <i> ff PAA incC sit!) “inc = Addi iIncin<o > ncout <i) A incCti> Register Array - 37 - Repeat forn=D to IS: r Re eat “ee L=Pto lS A Y, tL I Mosaic ver. A 4-84 topo Lif It P| Bus <i> % Areadln] pte Place doHed bef Frans istors +o pull down when reell n#( $a) feong ” +25) £8 SQ) - 38 - o_ (Reqistec Select) Generechion Mosaic ver. A H-P4 : 4. 5¢3> —<(] <4 am _dt7) $43 ¢ LA 13? S<2? xf} 4 —< | aoe <1 (6) $42? <_ FTL <1(2? S<1> —<] xc ir. I(S> S<1> « | | L. E41) S(P? “IT aa ECD) S{Q> « | | Phi _.T<@ vyv¥viwvYv | 3 mor LABS | ye SN’ NY used oo +o Ports - 39 - Memory Data Intecface, Mosaic ver. A 4-84 Bus Precharge ej and Instruction Register WF Repeat for (= Ot IS: I + Data path LA>D to Near Pad —_ ee Dota Pad<i) Bustd : (tristate) | write p QaINn> Konig hed - 2 Super - — f, be ther) | | i eee - an ~ — eee eee Le “— PAINZT For c= 4,5, 6: near Flag cond rhon PLA For ten Ty lect OY near fegister Selec : ad To JIFe For t= G...15: \ 7 equivalent eircurt built ~_ | controller (Note duplications for Tdi) - J some bits) not needed In version B Output Pocts pq.1 of 2 - 40 - Mosaic ver.A 4-94 Repeat Loe n=@ to 3: OP Pad[n] Lo pee ees PA OPshett ww | LL —_ ry —~ i ns coe - Y 4 Pulldown ® Ele 8 1 | t=O4013 1 Ee, y ‘- OPshif4 In] op 4 BACPhood tn) emplytn] 3 OPatn<t? J Bus<) a4 LY soPshift fn) L_y mee ee ye ee errr 7 —_— — = lempty[n] +, PY G AOR {nJ / \ ya OPfoad [n] + —L — vee 4 1 L OPolnICD FL. 4 - 41 - Output Ports py. 2 of 2 Mosaic ver. A 4-84 Repeat for n= Oto: ¢4 OPsh fA In] ¢ AOPshft (nl cn OP Radin Fate) 2 + + “AWW 1 pe —__f tt { aaa 1) 3 | 16) ——+-— - Place dotted T <5) : z transistors ie ral tell to pull down Pe wel! Qrece i: hen T¢4) ! si i +21<S? ; aaceaee tates 4 ~ 42 - Input Ports pg: of 2 Mosaic ver.A 4-84 Repeat for n= @ to4t: Te Pod Ln] ght ¢@ = 2, { —L TPfulltn] > — r | coe we —v smn remem ment em emer etree emmy emu meme T a Xe OY —)p eet . — Ruslid | ne ¥ ATPread in] O " , r | Np. L=GtoiS * only fh _ 7 EY, Jytentin t cf $ L - + : Ya dk Gal Pshift Ln] badvanc ani wee le _+ a Tt Gratin IP Podtnil 2° pest Ln] c TPfollin] P aTPshftin] ~ 43 - Input Pacts PF 2of2 (and Port Condition) Mosare ver.A I-24 Repeat for = Bto3: 4 A advance Ln] — ._pre} PConel %*Pread fn] TPfilIind @) - pws + ¢—W-4+ advance | ' T<6> 1X6) ct ms ml Place doHted T¢S) fe trans)stors aa ft ely iy to pull down Is) 3 re | * | ankn beet ' ii aE Port Cond rhion OutCond t+ ¥, _. —, pet AN. ro PCond ~ 44 - MOSAIC PROCESSOR VERSION B INSTRUCTION SET page 1 of 4 (6-MAR-84) PROCESSOR FEATURES: Sixteen 16-bit general registers: RO... R15 Memory addressed as 16-bit words 12-bit Program Counter (PC) contains address of next instruction ¥lags: © = Carry/Not Borrow Zo—-~ Zero N ~~ Negative V ~~ Twos~complement overflow Ports: Four input ports Four output ports Connecting an input port to an output port forms a fifo two l6—bit words long. ALL INSTRUCTIONS: I | K | J | | | I 1 | | | | | | | | | | | | | 15 14 13 12 11 #10 9 8 7 6 5 4 3 2 1 = 9 followed by 0, 1, or 2 words of immediate value. When K specifies a port: | JAdv{Dir| pt ] J | | | { | l | I I | | | | | I | | I TS 14 13 12 iF 10 9 8 7 6 5 4 3 2 1 0 pt is the port number; specifies one of 4 ports Dir=0 for output port; Dir=1 for input port Adv=1 to advance port (remove word from fifo) after input port is read KEY: Rn is register number n. Rnt+ is register number n, incremented after reading. --Rn is register number n, decremented before reading. val is an immediate value. @z is the memory word whose address is z. A | 5 means concatenation of bit field A and bit field B. £ <i> means the i-th bit of f . f<i:j> means i-th to j-th bits of f. Bits are numbered from least to most significant. FPC is the flag/PC word: C | Vj Nf Z 4] PC SPECIAL CASES: HARD RESET: (Reset pin goes HIGH) QO —> PC SOFT RESET: (Interrupt pin goes HIGH for >=26 microcycles) FPC => @(-1); | O-> PC INTERRUPT: (Interrupt pin goes HIGH for 1 microcycle) FPC ~> @(-2); @(-3) —> PC m 45 = MOSAIC PROCESSOR VERSION B INSTRUCTION SET page 2 of 4 MOVE TNSTRICTTONS : | 0 Of MSOURCE | MDEST | K | J | a SC ON SN RN SON RN USN ORS NING ENN DONS SS 15 14 13° 12° 11 10 9 8 7 6 5 4 3 2 1 0 Assembly syntax: MOVE <source>,<destinatiom Execution time = 3 + Time(MSOURCE) + Time(MDEST) microcycles Ri meane Rk when MSOURCE ie 0, 1, 2, or 33 Ri means Rj otherwise. All move instructions modify Z and N based on value of X, and set V to zero. MSOURCE X <source> Time (MSOURCE ) 0 Rj Rj 0 1 @Rj @Rj 2 2 @R j++ @R j++ 2 3 @(R4j+val) @Rj+val 3 4 val #val 0 5 @val CHyal 2 6 Input Port pt Ppt+ [advance | 1 Ppt= [no advance] 1 7 0 0 0 MDEST effect <destination> Time (MDEST) 0 K~> Ri Ri 0 1 KX ~> @Ri @Ri 2 2 X => @Ri++ QR 44+ 2 3 X -> @(Rit+val) @Ritval 4 4 X -> Ge-Ri @—-Ri 3 5 X= @val @#val 3 6 X => Output Port pt Ppt 0 7 X ~> nowhere . 0 Notes: When source and destination both contain a val, then they are different (i.e. the instruction takes two immediate values). When source or destination is a port, instruction does not terminate until port is ready (i.e. until input port has a word to read or output port has room for another word). When source is a port, destination may not be a port due to contention for field k. ~ 46 MOSAIC PROCESSOR VERSION B INSTRUCTION SET ARTTHMETTC ANT BRANCH TNSTRIUCTTON MONFS: ~ page 3 of 4 | MODE | OP | Id | 15 14 13 12 11 10 9 8 7 Execution time = 3 + Time(MODE) + Time(OP) Assembly language syntax MODE xX YX Dest (when Rk not specified, k=j) Time(MODE) 2 Rj Rk Rk <OP Mnemonic> Rj {, Rk} 0 3 val Rj Rk <OP Mnemonic> #val , Rj {, Rk} 0 4 @Rj Rk RK <OP Mnemonic> @Rj {, Rk} 2 5 @vyal Ri Rk <OP Mnemonic> @#val , Rj {, Rk} 2 G @Rj Rk @Rj <OP Mnemonic> M @RJ [, Rk] 4 7 @val Rj @val <OP Mnemonic> M @#val {, Ri} 4 Modes 6 and 7 are defined only for OPs BRANCH CONDITIONS: that assign a result to Dest. Alternate <OP Mnemonic> k Condition (implies OP=BRAT) (implies OP=BRAF) OOpt Output port number pt Not Ready BONR BOR (i.e. no room in port to do output) Olpt Input port number pt Not Ready BINR BIR (i.e. no word in input port to read) 1000 ~V [overflow] BVS BVC 1001 N [negative] BNS BNC 1010 ~C {Carry = 0] BCC or BLO BCS or BHIS 1011 N xor V {signed < ] BLT BGE 1100 Zz [zero] BZS or BEQ BZC or BNE 1101 Zor N [<= zero] BLEZ BGTZ 1110 Zor ~C {unsigned <=] BLOS BHI 1111 Zor (N xor V) [signed <=] BLE BGT MOSAIC PROCESSOR VERSION B INSTRUCTION SET ARITHMETIC INSTRUCTIONS ~ 47 ~ page 4 of 4 All Arithmetic instructions modify the Z, N, and V flags. Some always set V to 0. They are: ASR, ROR, LSR, RNR, AND, OR, XOR, COM, BITT, and MUL C flag OP Instruction <OP Mnemonic> Effect modified? TIMECOP) OQ INCrement INC X+1 -> Dest no 0 1 DECrement DEC X- 1 -> Dest no 0 2 Arithmetic Shift Right ASR XC155 4X -> Dast|C yes 8) 3 Arithmetic Shift Left ASL X+X ~> Dest yes 0 4 ROtate Right ROR CIx -> Destjc yes 0 5 ROtate Left ROL K+X+C ~> Dest yes 0 6 Logical Shift Right LSR OIX -> DestiC yes 0 7 Rotate Nibble Right RNR X<¢3:O0>}X<15:4> -> Dest no 0 8 ADD ADD X+Y¥ -> Dest yes 0 9 ADD with Carry ApDDC K+Y+C -> Dest yes 0 A SUBtract SUB ¥-X -> Dest yes 0 B SUBtract with Carry SUBC YurKX~1+C -> Dest yes 0 Cc SUBtract Negate SUBN X- ¥ -> Dest yes (9) D SUBtract Negate with Carry SUBNC X~Y-~- 1+C -~> Dest yes 0 E NEGate NEG ~X ~> Dest yes 9) F INCrement with Carry INCC xX+C -> Dest yes 0 10 bitwise COMplement coM “x “> Dest no 0 11 bitwise AND AND X and Y ~> Dest no 0 12 bitwise OR OR X or Y => Dest no 0 13 bitwise eXclusive OR XOR X exor Y -> Dest no 0 14 CoMPare CMP X- ¥ yes 0 15 BIT Test BITT X and Y no 0 16 unsigned MULtiply MUL high word(X*Y) -—> RJ no 18 low word(X*Y) -> RK modify Z, N, V based on high word 17 undefined BRANCH INSTRUCTIONS: OP Instruction <OP Mnemonic> Effect TIME (OP) 18 JUMP JUMP KX~>? PC 1 19 Jump and ReSTore flags JRST X —-> FPC 1 1A POP Jump POPJ @Rk++ ~—> PC 3 1B POP Jump and Restore flags POPJR G@Rk++ ~> FPC 3 ic Branch True BRAT X -> PC if Condition k true Oor i * 1D ~=Branch False BRAF X => PC if Condition k false 0 or i * 1E PUSH Jump PUSHI Yel —> Rk; FPC —> @Rk; X —> PC 4 IF undefined * TIME(OP) = 0 if branch is not taken; 1 if branch is taken. When <OP Mnemonic> is BONR, BOR, BINR, or BIR: pt may be specified by writing "Ppt" in place of "Rk" field. ! Mosaic ver. Version 1 5eMAR#84 ! Syntax of implicants is: ! word <inputs> ! MACROS: DEF DEF DEF DEF DEF DEF DEF DEF DEF DEF DEF DEF DEF DEF DEF DEF DEF DEF Cin=0 Cin=1 PCtt=>A RAtH=>A PC>>A RJ=> ee ae B microcode - 48 - page 1 vf 7 <outputs> Cforce Cforce Cvall PC@->ine Addl ine™>A A-?PC RA~>inc Addl ine~>A A->RA PC—>ince inc~>A Anm>PC useJ R=> R=> useJ R R GP= GP= GP= GP= GP= GP= CGP= GP= 0c 86 oc c3 OF DEF saveC rnib DEF testX GP= OC ! FEEDBACK MNEMONICS: DEF .reset2 FB= DEF .reset3 FB= DEF ,.reset4 FB= DEF .interrupt2 FB= DEF .interrupr3 FR= DEF .interrupt4 FB= DEF .interrupt5 FB= DEF ,.interrupt6 FBS DEF .refetch FB= DEF .fetch FB= DEF .decode FB= DEF .get FB= DEF .get2 FB= DEF .get3 FB= DEF .get4 FB= DEF .g0 FB= DEF .go2 FB= DEF .go3 FB= DEF .mov FB= DEF .mov2 FB= DEF .mov3 FB= DEF .store FR= DEF .RJ+K- FB= DEF .PC-2 FB= Cin=0 nosh OA Cin=0 Cin=0 OA Cin=1 A5 Cin=0 Cin=1 Cin=0 Cin=0 GP= 00 Cin=0 ! rnib refreshes the carry flag. ! after DISPATCH: of every instruction. nosh nosh nosh nosh nosh nosh nosh nosh W=> W=> W=> W=> W=> W=> W=> This is done on the cycle Cin=0 nosh setZNV ree eee OO ODODOOCODOOCS MOOD DOCOOOFKE FE EEF OOODCOCO OF RFE RFP OO OOFRFrErFOOOFFF-o0c 0 orroorroOoorr OOFOCOOFrFODEF FOO OoOrOorOoOrFOrFOFOF OOF OF OFOrFOrFr SO ee ee ey ee ae ee ey — oe oe le ee ee a) a es Musale ver. B microcode CONTROLLER INPITS (21): ’FB= <fb4> <fb3> ... <fbO>’ "I= <i15> <i14> ... <i7>’ “KESET” “INT’ ’Flagt’ *PortC’ *Mout ’ *SRout’ ! CONTROLLER OUTPUTS (49): “FB= <fb4> <fb3> ... <fbO>’ ! Bus sources: “IN=>’ Memory data input ‘pc->’ Program Counter *Pt=>’ Input port pt *R=>’ ! Bus destinations: ‘D’ Memory Data out ‘PF’ Flags (C,V,N,Z) ‘Xx’ =ALU X input "Yshift’ “R’ ‘Pt’ Output port pt ! ALU/Shifter control: ‘GP= <hex digit><hex digit>’ ~ 49 - page 2 of 7 5 Feedback bits 10 Instruction register bits Unspecified bits are ’*’ (don’t care). When ‘I=’ not specified for an implicant, that from last implicant is used. Hard resect (’RESET=0’ tmplied when “RESET=1’ not specified) External interrupt flip flop set Flag Condition Port Condition (0 when port K is ready) Shift out of Multiplier/Product register Shift out of 16-bit shift register 5 Feedback bits ‘M=>?’ Wed? Multiplier /product ALU/shifter output If useJ then Register J, else Register K “A’ Memory Address ‘M’ Multiplier/Product “y’ ALU Y input ALU Y input, bus data shifted right, Carry from ALU into high bit If useJ then Register J, else Register K Carry Generate and Propogate codes (7 bits) Bits of each digit are for: (X=1,Y=1)(X=1,Y=0)(X=0, Y=1)(X=0, Y=0). LSB of G code (X=0,Y=0) must be zero. Carry in to ALU is (IF Cforce then (IF Cvall then | else 0) else old Carry flag) ‘Isc’ Logical shift right ‘rnib’ Rotate nibble “setZNV’ Modify Z, N, and V flags ‘Cforce’ ’Cvall’ ‘asr’ Arithmetic shift right ‘ror’ Rotate right ‘nosh’ No shift, and recirculate Carry flag ‘setC’ Set C flag to Carry out ‘Mshift’ Shift Multiplier/Product right ! Address section "PC->ince’ PC goes to incrementer carry in to incrementer is 1 (defaults to 0) incrementer output goes to memory address ‘Addl’ “ine=>A‘ ‘Aw>PC’ Address goes to PC { Miscellaneous *RA->inc’ Refresh address to incrementer “A->RA‘ Address goes to RA “INT:=0° Clear external interrupt flip flop *IN@>1’ *WRITE’ Latch instruction register with new memory data Write data in D to memory location in A “SRin=1" Inject bit into shitt register for counting multiply steps ‘used’ Let field J (as opposed to K) select a register ‘Advance’ Advance input port pt ! Mosaic ver. ! HARD RESET ! X and Y are assigned to make them digital, so ALU can make constants later RESET=1 FB= * I= * word hardreset: B microcode ! INTERRUPT AND SOFT RESET ! Interrupt: word word word word word word ! If interrupt word word word interruptl: interrupt2: interrupt3: interrupt4: interrupt 5: interrupt6: softreset: reset2; reset3: PCF-1 ~> @(#1); edecode einterrupt2 -interrupt3 einterrupt4 einterrupt 5 -interrupt6 persists, do a soft reset: sinterrupt4 sreset2 -reset3 - 50- page 3 vf 7 @(-2) ~> l= * INT#=1 INT-0 INT=1 :: INT:=0 XY RAt>A .reset4 PC. f¢ LNT:=0 Pvc=> X -interrupt2 ts X-l=> D einterrupt3 s: ~l=> A X sinterrupt4 s3 Write Z-1-> A winterrupt5 : «interrupt6 4 IN=> A A*>PC «fetch PCF=1 => @(-3); O-> PC, 2: Xe-l=> X »reset2 23 X-l=> A ereset3 Write sreset4 static and X and Y digital: ! While waiting for INT=0, keep storage word reset4: -reset4 INT=1 :: INT:s=0 X Y RAHA .reset4 word resct4: ereact4 INT=0 :: O=> A A=>PC -fatch ! FETCH AND DECODE word fetch: «fetch I= * 2: PCHe>A .decode ! All instructions pass through decode: (or interruptl: ) word decode: edecode I= * INT=0 :: IN->I saveC RJ=> KY DM RADA .get - 51 - ! Mosaic ver. B microcode page 4 of 7 ! REFETCH ON FATLED T/O TN MOVES word refetch: .refetch I= * 2: X-l=> A Ar->PC «fetch ! MOVE SOURCES USING REGISTER J (SO DESTINATION USES K) word RJ~?: get I= oo0000 2: POR?ZA «MOV word @RJ->: -get T= 00001 2: RJ=> A eget3 word @RJ++->: get I= 00010 : RJ=> AY -get2 Y+l=> RJ PC=>A .get4 word @RJ++->2: .get2 IN=> Y PCH=>A .get2 word @(RJI+#)—->: .get T= 00011 X+¥=> A .get3 word @(RJ+f)->2: .get2 IN=> K D mov mH Ht oO o * o word @-wait: .get3 word any~@: .get4 I= 00% * * ! MOVE SOURCES NOT USING REGISTER J (SO DESTINATION USES J) word #->: -get T= 00100 :: IN=> X D PC+HE>A .mov word Gf->: eget T= 00101 ¢: IN=> A ~get2 word @#->2: -get2 A PCH->A = .get4 word badPt->: .get I= 001108 * * * * 033 PC=> X .refetch ! Wait a eycle so controller can dispatch on port condition: word InPt->: eget T= O0O011L0*® % ®*** 1] ct: PC=>A .get2 word InPt=>: -eget2 PortC=0 I= O0OO0110%* * * * O1:: Pt=> XD omov word InPtA=>: .get2 PortC=0 I= 0011 0% & * * 11 2: Pte> XT Advance .mov word iofailed: .get2 PortC=1 I= 0011 0 ¢: PC=> X erefetch word Q->: get I=OO111 3: O=> X D PC=>A -mov ~ 52 ~ 1 Mosaic ver. B microcode page 5 ot 7 ! STUFF ASSOCIATED WITH MOVE DESTINATIONS ! Use register J in next two cycles only if MOVE source didn’t use it: word pickJ: «mov T= 001% * * * * 3: NOTRANSISTORS useJ word pickJ2: emov2 I= 001 %* * * * * :: NOTRANSISTORS useJ word store: estore I= 00 i: WRITE PC~>A «fetch ! MOVE DESTINATIONS PROPER word ~>R: emov T= a00**%* 000 :: X=> R setZNV PCH->A_ .decode word ->@R: -mov I=00*% * * 001 :: testX R=|>A -store word ~>@R++: -mov I=O0O0O* *%* 010 :!: testX R=|> AX »mov2 word ~>@Rt++2: smov2 2: Write Xt+l=> R PC->A .fetch word ~>@(R+#): .mov I= O0O0%* * * O11] ¢: testX R=> X »mov word ~>@(Rt+#)2: .mov2 it IN=> Y PCH >A »mov3 word ~>@(Rt#)3: .mov3 t: X+¥=> A estore word ~>@-—-R: mov T= O0O0* **100 :: testX R=> X »mov2 word ~>@--R2: -mov2 i: Xel=> AR store ! Note: Wait a cycle before taking #value from IN to guarantee correct data ! independent of MOVE source: word ~>@#: mov I= O00** * 101 ¢: testX PCH=>A =. mov2 word ~>@#2: -mov2 :: IN=> A «store ! MOVE to output port: if K specifies input port, then do nothing; ! if port isn’t ready, reverse side effects and refetch word ~>Pt: PortC=0 .mov I= 00%* * * 110% O:: X=> Pt setZNV PCH >A .decode word ~>badPt: emov I= OO * ** 110% 1 8: setZNV PC++->A .decode word ~>Prwatt: PartC=1 .moav T= 0000%*11 0 Pc=> X erefetch word ~>Ptwait: PortC=] .mov I= 00010110 i$ Y=> RJ RJ +t word RJ+tee: .RJ+b- 2: PC=> X erefetch word ~>Ptwait: PortC=l1 .mov I= 00014141410 PCc=> X »PC-2 word ~>Ptwait: PortC=l .mov I= 0010%* 110 :3 PC=> X «PC~2 word PC=2: »PC-2 I= * 2: Xel=> X erefetch word —>Ptwait: PortC=l .mov I= 0011%* 110 t: PC=> X erefetch word ~>*: «mov I= O00* ** 111 2: testX PC+H=->A -decode ! Musalc ver. ! ARITHMETIC AND BRANCH word word word word word word word word word J,K,K: #,J3,K: @J,K,: @J,K,K: @I,K,@J QH,J,: @#, I,K: G# LI, GH any@; . rs -get eget -get2 egetzZ eget »geta eget2 -get3 B microcode page 6 of 7 SOURCES I= 010 I= 011 I= 1%* 0 I= 100 I= 1190 I= 1 * ] I= 101 I= 111 I= 1** ! WORDS TO SPECIFY ALU FUNCTION word word word word word word word word word word word word word word word word word word word word inc: dec: aS5C;5 asl: ror? rol: Isr: rnr? add: adde: sub: subc: subn: subne: neg: inec?: com: and: or: xOr: «20 +20 e5YVU *Z0 «Zo +20 ZO «Z0 ry :46) «Z0 «Zo 20 +20 *g0 Zo ~go *Z0 £0 «Zo «go T= T= T- T= [= I= [= I= I= I= ! NORMAL ARITHMETIC word word word word word word word word ALU=>K: ALU-—>K: ALU->K: ALU~>K: ALU=>@; ALU>>@: ALU->@J: ALU=>@#: «Z0 Ce =49) «£0 *BO0 «Z0 Zo «stor «stor ** * 000 0 kee 0000 eee 0001 *** 0001 **x* 9010 ke *e0010 eee O01 1 ee * 0011 *ek* 0100 **e** 0100 *** 0101 *** 0101 *** 011 0 x**e* 011 0 **e*e 0111 x*eA* O1 11 *e*e 1000 *** 1000 *** 1] 001 ** * 1001 DESTINATIONS T=01%* O* I= 01% 1 0 T= 10* O0* T= 10% 10 T= 11* 0% T=11%* 10 eT=11 0 eT=-lil -~ 53- on ee ae se oe we ° «oe ° IN NORMAL ARITHMETICS MOrOFOFrOFOrFOrFr O7" OF0Fr 0 OO + * * * [o) Ce er ee ry eee er , eS ee ee TY 8 (8 #8 oF fe oe ee ee % bb as «8 ae ee 1 oe ae en oe eee * PC=>A RK=> Y¥ 20 PCH—>A IN=> X -go RJ=> A eget2 PC=>A RK=> Y eget3 KK=> ¥ -get3 PCH DA -get3 eget3 IN=> X 20 ALUONLY GP= 0C Cin=1 nosh setZNV ALUONLY GP= C3 Cin=0 nosh setZNV ALUONLY GP= OC Cin-0 asr sctZNnv ALUONLY GP= CO Cin=0 nosh setZNV setC ALUONLY GP= OC Cin=0 ror setZNyv ALUONLY GP= CO nosh setZNV setC ALUONLY GP= OC Cin=0 Isr setZNV ALUONLY GP= OC Cin=0 rnib setZNV ALUONLY GP= 86 Cin=0 nosh setZNV setC ALUONLY GP= 86 nosh setZNV setC ALUONLY GP= 29 Cin=1 nosh setZNV setC ALUONLY GP= 29 nosh setZNV setC ALUONLY GP= 49 Cin=1 nosh setZNV setC ALUONLY GP= 49 nosh setZNV setC ALUONLY GP= 03 Cin=1 nosh setZNV setC ALUONLY GP= OC nosh setZNV setC ALUONLY GP= 03 Cin=0 nosh setZNV ALUONLY GP= 08 Cin=0 nosh setZNV ALUONLY GP= OF Cin=0 nosh setZNV ALUONLY GP= 06 Cin=0 nosh setZNV 2: PCtH>A NOALU W=> RK -decode :$ PC+e>A NOALU W=> RK -decode t: PCHe>A NOALU W=> RK -decode 7: PCHe>A NOALU W=> RK -decode o: NOALU W=> D estore 33 NOALU W=> D store :: Write PC->A «fetch :: Write PCH >A -tetch - 54 - ! Mosaic ver. B microcode page 7 of 7 ! SPECTAT. ARTTHMETTCS: MULTIPLY, ETC. word cmp: .go I=** * 10100 t3 PC+t->A GP= 49 Cin=1 nosh setZNV setC -decode word bitt: .go I= ** *10101 :2 PCH—>A GP= 08 Cin=0 nosh setZNV decode word mul: .go I= ** *}] 011% 3: Mshift O=> Y SRin=1 02 word mulU: «g02 SkKout=0 Mout=0 i: Mshifc Y=? Yshift RAtt"->A .g02 word mull: -go2 SRout=0 Mout=] :: Mshift X+Y=> Yshift RAH=>A .go2 word muldone: .go2 SRout=1 2: Mshift Y=> RJ setZNV PC~>A_ .g03 word mulend: .go3 te M=> BK BC++—DA .decode ! BRANCHES word jump: +Z0 I= *** 131000 :: X=> A Am>PC fetch word jrst: -go I= ** #11 001 :: X=> FA A->PC fetch word popj: Zo I= ** *1101% :: RK YA -go2 word pop j2: ~go2 t: Y+l=> RK -g03 word pup j33 «g03 Ie ** * 11010 ¢s: IN=> A A->BC «fotech word pop jr: «203 T= ** * 11 01 1 2: IN=> FA An>PC «fetch word /->PC(P=0): .go PortC=0 I= *** 111000 :: PCH->A -decode word ~>PC(P=1): .go PortC=l1 I=*** 111000 :: X=> A A->PC .fetch word /~>PC(F=0): .go FlagC=0O I= * * * 111001 :: PCH-A decode word ~>PC(F=1): .go FlagC=1] I= *** ] 11001 2%: => A A~>PC .fetch word /~>PC(P=1): .go PortC=1 I= * * * 11101 0 ¢%: PCHeD>A -decode word ~>PC(P=0): .go PortC=0 I= * 4% * 111010 :: X=> A Axm>PC -fetch word /~>PC(F=1): .go FlagC=1 I= ** * 111011 :: PCH-D>A decode word ~>PC(F=0): .go Flagc=0O I= *** 1121011 3: Ke> A A->PC fetch word —>PushJ: *Z0 =**e ] 111% 2: Yel=> RRA 2go2 word —>PushJ2: ~go2 2: PC=> D 03 word ~>PushJ3: 203 2: Write X=> A A->PC fetch - 55 - Mosaic VERSION B CIRCUIT DIAGRAMS 4-94 Some os Mosaic ver.A exceph |. As indicated in ver. A Tnstruction register and Flags 2. Replacing controller 3, Including SR and M registers replacing YU requster 4y Tnclvding Interry pl flip flop Additional Pads: Addit onal Controller Inputs — Additonal Controller Outputs : * indicates type “raw: A\\ others type "e1" M> | =>M 2Yshiff 3F Msheft * SR in* INT<@ FB<4> -~ 56 - Controller | Mosaic ver. B 4-24 (Replaces Mosaic ver. A | controller) Repeat for each implicant + 4 “7 ~ if? Fong 7 | Yo 5s $+—< ¥,, AIN9L when input is IPs go TN (15...6> ce It Fo. otherwise + IC Connect scan -in’s te scanout’s. == First Scan.in to scan. Pacl. ¢ 1 Last saan.out to scan_ovut Pad. ra type type Scanin 4 5 cl iT} e " Caw" L e A ! to Ft, FY, s 1 | i j . ¢ an book i — Select: output L- fo %, Hog S “ype per = o. Ov Pp ~ ut scan. out . - 57 - SR Any M_ REGISTERS Mosaic ver.B 4-94 SK Shift Register for covating multiply Steps SRG? =SRin- ff SRCLtHY rf, Repeat for L=DtolS + ¥, Le SRCi> M Multiplier/ Product Reaistec M<16) = Y<-1> ~ 58 - Y register (and Interrupt Flip Flop) Mosaic ver. Bo 4-84 Y (Replaces Y register of version A) ga aNGhitt 4 Hoy pep alu <I 6) Bus¢IS)5_ 171 5 ¥CIS> Repeot | Buscittyy Fo €Peot | RBusditl) sf L __ for ingly) YAN ~—— — — — Sima” — — — ° — lntercugt flip flop | _INT —L INT Pad > NT req = . INTRE {, A INTE@ 59 - D LAYOUT Controller | ———> IN<2?) Vdd from ut {907 UIDS oo ESE Corcuit Pg: 30) \yt ? (nol Fee cs SS fun! a5 = RRS AALS AAA | oat 47} input plane IN¢? 8 ~~ a 7. 2. iN i) 4 E type Mey + ov AD) > SELECT raw output plane + pe Fou APPENDIX C t ov N Tes ap . Sa ORGS ues oe AAT SaaS eeee cee RENAN] S ah . AN <i TASAS Mee phi NS SEY ee paki PASRAN ST TATRA E TINH Sy ee SRS SS STIR ASA Sx BS La NS 5 Oh SS) S's AREA NS ASS SSNSSSSS: AS ANLAS UL TUS TANNA ATS 60 - precharge, SR, ivy and M reastecs NS SARAS EASA EST Rane CE EALERE: ¥ COKE SRST SS Reastec arroy, Buc SSNS SRSA PAR SAAR, MEAS AN: WSSSSASERS Neasgeasas x CRE QIYWECI-SA | ae a e————— 948 22ULO Kuo po ‘S| PS 4G > _ | J J a k& (Uana $11) sa>1|8 4197 Kuo ——__—_> i ~ —y— (LS : Gd fENDAVD) (LS ‘2d ANID) W US SAg (bs bd INDAND) ahuourasd M4 JD Ja4Sla>} as (Zé . bd 41ardtry 61 - ALU. input lotches and function blocks Cewcuit CT GLE . PETES BeOS BY os RX: y Bus<t? aa ae TOLCRE CEA OE CLARE ELLIE EEL: iy EE te: Serer Ug Qr= Bus<it | FAATEEOCLEL CO ELEELLOL EE Saat |s 419 7 Kuo — Sou a —— YO — Ny - Kawod R14 320 1F (35 bd Kop Volpotyipod Pas — va4sibaJ OW aye oA F443 UdS) §dY>4y9| 4ndey. WN 62 - Carcect PY 31) ALU Coery Chain £I9SNg C140 004 E1st> 3549 C1479 4ean[o E ulgg°=V <— Ja4jsUs Aes? ae ES EEE ee ASA SAN SENET 8 < POET TEC CCE COPELES, 2G HAN SN NS NAMEREBASAS: NN SSSR AS wy AS AANA YANSAN ESS NO EE EE SS i COC RRR ESS SS aS ONSEN ; TL SHANSNS SY a NS ABSSAS ENS SAN ANSANSS AAAS Raacysy: SSSR RS ca PELE co eens ete NSSSARAAS aut AAT ACR Na SAN: VERY SESS A ae CLAY QA 4292912 Puy PPA Puy A KVYS0Q 4 Od as : vi AAA AAAAAAAAAAAT aa Restoring stage ery propog ation) f e ¥ rection of ca datas sta ys Levene BRS Fa pind eee SAREE: M Patel stat oe aa Non-restorin (Snat| indicates - 63 Flags and Flag Condition PLA Ceiecuit Pg: 33-35) new F lag Ca Ry SSS RANA NA SAA SEARS ISSR barra) SoeeS at SS EPs OR SS ie wi * LES e 9 ay ~ SEESEISS NNR] ES, ry SSN. MANNE NANA S Buscl ANS AS NSANSSSSANS y Bus¢ Ky: N SATENAT SS INNA NS NSS SANS $3 Up epiiprecce Vdd Gnd Vdd VERZE ARE TI ATT OCA COIITOPPILTOUCEOUPILITTCCLOLELTIN ELON? 64 J NSASRANAYN ASA RRC an LANs RSNapeces SEAR SSS SABRRSES SS SRC ARES AN NCAA CT SASS NLU SURURULLS AANSNANSANANSE LVS VAS SS, Noose RAS ee SSRASARSLYS ARS ASS fas : coxs R C1$5 5S RSSSSSh SESEESSUSSSSSSSSSE SS EESSSRSSSSs ESTO Sa ESSER ESSN OS EEE Sy SSNS EESEEATO OS ONT EOI OU ETT NE SSS SRR SES SR SESS IN ERS REA a 5 ie ae . Bae we a = Ny RSS Senet yy $ 3 -UNLLRA SN! x o howe » s A. .s nn IN: . SANS s ms SR GRALS $3, Oe NS ae SSEEEEE SN Rehiity SSAST] Beet N SNASSAY . m3 re ASANANS ~ SRS SASSY Kh Se ee bt sed iNet iy te SRS ee) xs SURREY ed ~ SSANANAN A555. tal Nag cPNSELSS, ANS SANA NAS ANR AAR hs a PSERRCURRNUNAE NA NAN Aaa eta Cran x “A AAASAS AN S He} SECS NE RG ESSSEESS BA SIC cs -Biate! : oH ‘ ay 5 cen 3 Nene | eases Te eee Bes) earns ENN Sh ee ‘a y SA NAANSN WAAR: Pi SSSAR SSS 7 I x: ad 7 SYN SSNS VANS SA EELS BESS S555 ‘ 5 conn INSO9 Ress RRN SSSERSSY EERE 3 AAPA AS SSS ~. NASA YNANARTEULU USAR NAAR, SASSSIRERTAR SANG UCIAE NAAR ey katana s SSD. RATNER NS AN SR SANS SR ASNBUCUCER SSA DOCK SANA ESS A ERE SAS 7 4 4: 4. ae 35. ete eee Raeace eae Keeh ee FA ee Lepore Eee POET, Rs RENAN SSE NSANSSSS COTTE S SN ee ss ; SNSNSANS TRANS SASL ASN SSE KI4DV Ppuaspog Sass SES BS KELLT S 50800 eas bY 4'9 7 huy Address Section (circuit Pg: 36) = U x nannanes neeancecaeaced: WAT Ae gees s. iG sere eses. Bae Eek AR bs =G..13 t _ 65 PPRRRAL LE EAE bit From =BA3 PEC PAEEL EE, wv) + ty oO OQ. PPA sfaed rodut JA0|n} TTT TN SS INNA NANASAARAN SAN SASS SYR NS ASSN SSS ANS NS SY ANN SANA SSANSSNSAS: NA ASS SANS ASF RSSERS yee 22) COOLEAAPLIDA CLECLEELL AGE, wv + > QO. 4 30¢j anduy fla POPS EES Metra eTES. KAA Race AS SSASEACATS AS: om & bit fr AN! SS aS NS NN 3 AN SS 33 Tin <|— | . J . z= GPCFELOLTES A sereree| RRS ENSCRAN: SSRS NESS a 7 POPE PLAPPLESS $9332) ) a (or “6d 420d 40d 409 |