UNIVERSITY OF CALIFORNIA, DAVIS Department of Electrical and Computer Engineering. EEC180A DIGITAL SYSTEMS I Winter 2015

Transcription

1 UNIVERSITY OF CALIFORNIA, DAVIS Department of Electrical and Computer Engineering EEC180A DIGITAL SYSTEMS I Winter 2015 LAB 7. Finite State Machine Design LED Bouncing Ball Hardware Required 2 or 3 74LS74 Dual D positive edge Flip Flops 2 74LS194 4-bit bidirectional shift register, serial/parallel in, parallel out, asynchronous clear, load/hold/left/right X Other logic gates in your kit (as few as possible) 8 + num-state-bits LEDs and current-limiting resistors Preparation (Pre-lab) Design a state graph of the controller described in this document Derive the state transition tables and output logic needed for your design Design your circuit using as few gates as possible/reasonable from your kit Description Design a Finite State Machine that controls an 8-bit bidirectional shift register. The shift register will be used to simulate a "bouncing digital ball" moving across an array of 8 LEDs connected in an active-low fashion. The two modes of operation are illustrated in the following two diagrams. 1

2 The 8-bit bidirectional shift register is implemented using two 74LS194 components as shown in Fig. 1 and utilizes the three basic commands: SHL (shift left), SHR (shift right), and LOAD parallel data. Refer to the 74LS194 data sheet located on the class website for more detailed information. Figure 1. 8-bit bidirectional shift register using two 74LS194. As shown in the 2 cases illustrated, the controller can switch between two ball types: 1-LED/ball or 2-LED/ball. The ball type will be switched if the Switch_Ball input is asserted but it takes effect only when the ball touches the "left wall." It is permissible for the pattern to repeat once when the ball type changes. You may implement this capability however you like, but you may find it easiest to implement an independent single-bit state machine whose only job is to remember that the Switch_Ball input was asserted some time while the ball was moving. Your controller then checks whether Change_Ball_Type is set when the ball hits the left wall. 2

3 It may need a small modification for Moore and Mealy versions. Figure 2. Change_Ball_Type FSM Initialization and changes to the ball type are implemented by using the load function of the shift registers and loading the correct ball pattern into the leftmost location in the shift register. Loading the two ball types requires the correct control of the D0A and D1A inputs. The other six unused D inputs should be connected to 5V. The ball then immediately begins its bouncing pattern which is implemented by right shifts, left shifts, right shifts, etc. Rather than counting the number of shifts to correctly change the direction of shifting, instead use the Q0A and Q3B signals to synchronize your controller. The controller includes a Reset input that automatically loads a 1-LED/ball type into the shift register and begins ball movement after being asserted. A block diagram of the overall design is shown in Fig. 3. One example of how the system works can be described with the following example: When Reset is asserted, the controller loads the default ball type (1LED/ball) into the 8-bit Shift Register. After reset is released, the controller asserts the appropriate S1,S0 combination to the shift register to start shifting the light to the right. When the LED light (ball) reaches the right wall of the LED array, the controller reverses the direction of the shift register. This gives an effect of a bouncing ball. Then when the ball reaches the left wall, the controller switches the direction again. If the Switch_Ball signal is set, the ball type will switch to a different ball type (2LEDs/ball) but the new ball will be loaded only after the current ball reaches the left wall. The ball type will toggle between 1LED/2LEDs per ball every time it touches the left wall as long as Switch_Ball signal is set. 3

4 Figure 3. Block Diagram of Bouncing Ball Controller Part I. Implement either a Moore or Mealy version with either one-hot or binary state encodings of your bouncing ball controller design using as few components as possible. Enter your design into Quartus and simulate it using ModelSim. Demonstrate your simulation to your TA and have your verification sheet signed. Part II. Implement your design in hardware. Demonstrate your simulation to your TA and have your verification sheet signed. Hints A straightforward Moore design requires about six states. It may be possible to implement with fewer states with a Mealy implementation. Starting with a state for a left-moving ball and another state for a right-moving ball sure seems like a good start The controller has inputs Q0A, Q3B, Change_Ball_Type (and reset), and so a standard implementation of the Next State logic will have many inputs probably six after including the state bits. A one-hot state encoding may be easier to implement. If you choose a standard binary encoding with fewer flip-flops, it may be easier to use Quine-McCluskey rather than 6-input-variable K-maps. Use the Clear_ and Preset_ inputs on your D FFs for Reset Add one LED to each of your state bits for easier debugging. Plan on significant debugging time. Plan on more if you check your design quickly. Read the web page, Tips for building and debugging your circuits 4

5 Lab Report Each individual is required to submit a lab report describing their own design. Use the format specified in the "Lab Report Requirements" document available on the course web page. Include the following items in your lab report: Lab cover sheet with TA verification for circuit simulation and performance Graded pre-lab Complete documentation of your final functional design including: State diagram, State assignments, Next state equations, and circuit schematics. Tables, K-maps or other work showing how you derived your equations. Complete Quartus II schematic and simulation printouts Very briefly justify your design decisions. Explain why you chose either a Mealy or a Moore machine for your finite state machine Grading Prelab 10 points Lab Verification (checkoff) 140 points o Simulation (40 points) o Hardware design (100 points) Lab Report 50 points o Design documentation of working design, subject (40 points) to 0 5 point partially-working grading scale o Neatness, completeness, style. (10 points) Updates: 2015/03/10, 17:00 Add checkoff breakdown between simulation and hardware design. Figures 1 and 3 updated. 2015/03/06, 00:30 Page 1 state explicitly that LEDs should be connected active-low 2015/03/06, 00:10 Figure 1 shifter inputs now connected properly 5