270 THE PDP-11 FAMILY
2. Is the bus well specified (and well documented), so that a series of interfaces designed either concurrently or over a period of time by different engineers will in fact be compatible?
3. Does the bus avoid imposing unnecessarily strict performance constraints on the system?
4. Is the cost of the bus and its connections commensurate with the computer system and the bus' role in it?
5. Does the bus design anticipate expansion of the system in the future (without excessive cost)?
6. Can the bus be manufactured and tested in high volume production without excessive hand-crafting or tuning?
Beyond the scope of this chapter are some additional functions of buses, such as providing a means to diagnose and repair the system components connected to it and to allow measurement of system loads and performance.
Why Buses Are Important
As the above list of criteria suggests, there are many ways in which poor bus design can spoil the performance or cost/performance ratio of an otherwise well designed computer system. Failure to anticipate future expansion of a computer system is a common problem in bus designs. The PDP-l1 Unibus, a very successful bus, first became inadequate as the main interconnection pathway when processor and memory speeds surpassed the bandwidth capability of the Unibus. Later, the Unibus 18-bit memory address width became a limitation.
Computer design is driven by advances in semiconductor technology. Every time the cost of the components of a computer subsystem decreases by, say, 50 percent, the subsystem is redesigned to take advantage of the lower cost. At present, the performance/cost (or storage capacity/cost) ratio for logic and memory is increasing at a rate of up to 100 percent per year. But the bandwidth/cost and other performance ratios of interconnections are steady or decreasing slightly. As a result, bus designs tend to persist in time across several redesigns of the other computer system components. This justifies the extensive engineering effort required in the initial design of a bus.
How Buses Are Designed
To design a bus, the engineer must first find out what system components are to be interconnected. Then, studying the requirements of communications between these components, the engineer chooses a structure. Finally, the cost constraints and available technologies lead to a choice of implementation.
The five-function model given below is not a set of bus designs but a functional model that results from taking the commonly used minicomputer building blocks and asking: What communications need to occur between this component and each other component? The model shows the five types of communications which were the answers to that question. The five functional pathways are the maximum number of interconnections that would be useful in a conventional single-processor mini computer. Real bus designs combine these functions in cost-effective implementations.
After choosing the structure and functions of buses, the engineer must write a specification. This is crucial to the success of bus design if it is to be interfaced by a number of different engineers. As an example of the detail that can go into a bus specification, Figures 1, 2, and 3 show how the Massbus Data Read operation has been specified in a DEC internal engineering document.
After writing a specification, the engineer builds a prototype and tests it. If other engineers concurrently build interfaces to the bus, discrepancies, errors, and misunderstandings will be uncovered sooner. Finally, it is important that the specification be maintained, updating it to conform to the latest known design constraints. A very useful appendix to a bus