History of the Memory Bus

I write about the memory bus because it is a place to stand to introduce some names and ideas that have pervaded computer architecture since 1960. These ideas are highly critical to understanding the security attributes of a computer system.

The IBM 704 computer (1956) and its predecessor, the 701 (1954), considered the memory to be accessible solely to the CPU. I/O was accomplished by the copy command which would move data between a program accessible word, and the I/O device. With the 709 there was a new way to send data to memory or retrieve it. The ‘channel’ could access memory asynchronously to what ever program the CPU was executing. IBM was not much ahead of or behind others building computers in this regard.

The PDP-6 form Digital Equipment Corporation (predecessor to the PDP-10 and KA-10) was delivered to customers along with instructions on how to modify the machine. I do not recall the terminology used in those instructions but the following picture was made clear: There were several core memory boxes with an asynchronous interface. There were several other units delivered by DEC along with a typical PDP-6, that required access to memory, unmediated by the CPU. The ‘memory bus’ was that ‘cross bar’ that attached to each memory box, and to each unit that required access to memory.

The logical purpose of the memory system (memory boxes and memory bus) is to provide the clients with a set of numbered memory cells of standard size. The numbers are called ‘addresses’ and the content of a cell was called a ‘word’. When a client reads a word from memory what ever word stored at that address by any client is delivered to the reading client.

There are two good reasons for having more than one box of memory:

Even one CPU was often able to keep two boxes busy if data and instructions were mostly in different boxes.

In this era memory box latency was several microseconds.

To allow concurrent box operation the memory bus was redesigned to use synchronous clocked logic; a read request would occupy the attention of the bus for a fraction of a core latency. The returned word would occupy some other part of the bus during some predetermined future cycle. Other parts of the memory bus would consider simultaneous requests by memory clients and perhaps determine order by foreseeing and avoiding future scheduling conflicts. (Some computer systems had memory boxes of more than one latency.)

At least two architectural developments came along to muddy the simple concept of address space and its impact on the memory bus:

Over the five decades of this history the CPU clock has become about 104 times as fast while memory technology as become 102 times as fast. The cache was invented to aid this lag and while an ugly idea, has entirely conquered the design of systems. What programs must be aware of the cache? IBM held that not even the privileged code should worry about the cache. The Intel world of PC’s has largely held that the kernel must be aware of some aspects of the cache, and even on occasion the application might give hints to lubricate cache logic. The application logic was mainly (entirely?) in the form of semantics free instructions that might make the program faster.

The memory map plainly split the concept of address space into two parts:

The memory map mapped the virtual address into the real address. The good news was that the new address space concepts each played a role in the design and description of computers.

How does the memory bus relate to the map and the cache? Usually the cache is associated with the clients and not the memory boxes. The cache was invented to boost the CPU but what of other memory clients? That depends on another dilemma: is the cache addressed by virtual or real addresses? Modern systems have two or three levels of cache and there are as many questions. I think that today the memory bus is always nearest the real memory (DRAM) and thus real addresses are delivered by memory clients to the memory bus.

link, link