14.
1.1 The Process of Design
Design is a complex process, more of an art than a science. It is not simply a matter of following predetermined steps, as in a recipe. The only way to learn design is to do design. Let's introduce the concept with an example. Your boss has given you the job of designing and implementing a simple device to control a traffic light.
So how do you begin? Figure 1.1 portrays the three somewhat overlapping phases through which every design project must pass: design, implementation, and debugging. Not surprisingly, these are the same whether the object being designed is a complex software system, an engineering system like a power plant, or an electronic system like a computer. Let's look at each of these phases in more detail.
1.1.1 Design as Refinement of Representations
Complex systems can be described from three independent viewpoints, which we shall call functional, structural, and physical. The functional view describes the behavior of the system in terms of its inputs and outputs. The structural view describes how the system is broken down into ever more primitive components that form its implementation. Finally, the physical view describes the detailed placement and interconnection of the primitive building blocks that make up the implementation. You can think of design as a process of precisely(and creatively) determining these aspects. To illustrate these concepts, consider a simplified representation of a car. Its inputs are gasoline and the positions of the accelerator pedal, brake pedal, and steering wheel. Its output is the power that moves the vehicle in a given direction with a given speed. The detailed specification of how the inputs determine the direction and speed of the car constitutes its functional description.
The car system can be broken down into major interacting subsystems, such as the engine and the transmission. These are made up of their own more primitive components. For example, the engine consists of carburetion and cooling subsystems. This is the structural description.
At the most detailed level, the subsystems are actually primitive physical components: screws, metal sheets, pipes, and so forth. The car's cooling subsystem can be described in terms of a radiator, water reservoir, rubber tubing, and channels through the engine block. These form the physical representation of the car.
Design Specification Let's return to our hardware example: the traffic light controller. Your design begins with understanding what you want to design and the constraints on its implementation. This is the design specification. Your goal is to obtain a detailed and precise functional description from the design specification.
You begin by determining the system's inputs and outputs. Then you identify the way the outputs are derived from the inputs. You would probably start by asking your boss about the traffic light's functional capabilities. Here is what your boss tells you:
- The traffic light points in four directions
(call them N, S, E, W). - It always illuminates the same lights on N as S and E as W.
- It cycles through the sequence green-yellow-red.
- N-S and E-W are never green or yellow at the same time.
- The lights are green for 45 seconds, yellow for 15, red for 60.
(green, yellow, red) and each direction (East, West, North, South). That's 12 different outputs. Not all of these are unique. Since North and South are identical, as are East and West, the number of unique outputs is six.But what are the inputs? Something has to tell the system when to start processing. We call this the "start" or more commonly the reset signal. In addition, the system must be equipped with some periodic signals to indicate that 15 or 45 seconds have elapsed. These signals are often called clocks. The inputs could be represented by two independent clocks or by a single 15-second clock with additional hardware to count one or three "ticks." Since your boss has not specified this in detail, it is up to you to decide. It is not unusual for the initial design specification to be ambiguous or incomplete. The designer must make critical decisions to complete the specification. This is part of the creativity demanded of the designer: filling in the details of the designs subject to the specified constraints.
How are the inputs and outputs related? There are many ways to represent the functional behavior of a system, such as the flowchart shown in Figure 1.2. The start signal causes the green N-S lights and the red E-W lights to be illuminated. When the 45-second clock tick arrives, new outputs are turned on: the N-S green lights go off, the yellow lights go on, and the E-W lights stay red. After another 15-second clock tick, N-S yellow goes off, N-S red goes on, E-W red goes off, and E-W green goes on. A similar sequence of events happens when the light configuration changes to N-S red, E-W green, and then to N-S red and E-W yellow. After this, the whole process repeats.
Design Constraints At this point, you have a pretty good feeling about the function of the traffic light. The next set of issues deals with the system's performance characteristics. You need to consider the operational speed of the hardware, the amount of space it takes up, the amount of power it consumes, and so on. These are called the design's performance metrics. Constraints on performance influence the design by forcing you to reject certain design approaches that violate the constraints.
So now you must go back to ask the boss a few questions. How fast must the hardware be? How much can it cost? How small does it have to be? What is the maximum power it can consume? Answering these ques-tions will help you identify the appropriate implementation approach.
The traffic light system changes its outputs every few seconds. Your boss tells you that a very slow, inexpensive technology can be used.
The traffic light hardware must fit in a relatively small box to be placed next to the structural support for the lights. Your boss tells you that a 6 inch by 6 inch by 1 inch space is available for the hardware. You recognize that old-fashioned, oversized vacuum tubes are out, but neither is an advanced technology needed. For the kinds of technologies we will be describing in this book, this space could hold approximately 20 -components.
How much can it cost? Erecting a set of traffic lights probably costs several thousand dollars. Despite this, your boss tells you that the hardware cannot exceed $20 in total component cost. This rules out the hottest microprocessor currently available (which costs a few hundred dollars), but the constraint should be easy to meet with simple inexpensive components.
How much power can the system consume? The boss limits you to less than 20 watts, about one third of the power consumed by a typical light bulb. At this power level, you won't have to worry about fans.
If a given component consumes less than 1 watt, the power and area constraints together restrict your design to no more than 20 components. At a dollar a component, the design should also be able to meet the cost constraint.
Design as Representation Design is a complicated business. It has been said that to design is to represent. Our initial representation of the traffic light controller was a rather imprecise set of constraints expressed in -English. We refine this into something more detailed and precise, suitable for implementation. We start by identifying the system's inputs and outputs. Then we obtain a more formal behavioral description, such as the flowchart shown in Figure 1.2. Ultimately, we refine the design to a level of detail that can be implemented directly by the primitive building blocks of our chosen implementation technology.
In this book, we will develop methods for transforming one design representation into another. Some approaches are very well understood, while others are not. For example, nobody has yet proposed a foolproof method to transform an English statement into a flowchart. However, where such procedures are reasonably well understood, programmers have codified them into computer-aided design tools. These tools are being used, for example, to manipulate a logic design into a form that is the simplest to implement with gates and wires. It is not too far-fetched to imagine software that could translate a restricted flowchart into primitive hardware. As we learn more about the representations of a design, we will introduce the tools that can derive one representation from another.
1.1.2 Implementation as Assembly
Here we examine the different approaches for implementing a design from simpler components. Primarily, these are top-down decomposition and bottom-up assembly.Top-Down Decomposition It is easier to understand the operation of the whole by looking at its pieces and their interactions. The "divide and conquer" approach breaks the system down into its component sub-sys-tems. Each is easier to understand on its own.
This is a good strategy for constructing any kind of complex system. The process of top-down decomposition starts with the description of a whole system and replaces it with a series of smaller steps-each step is a more primitive subsystem.
For example, Figure 1.3 shows one of the possible decompositions of the traffic light system. It is broken down into timer and light sequencer subsystems. The timer counts the passing of the seconds and alerts the other components when certain time intervals have passed. The light sequencer steps through the unique combinations of the traffic lights in response to these timer alerts.
The decomposition need not stop here. The light sequencer is further decomposed into a more primitive sequencer and a decoder. The decoder generates the detailed signals to turn on the appropriate light bulbs.
The decomposition of the design into its subsystems is its structural representation. The approach can continue to any finer level of detail.
Bottom-Up Assembly The alternative approach to top-down decomposition is bottom-up assembly. In any particular technology, there are primitive building blocks that can be clustered into more complex groupings of blocks. These are appropriately called assemblies.
Consider the implementation of an office building. The most primitive components are objects like walls, doors, and windows. These are composed to form assemblies called rooms. Assemblies of rooms form the floors of the building. Finally, the assembly of the individual floors forms the building itself. By determining how to construct such assemblies, you move the process from design to implementation.
Rules of Composition An important facet of design by assembly is the notion of rules of composition. They describe how items can be combined to form assemblies. When followed, they ensure that the design yields a functionally correct implementation. This has sometimes been called correctness by construction.
When it comes to hardware design, the rules of composition fall into several classes, of which the most important are electrical and timing rules. An electrical signal can become degraded when it is stretched out in time and reduced in amplitude by distributing it too widely within an electrical circuit. This makes it unrecognizable to the rest of the logic. Electrical rules determine the maximum number of component inputs to which a given output can be connected to make sure that all signals are well-behaved.
Timing rules constrain how the periodic clocking signals effect changes in the system's outputs. In this book, we develop a disciplined design approach that is well-behaved with respect to time. This is called a synchronous timing methodology. A single reference clock triggers all events in the system, such as the transition among the light configurations in the traffic light controller. Certain events come from outside the system, and are inherently independent of the internal timing of the -sys-tem. For example, a pedestrian can walk up to the traffic light and push a button to get the light to change to green faster. We will also learn safe methods for handling these kinds of signals in a clocked, synchronous system.
Physical Representation As a logic designer, you construct your design by choosing components and composing them into assemblies. The com-ponents are electrical objects, logic gates, that you compose by wiring them together. In general, there is more than one way to realize a particular hardware function. Design optimization often involves selecting among alternative components and assemblies, choosing the best for the task at hand within the speed, power, area, and cost constraints on the design. This is where the real creativity of engineering design comes into play.
1.1.3 Debugging the System
The key elements of making a hardware system work are, first, understanding what can go wrong and, second, using simulation to find problems before you even build the system.What Can Go Wrong As Murphy's law says, if things can go wrong in designing a hardware system, they will. For a system to work properly, the design must be flawless, the implementation must be correct, and all of the components must be operational.
Even a design that is perfect at the system level can be sabotaged by an imperfect implementation at the physical level. You may have chosen the wrong components or wired them incorrectly, or the components themselves could be faulty.
Simulation Before Construction Designers today take advantage of a new approach that allows them to use computer programs to simulate the behavior of hardware. When you do simulation before construction, the only problems that should remain are either a flawed translation of the design into its component-level physical implementation or bad components. Simulation is becoming increasingly important as discrete components wired together are replaced by programmable logic, where the wiring is no longer visible for easy fixing.
[Top] [Next] [Prev]
![What is Sarbanes-Oxley[q]](/icons/blank_book.jpg "What is Sarbanes-Oxley[q]"){kind=icon}