MemoryControllerSpec.tioga
Copyright © 1986 by Xerox Corporation. All rights reserved.
Last Edited by: Gasbarro September 24, 1986 4:47:36 pm PDT
June87 Memory Controller
Board
The June87 Dragon Memory Controller board supports four banks of random access memory. Banks operate independently so that total memory bandwidth is roughly proportional to the number of banks in the system. Each bank will initially consist of 8 MBytes of Single-Error-Correct, Double-Error-Detect (SECDED) memory using Single Inline Memory Module (SIMM) mounted 1 Mbit DRAMs. There are nine RAMs per module and eight modules per bank for a total of 72 RAM chips (64 data + 8 ECC). The controller chip allows for expansion up to a maximum of 16 banks, though there is no space or power provisions in the current package to accommodate this much memory. Banks must be added in increments of powers of two. The controller chip also provides extended addressing capability to provide for future generations of DRAMs. The 1 Mbit SIMMs can be upgraded with 4, 16, or 64 Mbit parts. A complete bank of memory consists of the eight SIMMs, the controller chip, three AS-TTL drivers for the RAM address and control lines and possibly an additional chip providing timing for the RAM. These parts will occupy ten to fifteen square inches of board space.
Chip
DynaBus Interface
The memory controller responds to the following DynaBus commands:
ReadBlockRequest - reads four 64-bit words from memory
WriteBlockRequest - writes four 64-bit words from memory
WriteSingleRequest - reflects reply and data to caches below
IOReadRequest - returns first failing address and syndrome
BroadcastIOWriteRequest - reflects reply and data to caches below
The memory controller maintains a queue of those Dynabus commands which it must act on. These commands are executed in the order in which they were received. If the queue is so full that another command could cause it to overflow, the memory controller negotiates with the arbiter to stop incoming requests.
Data Path
The data path of the memory controller chip, illustrated in the block diagram [1], is fairly straightforward. The memory controller generates the error correcting check bits for every word that is placed on the Dynabus. In parallel to this generation, the word is decoded by the Input Control FSM to determine if it is a command intended for this bank and if so, how many data words follow. Only valid command and data words are entered into the input FIFO. When a valid command propagates to the front of the FIFO the Command Decode FSM determines what RAM operation should take place, assembles any needed data in the Write Buffer, and initiates the RAM timing sequence. When the RAM operation has finished and any result has been latched in the Read buffer the Command Decode FSM registers a reply request with the Request Queue FSM. This state machine keeps track of the number of pending replys and the number of cycles each requires. It in turn issues a request to the Reply Control FSM to negotiate for the Dynabus and ship the Reply Command and Data. In order to improve the utilization of the RAM, the Read buffer is implemented as dual-ported ping-pong buffer. Thus, while one command is waiting for it's reply to be sent, another RAM operation can be initiated and the results stored in the other half of the Read buffer. The Buffer Control FSM handles which port of the buffer should be read/written next.
Control
Most of the control circuitry of the memory controller is implemented in the five finite state machines. Of these five, two have been implemented with hardwired logic. The remaining three will (hopefully) be automatically generated.
RAM Timing
The exact implementation for the RAM timing generator has yet to be determined. There are three possible candidates: an external timing generator chip (Am2971), an internal phase-locked loop delay circuit, and an internal synchronous state machine generator. There are many factors upon which to base the selection for the implementation method, including risk, cost, number of pins, board space, and access time. Fortunately the decision can be delayed for quite some time while other aspects of the system become more clear.
Delay
The most important timing spec for the memory controller is the minimum delay from a ReadBlockRequest on the bus to the first word of data delivered. This delay is the sum of the following delays: five pipeline stages between the bus and the time that the CommandDecodeFSM initiates the RAM cycle, the total RAM access time (from RAS to the last nibble), and the output pipeline delay. The RAM access time depends on how the timing generator is implemented and on what speed RAMs we choose to buy. Upper and lower limits are 450-300ns. The output pipe delay is more interesting. Since the data is delivered from the RAM in the same cyclic order that it must be shipped on the bus it is possible to begin filling the output pipe before the end of the RAM access time. Thus, the output pipe delay is actually negative three cycles. In addition to the data delay there is the concern that Owner and Shared must be received before Request can be asserted. These signals are not valid until ten(?) cycles after the Request cycle. Added to this is the minimum delay from Request to Grant as determined by the Arbiter (3 cycles?). The total delay then is:
MAX[(2 cycles + 300-450ns), 13 cycles]
Assuming a bus cycle time of 25ns and the fastest RAM access time, the minimum Request to data delay then is 350ns.
Throughput
Assuming minimum timing for the bus and RAM, the throughput for a single bank of memory is limited by the ability to cycle the RAM. There are three cycles of overhead in the state machine in addition to the cycle time and the precharge time. Precharge time for the fastest RAMs is 100ns, so the minimum cycle time for the RAM is three cycles plus 400ns to deliver four 64 bit words. The throughput then is:
4 words / (3 cycles + 400ns)
= 8.5 MWords/second
Debug Interface
The system's DBus will be used to download various registers at system initialization time. The Memory and IO address space which the Memory Controller occupies must be programmed before any accesses can occur. The DBus is also used to initialize parameters specifying the size and speed of the RAMs used and the refresh rate.
Features Yet To Be Implemented
Owner, Shared Fifo
RAM Timing Generator
DBus Controller
References
[1] Block diagram
[Indigo]<Dragon>MemoryController>MCBlockDiagram.dale
[2] Schematic (in progress)
[Indigo]<Dragon>MemoryController>MC.dale