Description

Finite State Machine Design: Vending Machine
In this lab, you will design and implement a finite state machine (FSM) for a vending machine.
Introduction
For this lab, you will: Design a finite state machine that matches the specified behavior
This lab will be based on simulation only; no FPGA use will be involved. you are going to implement your design in Verilog HDL. At the end of the lab, you are expected to present a design project with source code and testbench.
Overview and Example
Finite State Machines (FSMs) are a powerful tool that can be used to model many real-world systems and are particularly useful for the behavioral modeling of sequential circuits. An FSM has a finite number of ‘states’ and can be in any one of these states at a given time. The machine transitions from one state to another based on the inputs it receives and the state that it is currently in. The machine must begin operation in an initial state. Given below is a simple example of an FSM for a turnstile, and the Verilog code to implement it. This FSM is a Moore machine because the output (is_locked) depends only on the present state. A Mealy machine is an FSM whose outputs depend on both the present state and input.

Fig 1: FSM for a Turnstile (allows a user to push through when a coin is inserted)
module turnstile(rst,clk,coin,push,is_locked); input rst,clk,coin,push; output reg is_locked; parameter LOCKED = 1’b0; parameter UNLOCKED = 1’b1;
reg current_state; reg next_state;
// always block to update state : sequential – triggered by clock always@(posedge clk) begin if(rst) current_state <= LOCKED;
else current_state <= next_state; end
// always block to decide next_state : combinational- triggered by state/input
always @(*) case(current_state)
LOCKED : begin if(coin) next_state = UNLOCKED;
else next_state = LOCKED;
end UNLOCKED: begin if(coin) next_state = UNLOCKED;
else if(push) next_state = LOCKED;
else next_state = UNLOCKED; //stay unlocked until push
end
endcase
//always block to decide outputs : triggered by state/inputs; can be comb/seq. always @(*) case(current_state)
LOCKED : begin is_locked = 1’b1; end UNLOCKED: begin is_locked = 1’b0;
end
endcase endmodule
System Specifications:
This section describes the behavior of the FSM that you are expected to design.

Fig 2: Vending Machine
Design a vending machine with the following characteristics:
1. The vending machine has 10 different snacks for sale. Each snack has a two-digit code (10-14, 20-24).
2. Each snack is stored in a separate slot like the vending machines on campus (see Fig. 2). There can be up to 10 units of the snack stored in 1 slot. A counter for every slot keeps track of the number of units of the snack remaining in that slot.
3. A buyer can purchase only 1 item at a time.
4. The machine only accepts payment by card.
Actions/States:
1. Reset: When reset = 1, all item counters and outputs are set to 0. The machine goes to the idle state when the reset becomes 0.
2. Idle: This is a state where the machine waits for a new transaction to begin. In this state, all outputs are set to 0, and the machine waits in this state until CARD_IN goes high to signal the beginning of a new transaction. The idle state is the initial state of this FSM.
3. Re-load: All snack counters are set to 10, i.e. the machine is fully re-loaded. A re-load can only be done when the machine is idle. A new transaction cannot begin when the machine is re-loading.
4. Transact: When card is inserted (CARD_IN = 1) – wait for item selection (see action
: get code)
a. If selection is valid (i.e. the code is a number between 10-14 or 20-24 and there are a non-zero number of items corresponding to that code left in the machine), display the $ amount of the selection on COST<2:0> as per Table 1, and wait for the VALID_TRAN signal (represents a valid/invalid transaction signal from the bank). The cost of the item will remain on COST<2:0> until the transaction is complete (machine returns to idle).
i. If VALID_TRAN = 1 : VEND selected item (see action: vend)
ii. If the VALID_TRAN signal does not go high within 5 clock cycles, the transaction failed. Set the ‘FAILED_TRAN’ bit to high for 1 cycle, and go to the idle state.
b. If the selection is invalid, set the ‘INVALID_SEL’ bit to high for 1 cycle and go to the idle state.
5. Vend:
a. decrement counter of the corresponding item by one (i.e., the item is dispensed)
b. set VEND to 1 for 1 cycle
c. Return to idle state.
6. Get Code:
1. The same bus (ITEM_CODE<2:0>) is used to enter the 2 digit item code sequentially (one digit at a time), the way you would press numbers on a keypad. The press is modeled by the input ‘key_press’. Thus, the item_code is read-only when key_press = 1.
2. Wait up to 5 clock cycles for each digit (Fig 3. shows the maximum wait time). If no digit is entered, or if a digit is entered and there is no second digit for 5 clock cycles, go to the idle state.
Example: For item ‘14’ entered over 3 clock cycles:
clk cycle 1: ITEM_CODE = 001 KEY_PRESS = 1 // read 1.
clk cycle 2: ITEM_CODE = 001 KEY_PRESS = 0 // no input. upto 4 cycles left clk cycle 3: ITEM_CODE= 100 KEY_PRESS = 1 // read 4.

Fig 3. Implementation of 5 cycle wait
ITEM CODE COST ($)
10,11,12,13,14 2
20,21,22,23,24 5
Table 1: ITEM CODE vs COST
Inputs and Outputs:
The I/O of the module vending_machine should be exactly as shown in Figure 4.

Figure 4: VENDING MACHINE I/O
INPUTS:
INPUT SIZE/ BEHAVIOR
CLK 1 bit. System clock ( T= 10 ns)
RESET 1 bit synchronous reset. When high, set all item counters, outputs to 0 and go to the idle state.
RELOAD 1 bit. Reload the machine (set all item counters to 10)
CARD_IN 1 bit. Stays high as long as the card remains inserted.
ITEM_CODE <2:0> 3-bit signal to input item code. entered one digit at a time. The 2 digit item code is
KEY_PRESS 1 bit. ITEM_CODE is valid for reading when this signal is high.
VALID_TRAN 1 bit. If HIGH, the transaction using the card is valid. It can go high any time after item selection is determined to be valid)
(card does not need to be inserted when this occurs)
OUTPUTS:
OUTPUT SIZE/BEHAVIOR
VEND 1 bit. Set to HIGH once the transaction is deemed to be valid. Set to LOW one cycle later.
INVALID_SEL 1 bit. Set to HIGH for 1 cycle if:
1. If 1 digit of ITEM_CODE is entered and there is no 2nd digit after 5 clock cycles
2. If no digit is entered for 5 clock cycles 3. The 2 digit ITEM_CODE is invalid (Ex. 23)
4. The counter for one of the items is 0.
COST<2:0> 3 bits. Set to 000 by default. Set to the cost of an item once item code is entered, and remains at this value until a
new transaction begins. (Ex. $5 = 101)
FAILED_TRAN 1 bit. Set to 1 for 1 cycle if VALID_TRAN signal does not go
high within 5 clock cycles of determining the ITEM_CODE
Things to think about/Hints :
1. Draw your FSM diagram before you write any code. What are your states? What inputs cause a state transition? Once your FSM is designed, use the example provided as a template to convert it to Verilog.
2. You can use the ‘actions’ as a starting point for your state definitions, but feel free to combine actions into one state or split up actions into multiple states if required. Aim for a clean, logical design with as few states as possible. (As a reference – one possible solution has around 10 states. Your design can have more/fewer.)
3. What happens if any input signal occurs when it is not supposed to? Does your FSM handle this correctly? Your vending machine cannot crash or take an action that violates the design specifications.
Deliverables
When you finish, the following should be submitted for this lab:
1. Verilog source code for the “vending_machine” module. The file should be named exactly as “vending_machine.v” and the module and port names should exactly match names defined in Figure 3. It is very important as your code is automatically run. Also, note that this code should be completely synthesizable. ***There is no restriction on the naming of the submodules (if any) but make sure to place all the submodules in the vending_machine.v file.
2. Verilog testbench you used to evaluate your design. Note that your testbench is graded based on the correctness of the waveforms generated in your report. Please name the file “testbench_UID.v” where UID is your UCLAadatID. It is too time-consuming to exhaustively test all possible input/state combinations for this design. Make sure you test at least one successful transaction and 4 special cases to get 80% of the marks associated with simulation. A testbench that identifies and tests all/most
‘interesting’ cases will get full marks for simulation.
3. Lab Report: Please refer to the syllabus for the basic components of your lab report. Note:
1. Include the FSM diagram and explain the states and transitions of your FSM. Bullet-points/tables are preferred over lengthy paragraphs. Draw a diagram similar to Figure 1 to represent the working of your FSM. This diagram can be drawn by hand or using the software. You can label the arrows (1,2,3, a,b,c, etc.) and put the text associated with each arrow in a table if you feel your diagram is getting very crowded. Include this diagram in your report.
2. Explain how you test your design and include simulation waveforms
3. Schematics can be generated from ISE but please explain how your Verilog code results in the RTL generated. Include the ‘Design Summary’ section of the synthesis report and the summary of your implementation (map) report and write 1-2 lines on the conclusions you draw from these reports.
4. Please name your report “report_UID.pdf” where UID is your UCLA IDPARRATT.
4. Video Demo: Please refer to ‘Syllabus’ for details. The ideal video length is 5-10 minutes. Please name your video “video_UID.xxx” where UID is yourBagotUCLA ID and xxx is the video format extension.
FAQ (will be updated if necessary):
1) When happens after a successful transaction? How is this different from reset?
After ‘vend’, the machine goes to the idle state. It does not reset. On transition to the idle state, all outputs are set to 0, but the item counters are not affected. On reset, both item counters and outputs are set to 0.
5) What happens when CARD_IN goes low in the middle of the transaction?
CARD_IN can go low any time after the transaction begins (assume the card’s info. is stored by the machine as soon as it is inserted).
6) What if CARD_IN stays as 1 throughout the transaction and through it finishing? Then should another transaction start immediately once the current transaction finishes? Yes.
6) Can you begin a transaction while reloading?
The ‘RELOAD’ input is valid only when the machine is idle. Additionally, card_in is ignored if it goes high after reload becomes high. A new transaction can begin only once reload goes low.
7) Changing inputs at the same clock edge as the state update is causing unpredictable behavior.
You can change the inputs (in the testbench) at the negative edge of the clock (or sometime before the clock edge) so that they are stable at the clock edge.