Stopwatch Design and Simulation

Using VHDL

Digital System Modeling

Michael Mayer

Department of Electrical Engineering

University of Missouri - Rolla

EE 301

May 1, 1997

Preface

This report was written for the Digital System Modeling class, instructed by Dr. Hardy J. Pottinger at the University of Missouri - Rolla. It describes the solution to a problem from Peter J. Ashenden's The Designer's Guide to VHDL (Morgan Kaufmann Publishers. Inc. 1996). Both Ashenden's work and Digital Logic Circuit Analysis & Design by Victor P. Nelson, H. Troy Nagle, Bill D. Carroll, and J. David Irwin were referenced often during the process of coding. This report can be found online, with all code from the Appendices, at the World Wide Web site: http://wwwserver.ee.umr.edu/~mrmayer

Table of Contents

• Introduction
• Procedure Part 1 - Behavioral Model
• Procedure Part 2 - Structural Model
• Conclusion
• Appendix A - Behavioral Model Code
• Appendix B - Behavioral Simulation
• Appendix C - Structural Model Code
• Appendix D - Structural Simulation
• Appendix E - Obsolete Code

Introduction

Digital System Modeling with VHDL (VHSIC Hardware Description Language) had its beginning in the Department of Defense as a way of making specifications for various electronic systems. It was later adopted and standardized by IEEE and is now used by industry as well as defense.

Many advances have been made toward making VHDL a more complete language for designing, simulating, and synthesizing digital systems. Mentor Graphics' System Design Series is a package that simplifies the design of state-machine systems. For simulating VHDL code, Mentor Graphics provides QuickVHDL.

These products were used extensively in the design of a stopwatch system. The specifications for the system come from Ashenden, Chapter 13, Problem 23 (page 329-330). Effectively, this stopwatch times to the hundredth of a second to a magnitude of 99 minutes, 59 seconds, and 99 hundredths. It has two button inputs (start/stop and lap/reset) and a clock, and powers a six digit display that shows these times along with a few indicator lights.

The stopwatch can be operated in two different modes. In the normal mode, it can time and show the current time as it elapses on the display. From there it can be paused (by hitting start/stop) and cleared (by hitting lap/reset). The other mode is entered by hitting the lap/reset button while it is running. This freezes the display, but allows the timer to keep running. If the start/stop button is hit, it will pause the timer as well, or if the lap/reset button is hit, then the stopwatch will return to the normal mode of operation.

Starting with a behavioral description, the stopwatch was modeled and simulated using System Design Series. Then it was refined to a structural model and simulated with the QuickVHDL Simulator. Finally, it was refined to a gate level model.

Procedure Part 1 - Behavioral Model

The behavioral model of the stopwatch was created in Mentor Graphics' System Design Series using System Architect and Control Architect. First, a context diagram (Figure 2) was created for the stopwatch to illustrate the ports of the stopwatch entity. A few VHDL types were created to allow for a higher level of abstraction (Figure 1).

After establishing the context of the stopwatch, five internal components were created: a switch filter, timer, memory, display decoder, and a finite state machine. The interconnection was described in System Architect by a data flow diagram (Figure 3). Control Architect was used to create the architecture for the state machine. Five states were identified in a matrix (Figure 4), along with the state actions and the next state that would result from start_stop or set_reset being asserted. From this information, Control Architect created a state transition diagram (Figure 5) and the correlating VHDL code.

After describing the entire system, System Architect was used to run trial tests (see waveforms in Appendix B). VHDL code was exported for the entire model (Appendix A), and verified with qvcom and qvsim. Note that the configuration cfg_stopwatch_behav was used to specify which components should be instantiated in the stop_watch_data_flow architecture. A testbench was written for simulation (see Appendix B). The behavioral model appeared to work properly in all simulations.

Procedure Part 2 - Structural Model

The behavioral model was copied to a new directory before being changed to a structural model. Due to the high level data types (such as integers) used in the behavioral model, each entity was rewritten to use only std_logic and std_logic_vector signals (see Appendix C). It was noticed that several large data buses (length of 23 and 42) ran throughout the model. The first simplification used bidirectional data lines and tri-state entities (see Appendix E). Eventually, this was eliminated in favor of combining the timer memory into the timer component. In the end, only one large data bus remained within the model.

The first structural architecture written was for the timer. It was composed of eight BCD counters and one modulo 6 counter. These components were developed as a composition of J-K flipflops and gates. The state-machine was then refined to a structural model. Five states were assigned to values of a state signal of type std_logic_vector (2 downto 0). Karnaugh maps were used to design equations for the next state as a function of the current state and the start_stop and lap_reset signals (Figure 6). Finally, the switch filter was implemented using two J-K flipflops and a BCD counter.

Configurations were used to implement the various architectures developed throughout the process of refining from behavioral to structural. Two configurations, cfg1 and cfg2, were made for the stopwatch entity, to test the behavioral components and the structural components, respectively (see Appendix C).

The structural model was simulated in qvsim (Appendix D). All results appeared satisfactory.

Conclusion

Behavioral and structural models have different strengths and weaknesses. The behavioral form requires less code and is generally more readable. For example, the state_machine is the behavioral architecture for main_control, and is much more readable than the struct architecture. It uses an enumerated data type for the state and case statements for determining the next state and state actions. The behavioral model uses reduced equations to determine the next state and state actions. From a hardware design standpoint, however, the structural design more closely resembles the actual hardware and therefore should be easier to synthesize.

One major problem encountered in this design was initializing the flipflops at the beginning of a simulation. A global signal stored in a package was attempted, but proved to be undesirable. Instead, an init signal (similar to the Xilinx //globalsetreset) was instantiated in the stopwatch data flow, which had to be manually forced to a 1 and then, after a few ms, to a 0.

The other large problem was filtering the switch to make a single pulse that would trigger the state machine to change states. The final structural model of the filter outputted one pulse after the switch was hit, and then counted off 1000 clock pulses (10 ms) before checking to see if the button was pressed again.

Synthesizing this model would be difficult due to the large number of IO pins and flipflops required. The use of a multiplexor would allow one set of decoders and pinouts to power all six digits of the display. Reducing the number of flipflops in the design, however, would take some major reorganization. The timer would probably not be easily reduced, but by adding a few extra pulse outputs on the timer entity, it could power the switch filter's counter, thereby reducing the number of flipflops instantiated there.