previous | contents | next

CONSTRAINTS

Constraints imposed on the choice of an RTM set by the application areas can be broken down into two types: problem-dictated constraints and user-dictated constraints. In addition, hardware technology and internal constraints are imposed by the realities of the production environment, in this case those at DEC.

These constraint categories are discussed in detail in the following sections. The manner in which these' constraints manifest themselves for each of the application areas is shown in the table of Figure 1.

Problem-Dictated Constraints

Within each application area, each digital system problem can be characterized by its hardware (and/or programming) requirements. Such constraints, for example, include word length, number base, and operation types. This set of constraints is a measure of the problem size.

We further measure problem size by the number of control steps (statements), the number of registers (and register operations), and the amount of memory needed for constants and variables (see Figure 1).

In terms of these problem requirements, RTM's were designed to accommodate up to 100 hardwired control steps, multiple arithmetic units, a small read-write memory of about 100 variables, and possibly a read-only memory. Other problem constraints, e.g., speed, noise, and reliability, also influenced the basic RTM design.

User-Dictated Constraints

User-dictated constraints (see Figure 1) are both objective and subjective because they reflect how a human user views the modules (e.g., with respect to cost, ruggedness, and the ability to debug) for solving a particular class of problems.

The cost constraint is very important in most problem classes. Thus, decisions for the modules like packaging, fixed word length (8-, 12-, and 16-bit), and. the method of interconnecting were all made to keep the cost low. RTM's are able to compete with relatively poorly packaged, overpriced, underproduced, or past produced computers just by having a simple structure and high volume production.

Perhaps the most important user requirement is the ability of RTM's to be used smoothly and rigorously in a design process. Such an ability directly affects design time and, therefore, cost. In the case of conventional logic design, the user selects registers, attaches data, operations and switches, and then designs a sequential circuit to evoke the system operations (see Chapter 8). Hopefully, such a design is based on a precise description such as a state diagram or a flowchart. Thus, since a logical design problem is usually solved through the use of some high level description -- in this case a register transfer flowchart -- we chose such a high level description as the basic and only design documentation for RTM's. This particularly influenced the model for the control part of RTM systems. We wanted to make it difficult to build poor systems by poor design and documentation practices.

Hardware Technology and Internal Constraints

The hardware technology and internal constraints dictate the parts from which the modules are to be constructed. Logic types other than TTL (e.g., DTL, RTL, ECL) were only briefly considered because TTL was the local standard, and

355

previous | contents | next