Massachusetts Institute of Technology
Department of Electrical engineering and Computer Science
6.111 - Introductory Digital Systems Laboratory
Laboratory 2 - Finite State Machines
Handout Date: February 17, 1999
This laboratory exercise concerns the design and implementation of a coin operated vending machine controller. The heart of your implementation will be a synchronous finite state machine (FSM).
This lab is designed to give you a methodology for designing and building a digital system and creating procedures to test it for completeness.
This laboratory is an exercise that reflects current issues digital designers face in industry. Design and implementation have always been part of this industry, but as microchips have become more complicated and the overhead for fixing mistakes become more expensive, verification and testing has become an integral part of digital design. This lab will introduce some testing techniques and procedures designers use today.
Your vending machine controller FSM is also given the task of loading static RAM locations with the cost of the vended products. The FSM will also display these values by reading the RAM locations.
The vending machine to be controlled accepts only coins (nickels, dimes, and quarters) and vends four products. There are two input switches which serve as the function and product selectors. There are also two reset switches, global and local.
Along with the three coin denominations, there will be another input, the execute or "GO" button. Essentially, this button will be used as the action button. In any operating mode, this is the button that will initiate any action in the FSM controller.
Using the input switches, the operator can switch the controller between four modes: normal operation, programming, display, and self test. Upon start-up, the operator of the vending machine can switch between these modes by selecting the appropriate function and pressing the "GO" button.
Figure 1: Vending Machine Controller Block Diagram
In normal mode, the vending machine operates just like any other vending machine. The controller will keep a running total when coins are deposited. After the money has been deposited, the user will select the product to be vended and push the "GO" button. If there is enough money in the machine, it will vend the specified product and return any change. The controller will ignore any vend requests if not enough money had been deposited.
In programming mode, the prices for the products are stored. Using the same switches and button used to vend products, the controller has the ability to program different prices for the various products.
In display mode, the operator can display prices that were programmed into the vending machine controller by selecting the product and pressing the "GO" button. This will allow the operator of the vending machine to manually check the prices that were programmed.
The self test for this vending machine will test the functionality of the SRAM. Switching to the self test function and pressing the "GO" button will start this routine. An indicator light will be used to verify that the test completes successfully or not. Remember, running this test will more than likely rewrite any previous data you may have stored in the RAM.
The local reset signal is used to switch out of a mode. The operator of the vending machine can terminate any mode by using this switch. When this switch is activated, the FSM will return to the initial start-up state. From there, the operator can select the next function to be executed. This switch should be synchronized to the system clock.
Finally, the controller can be reset by a global reset switch. This switch will return the FSM controller to the initial start-up state. If there is money in the machine, it will clear or "return" that money. Also, all prices stored in the SRAM will be cleared. Like the local reset switch, this switch should be synchronized to the system clock.
Figure 2: Controller Block Diagram
A simple block diagram of the vending machine controller is shown in Figure 2.
The input and output signals for the FSM are listed and described in Table 1 and 2. You may use any polarity you like, e.g., N_WE or WE as you choose. Table 3 describes the four functions specified by the two function switches.
The FSM should be implemented using VHDL and programmed into a CPLD chip. Other than SRAM, it is up to you to decide which elements you want to design and program into the CPLD and which elements you want to implement using IC chips. You are welcome to use the clock/divider you built in lab 1.
The GO and coin inputs should also be synchronized to the system clock. It is up to you to design the exact timing of each of these signals. Remember that you only want to assert any one of these signals only once per clock cycle. Also, you should consider what would happen if multiple buttons were pushed at once.
While it is possible to effect this synchronization by being clever and absorbing the synchronizing function within your FSM, it is strongly suggested that you explicitly synchronize the sensor signals (or stretched sensor signals) with D flip-flops. These D flip-flops can be part of a CPLD if you choose.
The prices for the four vended products are stored in RAM. Remember to wire the unused RAM address lines to GND. The RAM is implemented using the 6264 SRAM. Timing specification and data sheets are included at the end of this handout.
The DIVIDER is a series of counters driven by your crystal oscillator and produces the FSM clock /CLK. You can either use the timer which was built in lab 1 or code it in VHDL.
A partially completed VHDL source file is located in the 6.111 locker, /mit/6.111/vhdl/lab2/lab2.vhd. Copy it to your locker by executing:
cp /mit/6.111/vhdl/lab2/lab2.vhd lab2.vhd
The VHDL source file provided is not complete enough to create a CPLD file yet. For example, it does not include the complete FSM specification.
For the sake of simplicity, use the switches and lights available to simulate the machine. The four push-buttons should be used for the three coin inputs and the GO button. Use the switches to implement the two reset and input switches. You should use the hex led's to display the amount of change returned, and one led per product to indicate if it has been vended.
Use the following steps to facilitate your design, implementation, test, and report of the lab.
You should write up a report for this lab which meets the requirements specified in the "Report Guide" handout. Your report should include the following: data paths, an FSM, VHDL source file and the corresponding state diagram, at least one logic diagram, and all timing diagrams. You should also discuss your design, method of implementing it, and how you tested for functionality and bugs. The report should flow, be well organized, and most importantly, be complete. Verbosity is not a requirement.
The first step in any design process is to identify how you want to represent data. Before you can start to think about hardware implementation of this controller, you must decide how monetary values will be represented. Once you have decided on a representation, then it becomes easier to describe the state transitions and hardware implementation.
Because of the added flexibility of implementing systems in VHDL, it may become confusing to determine where you want to draw the line between hardware and software. Potentially, you may want to implement only the FSM in software. Maybe you want to program the entire system. What's important is to settle on one design at the start. Then, during the course of your implementation, you can change your design as you change your decision to implement things one way or the other.
It is important to realize how important PROPER verification and testing is in the design process. It can make the difference between success and failure. The underlying trait that is most useful is patience. It is very easy to become so eager to wire up the entire system and hope that it works the first time you turn it on. Unfortunately, 99 percent of the time, it doesn't. By then, it become very hard to isolate bugs in such a complex system.
Therefore, you should have the patience to test each part of the system individually. Not only verify that it works, but understand the timing involved in making it work. If you do this, you will be able to eliminate the parts individually from consideration when you encounter bugs while integrating the system. You can concentrate on the interactions of the parts rather than the parts themselves.
The self test function is one example of a testing procedure that is used throughout the electronics industry. Because microchips are so large, designers don't have the luxury of having an in-depth knowledge of all the components of the project. They must rely on these self tests to identify problems within components they are not familiar with. Therefore, it is standard practice for these self tests to be incorporated as part of the design.
Remember that the test routine for this lab needs to test both the address and data lines of the SRAM. One test would be to cycle through all the addresses with the same data. Another is to cycle through the addresses while cycling through different data. Two common data cycles are to count through all the bits or to alternate in a pattern: "1111", "1010", "0101", "0000". Be creative
Figure 3: Example Timing Diagram for SRAM I/O
and think of other patterns you could use. You can either visually inspect that the test worked by displaying the data to the led's, or have the FSM internally compare the results and indicate if the test passed or failed.
Although you are required to implement only one self-test routine, it is recommended that you try to implement more. Maybe even have a switch you can use to switch between different tests, or one that loops the current test. Be creative. You can never perform enough tests.
Because you will be using a separate SRAM chip, data sheets for the 6264 SRAM are attached. PLEASE read the data sheet carefully as this chip is easily damaged by incorrect use (wiring). ASK QUESTIONS IF YOU ARE NOT SURE!
The 6264 has a tristate Input/Output (I/O) bus. Reread the handout "Gates, Symbols, and Busses" which pertains to bussing. The I/O bus of the 6264 MUST be driven by a tristate buffer; you can use the 74LS244 included in your kit or you can use outputs of the CPLD.
Tristate bus contention occurs when two (or more) drivers are active at the same time. The 6264 tristate output is enabled when the /OE input is asserted low, the /CS is asserted low, and the /WE line is high. While it is true that many logic designers allow tristate bus contention to occur for short times (due to chip delays), it is not a good idea. For this laboratory exercise you are to ensure that NO tristate bus contention can occur.
The actual write pulse is the AND of both the /CS and the /WE asserted low. It is essential that the address lines to the SRAM not change when the write pulse is active. Otherwise you may write to multiple locations!
While the 6264 is advertised as a static RAM, a memory cycle is actually initiated whenever ANY address line changes. Thus, the address lines may NOT be tristated whenever the /CS is asserted, as the internal timing circuitry is actuated by noise on the HI-Z address lines.
One way to ensure both that tristate bus contention does not occur and that the address lines do not change when the write pulse is active is to connect the system clock, /CLK, to the chip select pin; see Figure 5. The address lines do not change until after the rising edge of /CLK. The /WE line can then be provided by your FSM. As long as the /WE line is low prior to (or concurrent with) the chip select being asserted, then the SRAM will not drive the I/O pins. The control line to the tristate gate connected to the switches can also be an output of your FSM, but it should also be gated with the system clock.
During T1 data from the SRAM will appear at the I/O pins, and during T2 the data from the switches will appear at the I/O pins. (/ES is the tristate enable for the switches.)
You should not use monostables (74LS123) to generate the /CS or /WE inputs to the SRAM.