Need for Timing

Digital circuits have inputs that are in one of two states: 1 or 0. The outputs are also either producing a 1 or a 0. In the previous section, we learned that 1s and 0s are represented by prescribed voltages and that voltage changes on the inputs result in changes in the output voltage. It can be very helpful to show the relationship between changes at the input and changes at the output in order to demonstrate the operation of the system. This means the logic states must be observed over time. Timing diagrams show the relation- ship, over time, between many digital “signals.” It is very important that you understand timing diagrams and can relate them to physical events in a digital circuit. For example, assume there is a circuit represented by the block diagram in Figure 1-8 that detects the “edge” at dawn, waits 10 min- utes, and then turns off the streetlamp. Figure 1-8(b) is a timing diagram which shows the input to the circuit as well as the output. From this dia- gram, we can determine the relationship between the two signals. Notice the curvy arrows. They are used to indicate the cause-and-effect relation- ship between input and output signals.

The length of daylight time and nighttime varies with the seasons but the period remains the same. If we want to measure how much of the time a digital signal is in its “active” state, then we must think about the pur- pose of the digital signal. In our example of a sensor whose duty is to turn the streetlights ON, we would say that this sensor is on-duty during the night when (in this example) the sensor is HIGH. The duty cycle of the street light would be the percentage of time it is dark over the course of an entire day.

Opening and closing a microwave oven door is something that happens at completely irregular intervals. If we tried to measure the length of time the door stands open, each measurement would be different. There is no regu- larity to the cycle of opening and closing a door. There would be no fixed period of time between events. Therefore, it is referred to as an aperiodic signal. Let’s contrast this digital signal with a sensor that turns on and off the streetlights. To make our point in this analogy, we will disregard the effects of weather and assume cloudless days. We also assume the sensor makes one clean transition at dawn and another clean transition at dusk. The sensor tells us whether it is day or night. A timing diagram of this sensor would look like Figure 1-9(c) in June (central United States). In December the sensor timing diagram would look more like Figure 1-9(d).

Highs and Lows Over Time

Think about a common digital input to a system that you operate all the time. A microwave oven has a switch in the door that tells the system whether the door is closed or open. This switch could be wired in several ways. Let’s assume the switch is open when the door is open and closed when the door is closed. It is wired as shown in Figure 1-9(a). The timing diagram in Figure 1-9(b) depicts the condition of the door over time. We can look at the diagram at any point in time and know the physical condition of the door.

DeCoDing the ahDL MoD-5 Counter

We looked briefly at the idea of decoding a counter in Section 7-8. You should recall that a decoding circuit detects a counter’s state by the unique bit pat- tern for that state. Let’s see how to connect a decoder circuit to the MOD-5 counter design in Figure 7-39 (or Figure 7-40). We will rename the counter SUBDESIGN mod5 to be a bit more descriptive in the block diagram for the overall circuit that we will draw later. Since the counter does not produce all eight possible states for a three-bit counter, our decoder design shown in Figure 7-49 will only decode the states that are used, 000 through 100. The three input bits 1c = MSB2 declared on line 3 will be connected later to the MOD-5 counter’s outputs. The five outputs for the decoder are named state0 through state4 on line 4. A CASE statement (lines 7–14) describes the behavior of the decoder by checking the c b a input combination to deter- mine which one of the decoder outputs should be HIGH. When the c b a input is 000, only the state0 output will be HIGH or, when c b a is 001, only the state1 output will be HIGH, and so on. Any input value greater than 100, which is covered by OTHERS and actually should not occur in this applica- tion, will produce LOWs on all outputs. 1 SUBDESIGN decode5 (2 3 c, b, a : INPUT; 4 state[0..4] : OUTPUT; )5 6 BEGIN 7 CASE (c,b,a) IS -- decode binary value 8 WHEN B"000" => state[] = B"10000"; 9 WHEN B"001" => state[] = B"01000"; 10 WHEN B"010" => state[] = B"00100"; 11 WHEN B"011" => state[] = B"00010"; 12 WHEN B"100" => state[] = B"00001"; 13 WHEN OTHERS => state[] = B"00000"; 14 END CASE; 15 END; Figure 7-49 AHDL MOD-5 counter decoder module. 474 Chapter 7/Counters and registers We will instruct the Altera software to create symbols for our two design files, mod5 (using a more descriptive name for any of the earlier design file choices) and decode5. This will allow us to draw a block diagram (see Figure 7-50) for our complete circuit that consists of these two modules, input and output ports, and the wiring between them. Each symbol is labeled with its respective SUBDESIGN name mod5 or decode5. Notice that some of the wiring is drawn with heavier-weight lines. This is to represent a bus, which is a collection of signal lines. The lighter-weight lines are individual signals. The symbols created by Altera will automatically have ports drawn to indi- cate whether they represent individual signals or buses. This will be deter- mined by the signal declarations in the SUBDESIGN section. Ports with group names will be drawn as buses. Since the counter output port is a bus but the decoder input ports are individual signals, it will be necessary to split the bus into individual signal lines to wire the two modules together. Whenever a bus is split, you must label both the group signal name of the bus and the individ- ual signals that are being used. Our block diagram has a bus labeled q[2..0] and the corresponding individual signals q[2], q[1], and q[0]. The simulation results for this counter and decoder circuit are shown in Figure 7-51.

DeCoDing the VhDL MoD-5 Counter

We looked briefly at the idea of decoding a counter in Section 7-8. You should recall that a decoding circuit detects a counter’s state by the unique bit pattern for that state. Let’s see how to connect a decoder circuit to the MOD-5 counter design in Figure 7-41. We will rename the counter ENTITY mod5 to make it easier to identify the module in our overall circuit. Since the counter does not produce all eight possible states for a three-bit counter, our decoder design shown in Figure 7-52 will only decode the states that are used, 000 through 100. The three input bits 1c = MSB2 declared on line 3 will be connected later to the MOD-5 counter’s outputs. The five outputs for the decoder are named state, a bit vector, on line 4. An internal bit vector signal named input is declared on line 9. Then line 11 combines the three input port bits (c b a) together as a bit vector called input, which then can be evaluated by the CASE statement on lines 14–21. If any of the input bits changes logic level, the PROCESS will be invoked to determine the resul- tant output. The CASE statement describes the behavior of the decoder by checking the input combination (representing c b a) to determine which one of the decoder outputs should be HIGH. When the input is 000, only the SeCtion 7-13/wiring hdl Modules together 475 state(0) output will be HIGH; when input is 001, only the state(1) output will be HIGH; and so on. Any input value greater than 100, which is covered by OTHERS and actually should not occur in this application, will produce LOWs on all outputs. Since we are using the Altera Quartus Development software, we can connect the two modules graphically. To do this, you will need to instruct the software to create symbols for our two design files, mod5 (using a more descriptive name for any of the earlier design file choices) and decode5. This will allow us to draw a block diagram (see Figure 7-50) for our com- plete circuit that consists of these two modules, input and output ports, and the wiring between them. Notice that some of the wiring is drawn with heavier-weight lines. This is to represent a bus, which is a collection of sig- nal lines. The lighter-weight lines are individual signals. The symbols cre- ated by Altera will automatically have ports drawn to indicate whether they represent individual signals or buses. This will be determined by the data type declarations for each port of the ENTITY. BIT_VECTOR ports will be drawn as buses and BIT type ports will be drawn as individual signal lines. Since the counter output port is a bus but the decoder input ports are indi- vidual signals, it will be necessary to split the bus into individual signal lines to wire the two modules together. Whenever a bus is split, you must label both the group signal name of the bus and the individual signals that are being used. Our block diagram has a bus labeled q[2..0] and the corre- sponding individual signals q[2], q[1], and q[0]. The simulation results for this counter and decoder circuit are shown in Figure 7-51. The standard VHDL technique (and an alternative with Altera’s soft- ware) to connect design modules is to use VHDL to describe the connections between the modules in a text file. The desired modules are instantiated in a higher-level design file using COMPONENTs in which the module’s PORTs are declared. The wiring connections for each instance where the module is utilized are listed in a PORT MAP. A VHDL file that connects the mod5 and decode5 modules together is shown in Figure 7-53. Even though q is an out- put port for our top-level design file, it is typed as a BUFFER on line 4 due 1 ENTITY decode5 IS 2 PORT ( 3 c, b, a : IN BIT; 4 state : OUT BIT_VECTOR (0 TO 4) );5 6 END decode5; 7 8 ARCHITECTURE a OF decode5 IS 9 SIGNAL input : BIT_VECTOR (2 DOWNTO 0); 10 BEGIN 11 input <= (c & b & a); -- combine inputs into bit vector 12 PROCESS (c, b, a) 13 BEGIN 14 CASE input IS 15 WHEN "000" => state <= "10000"; 16 WHEN "001" => state <= "01000"; 17 WHEN "010" => state <= "00100"; 18 WHEN "011" => state <= "00010"; 19 WHEN "100" => state <= "00001"; 20 WHEN OTHERS => state <= "00000"; 21 END CASE; 22 END PROCESS; 23 END a; Figure 7-52 VHDL MOD-5 counter decoder module. 476 Chapter 7/Counters and registers 1 ENTITY mod5decoded1 IS 2 PORT ( 3 clk :IN BIT; 4 q :BUFFER BIT_VECTOR (2 DOWNTO 0); 5 cntr_state :OUT BIT_VECTOR (0 TO 4) 6 ); 7 END mod5decoded1; 8 9 ARCHITECTURE toplevel OF mod5decoded1 IS 10 COMPONENT mod5 11 PORT ( 12 clock :IN BIT; 13 q :OUT BIT_VECTOR (2 DOWNTO 0) 14 ); 15 END COMPONENT; 16 COMPONENT decode5 17 PORT ( 18 c, b, a :IN BIT; 19 state :OUT BIT_VECTOR (0 TO 4) 20 ); 21 END COMPONENT; 22 BEGIN 23 counter: mod5 PORT MAP (clock => clk, q => q); 24 decoder: decode5 PORT MAP 25 (c => q(2), b => q(1), a => q(0), state => cntr_state); 26 END toplevel; Figure 7-53 Higher-level VHDL file to connect mod5 and decode5 together. to the fact that it is necessary to “read” the bit vector array for an input to the decode5 COMPONENT in its PORT MAP (line 25). VHDL does not per- mit output ports to be used as inputs. The BUFFER data type declaration provides a port that can be used for both input and output. The mod5 mod- ule is declared on lines 10–15 and the decode5 module is declared on lines 16–21. The mod5 and decode5 ENTITY/ARCHITECTURE descriptions may be included within the top-level design file, or instead they may be saved in the same folder as the top-level file as was done here. The PORT MAP for each instance of the modules is listed on lines 23 and 24–25. The word to the left of the colon is a unique label for each instance and the module name is on the right, then the keywords PORT MAP, and finally, in parentheses, are the named associations between the design signals and ports. The => operator indicates which module ports (on the left side) are connected to which higher-level system signals (on the right side). This circuit produces the simulation results shown in Figure 7-51.

7-14 state MaCHines

Upon completion of this section, you will be able to: ■■ Define the Mealy and Moore models of state machines. ■■ Differentiate between counters and state machines and the methods to describe both. ■■ Describe Mealy and Moore models of state machines using HDL. The term state machine refers to a circuit that sequences through a set of predetermined states controlled by a clock and other input signals. So the counter circuits we have been studying so far in this chapter are state machines. Generally, we use the term counter for sequential circuits that have a regular numeric count sequence. They may count up or count down, they may have a full 2N modulus or they may have a 6 2N modulus, or they may recycle or stop automatically at some predetermined state. A counter, as its name implies, is used to count things. The things that are counted are actually called clock pulses, but the pulses may represent many kinds of events. The pulses may be the cycles of a signal for frequency division or they may be seconds, minutes, and hours of a day for a digital clock. They may indicate that an item has moved down the conveyer in a factory or that a car has passed a particular spot on the highway. The term state machine is more often used to describe other kinds of sequential circuits. They may have an irregular counting pattern like our stepper motor control circuit in Section 7-10. The objective for that design was to drive a stepper motor so that it would rotate in precise angular steps. The control circuit had to produce the required specific sequence of states for that movement, rather than count numerically. There are also many applications where we do not care about the specific binary value for each state because we will use appropriate decoding logic to identify specific states of interest and to generate desired output signals. The gen- eral distinction between the two terms is that a counter is commonly used to count events, while a state machine is commonly used to control events. The correct descriptive term depends on how we wish to use the sequen- tial circuit. The block diagram shown in Figure 7-59 may represent a state machine or a counter. In Section 7-10 we found out that the classic sequential circuit design process was to figure out how many flip-flops would be needed and then determine the necessary combinational circuit to produce the desired sequence. The output produced by a counter or a state machine may come directly from the flip-flop outputs or there may be some gating circuitry needed, as indicated in the block diagram. The two variations are described as either a Mealy model for a sequential circuit or a Moore model. In the Mealy model the output signals are also controlled by additional input sig- nals, while the Moore model does not have any external controls for the gen- erated output signals. The Moore output is a function only of the current flip-flop state. An example of a Moore-type design would be the decoded MOD-5 circuit in Section 7-13. On the other hand, the BCD counter design in the same section would be a Mealy-type design because of the external input (enable) that controls the terminal state decoding output (tc). One significant consequence of this subtle design variation is that Moore-type circuit out- puts will be completely synchronous to the circuit’s clock, while outputs pro- duced by a Mealy-type circuit can change asynchronously. The enable input is not synchronized to the system clock in our MOD-10 design.

SiMpLe ahDL State MaChine

The AHDL code in Figure 7-60 shows the syntax for declaring a counter with named states on lines 6 and 7. The name of this counter is cycle. The keyword MACHiNe is used in AHDL to define cycle as a state machine. The number of bits needed for this counter to produce the named states will be determined by the compiler. Notice that in line 7 the states are named, but the binary value for each state is also left for the compiler to determine. The designer does not need to worry about this level of detail. The CASE structure on lines 11–25 and the decoding logic that drives the outputs (lines 27–33) refer to the states by name. This makes the description easy to read and allows the compiler more freedom to minimize the circuitry. If the design requires the state machine also to be connected to an output port, then line 6 can be changed to:

Aurther

Ronald J. Tocci

Gregory l. Moss

neal S. widmer

Downlaod Book