Description
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)
F
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. The 2 digit item code is
entered one digit at a time.
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.
4. Additional signals, counters, etc. may be defined/instantiated within the module
(invisible outside the module) to help synchronize operations and reduce the
number of states.
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 UCLA ID. 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 ID.
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 your UCLA ID and
xxx is the video format extension.
adat
PARRATT
Bagot
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.
