With the exception of the link itself, two components are in general physically distinct and thus their ports must be connected by a link. A perfect link would make this connection into an identity. In fact, there is always propagation delay so that the bit values at the port of the one component do not instantly assume the values of the corresponding bits of the other port to which it is connected. In modern digital technology these delays are often significant in the- performance of the system. In high performance designs they always effect the design in detail. In much other design they can simply be lumped in with the speed of the components themselves. Though they degrade the overall performance somewhat, they do not effect the design. When this is true, as it will be throughout this book, the link itself is no longer a significant separate component in the system. It can be replaced by a simple connecting line that identifies two ports. It does, of course, still have a capacity of a certain number of bits. It also has directionality, permitting bits to be transmitted either just in one direction (called a simplex link), in both directions at the same time (called a duplex link), or in either direction, but only in one direction at a time (called a half-duplex link).
With the role of links cleared up, we can now show concretely how to connect digital systems together. Figure 6 shows the illustrative system for simple addition used earlier. We have made a box for each component, labeling it with the appropriate abbreviation. The boxes are a matter of style only, and we will often dispense with them. We-have shown the direction of data flow in the links but omitted the data flow capacities. Links between controls and the components they control are invariably two way (at least half-duplex) since the controls both evoke their components and sense when they have completed operation.
Figure 7 shows a simple system for storing away data and then retrieving it. The component called X stands for the component outside the digital system in question, say a human at a keyboard or whatever. We often do not want to bother stating exactly what the nature of the external component is. Below the memory system we put in a blow-up of the M component itself, showing it as another system described in the same functional terms.
Both figures are still quite general, with the components labeled only by the gross functional category to which they belong. Before we can show the full detail, we need to know how to specify system behavior.
SPECIFYING SYSTEM BEHAVIOR
To design one must specify what one wants of the to-be-constructed system. Recall that all the formulations of the design task had both a part that gave the technology and a part that gave the desired specifications. These specifications must be given in independent terms. Suppose, for the system of Figure 6, we had just said "We want a system that takes data from the keyboard, transduces it, ships it to a memory, transduces a second number, ships it and the number in the memory to the data operation,...(and so on through the details of the figure)." How would you ever know whether it did the task that was wanted? It simply is what is and there is no independent statement against which to evaluate it. Worse yet, how would it ever have been designed in the first place? How would one have known what to write down in the diagram before it was written down?
In fact, of course, we did have an independent specification. We wanted to add two numbers given by a human and present the sum to him. But isn't this the same thing? Not at all. We could show it was not the same by exhibiting