Main Memories

This computer uses a derivative of the "Harvard" architecture, meaning that instruction (or code) memory is separate from parameter (or data) memory. This separation allows some operations to be performed faster but at the expense of additional hardware and requires a few additional machine instructions. Since there is no cost to added hardware, this is a sensible choice. The greatest benefit is that a new instruction may be fetched while other data operations are being executed. This could reduce instruction fetch latency to effectively zero time for many instructions.

=Data Memory (RAM)=

Both arrays are nearly identical in their control and timing, from an electric point of view. The data RAM will be described first and the differences in the ROM sub-system will be detailed after that.

Logical Design
The base memory device in the environment is the Memory Bank. (You should be familiar with this device before proceeding.) It is used in synchronous mode since the CLOCK input must be connected.

The lowest 8 bits of address are used by the base memory device directly. Enough devices are "stacked" into 'modules' to provide the necessary bits of storage (6 for code and 4 for data). The higher 8 bits of address are decoded by a single PLD (Memory Bank) uniquely for each module. This decoder output is combined with the control signal and fed to the module's CLOCK inputs and output enable buffers.

These modules are duplicated enough to provide the required storage and are all bussed together.

Electrical Design
The base memory 'chip' - the Memory Bank - has separate connections for data in and data out. See the description here for more complete information on the "Bank". The data output of the Memory Bank is always active so it must be fed to an "output enable" buffer (an AND gate). Control of this buffer comes from the local address decoder. The buffer output may then be bussed across the entire array. The data input is ignored by the M.Bank until specific conditions are met at the CLOCK input. Thus this signal may be bussed directly together throughout the entire array if desired. For this design this bus will only connect to the Debug Station. The processor core will not have direct access to program memory and must treat codespace as ROM.

The CLOCK input is used in this circuit to allow the chips to be programmed through the use of the debug station and so must be used during normal operation as well. This also makes the memory a synchronous device. On each memory read the CLOCK must rise from '0' to any value '8' or greater for the M.Bank to read the address inputs. The data output will then be valid at the next system 'tic'. This CLOCK signal must be unique to each module and is generated by a combination of the high-order address and the RomCntl signal.

The control encoding circuit comprises 3 M.Banks used as PLDs. One decodes the high-order address lines to create a local Module_Select signal which goes to the remaining 2 PLDs. This M.Bank is programmed to respond to a single high-order location and each module must have a unique program. Any module may be programmed into any memory space location.



Controls and Timing
This system uses only 2 control signals. They are "Latch_Addr" and "RAM_Control". RAM_Control initiates the read and write process and enables the output buffers. A '1' on bit 3 of this signal will initiate a read of the M.Bank. A '1' on bit 2 initiates a write (read has precedence). A '1' on bit 1 enables the output buffers (ignoring other bits).

The address lines must be stable when Latch_Addr is enabled. There must be a 2 tic wait once Latch_Addr is enabled before RAM_Control is activated for either a read, write or output enable. However the delay from a read function to stable outputs on the M.Bank is 2 tics. So the safest sequence is to enable Latch_Addr (assuming the address is already stable), wait 2 tics to send a read request, and wait another 2 tics to enable the output buffers. The M.Bank itself has latched outputs but the buffers are NOT latched so the buffer control must be held enabled until the data is safely latched at its destination.

The M.Bank is dual ported RAM so any time the address is changed a read must be executed to update and latch the data from the new location.

NOTE: To avoid glitching in the data output it is necessary for the output enable to be delayed following an address change or write cycle. (It would still be outputting data from the last location referenced.)

Layout Design
The arrays are built such that each 'module' is a vertical column. Sixteen of these modules are built into a 'stick' and sixteen of these memory sticks are layed out in the array.

Since each module may be programmed to respond to any high-order address and control input combinations, they need not be placed in any particular order. However a stick of 16 can accommodate the full 4-bits of an address signal. It will also make visual verification and initial testing easier. This layout will be up to 16 rows of 16 modules, each using 6 cells each providing 256 locations of 24 bits of data, for a total of 65,536 words or 1,572,864 bits of storage!

Much time was spent in layout to create the smallest footprint cell as possible. It works out to a 3 x 4 x 3(high) space requirement. These cells could be tightly abutted but then there would be no chance of later inspection. Rather a single blank plane is allowed between rows of modules.



The data streams connect horizontally between the modules so they are brought out to one end of the array where the rows are connected horizontally with the input and output streams separated. The input stream only connects to the Debug Station and the output will go to the Station but its primary destination is the Instruction Decoder Circuit.

The (2) address inputs and the (2) control lines of each cell are chained vertically to create the coherent module. The modules' (lowest-order) address lines are connected horizontally along and just above the rows of memory modules and brought out to the same end as the data streams. Here each row is connected as with the data streams. All (4) address lines go to the Debug Station but are generated by the Program Counter in normal operation.

The control lines from the memory cells continue above the mentioned address line and are generated by the high-order memory decoder and CLOCK encoder circuits. These circuits lie at the top of each module. The (2) high-order address lines connect horizontally between each module and go to the same end to join their fellow address lines. The RAM_Control line runs along with these address lines and is brought out alongside them.

=Instruction Memory (ROM)= The instruction memory is 24 bits wide which is ample for this project. There will be 32K (or 64K?) words available to the programmer. This ROM is meant to be considered inviolate by user programs. However there will be provided some special instructions to transfer data from RAM to ROM. In order to place the low level routines and higher programs into memory this design does support a programming mode where the ROM may be read and written directly from a programming and debugging station.

The differences between the ROM and RAM are the size as noted above and the connections to the system.
 * ROM data output is instruction code so it is not connected to the data bus by default. Rather it has a direct connection to the Instruction Decoder.
 * The control inputs are generated by the Program Counter but may be overridden by use of the special instructions and the Debug Station when that is used.
 * The Program Counter includes a latch on its output so there is no local latch for the address lines.

=Notes=
 * Would some local processing help? E.g., an auto-increment built into the memory controls.
 * Hopefully the PC can maintain a continuous 'enable' for the ROM output eliminating another latch stage and saving 1 tic access time...


 * During implementation it was found that the complete ROM array caused a system overcomplexity 'glitch' which does not affect operation but does create graphics rendering errors. These errors would make it impossible to visually inspect the array. The problem was avoided by reducing the memory capacity by half and removing every other row of modules.