Digital Logic on the DE1-SoC with VHDL (6/6): FSM capstone -- a vending machine

In Lesson 5 you built a finite state machine whose state was an abstract position in a cycle: a traffic light cycling green -> yellow -> red. If you did the optional detector, you also saw a state remember part of a pattern. In this capstone the state means something concrete and physical: how much money you have put in so far. You are going to build a small vending-machine controller; optional checkpoints can grow it feature by feature.

A finite state machine, recall, has three parts: a set of states, a rule for the next state given the current state and the inputs, and an output that depends on the state (and, for a Mealy machine, the inputs too). The skill this lesson adds is design: you decide what the states should be, draw the transition table, and only then write the VHDL.

For a coin machine the natural choice is to let each state *be* a credit level. If the machine accepts nickels (5 cents) and dimes (10 cents) and dispenses at 15 cents, then the credit can be 0, 5, 10, or 15 cents — four states. We will call them S0, S5, S10, S15. Inserting a coin moves you to a higher-credit state; reaching the price dispenses the item and returns you to S0.

The board signals are the same as always. Because this is a clocked (sequential) design, the entity declares the clock itself — the default blink.vhd template has no clock, so we add CLOCK_50 : in std_logic. As in Lesson 5, a switch up is logic 1, KEY is active-low (a pressed button reads 0), LEDR is active-high (lit when driven 1), and HEX0–HEX5 are active-low seven-segment displays (a segment lights when driven 0).

Here is the complete base design. Read it as a finite state machine in the now-familiar three blocks: a clock divider (so coin insertions happen at a human pace), a combinational next-state/output block, and a clocked state register with an asynchronous active-low reset.

The states. S0, S5, S10, S15 are the four named credit levels. The current credit in cents is derived explicitly from state comparisons and shown two ways: on LEDR(3 downto 0) as a binary number of cents, and on HEX0 as a single character — 0 for 0c, 5 for 5c, A for 10c, and F for 15c (these are just the hex digits whose values are 0, 5, 10, and 15).

The transitions (this is the table you would draw first when designing):

Transition summary:

- S0 (0c): nickel -> S5; dime -> S10; no dispense.
- S5 (5c): nickel -> S10; dime -> S15; no dispense.
- S10 (10c): nickel -> S15; dime -> S0 and dispense at 20c with no change in the base version.
- S15 (15c): on the next tick -> S0 and dispense, regardless of input.

Two details are worth pausing on. From S10, inserting a dime reaches 20 cents — more than the 15-cent price — so the machine dispenses and returns to S0, but in this base version it gives no change (the checkpoint below fixes that). And S15 is a "dispense and reset" state: on the very next tick it asserts dispense and returns to S0, regardless of input. So when you feed coins that land exactly on 15c, you will see the credit reach F, and then on the following tick the item dispenses.

The dispense output is latched. dispense itself is a one-tick signal. As in Lesson 5's detector, a single-tick pulse is easy to miss on a remote camera, so we latch it into dispensed_latch, drive it to LEDR(7), and only clear it on reset. That way, once the machine has dispensed, LEDR(7) stays lit until you press KEY(0).

Inserting a coin — the timing. The divider here uses DIV = 16,666,666, so slow_clk toggles about every 0.33 s, but the FSM samples coins only on rising edges. In practice, treat one coin tick as about 0.67 s. To insert one coin, toggle a switch up, wait at least one rising-edge tick, and set it back to 0. Holding a switch up across several ticks would count as several coins. Insert coins one at a time.

-- Student starter: fill the TODO lines before synthesizing.
-- Lesson 6 - Exercise 3-C: vending machine FSM capstone base design.
-- SW(0)=nickel, SW(1)=dime, KEY(0)=reset. LEDR(7)=dispense latch.
-- Insert one coin by holding SW(0) or SW(1) high for one slow_clk rising-edge tick, about 0.67 s.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity blink is
    port (
        CLOCK_50 : in  std_logic;
        KEY      : in  std_logic_vector(3 downto 0);
        SW       : in  std_logic_vector(9 downto 0);
        LEDR     : out std_logic_vector(9 downto 0);
        HEX0     : out std_logic_vector(6 downto 0)
    );
end entity blink;

architecture rtl of blink is
    type state_t is (S0, S5, S10, S15);
    signal state, next_state : state_t := S0;
    signal dispense, dispensed_latch : std_logic := '0';
    signal credit : unsigned(3 downto 0);
    constant DIV : unsigned(24 downto 0) := to_unsigned(16666666, 25);
    signal div_count : unsigned(24 downto 0) := (others => '0');
    signal slow_clk : std_logic := '0';

    function seg(d : unsigned(3 downto 0)) return std_logic_vector is
    begin
        case d is
            when "0000" => return "1000000"; -- 0
            when "0101" => return "0010010"; -- 5
            when "1010" => return "0001000"; -- A = 10
            when "1111" => return "0001110"; -- F = 15
            when others => return "1111111";
        end case;
    end function;
begin
    process(CLOCK_50)
    begin
        if rising_edge(CLOCK_50) then
            if KEY(0) = '0' then
                div_count <= (others => '0'); slow_clk <= '0';
            elsif div_count = DIV then
                div_count <= (others => '0'); slow_clk <= not slow_clk;
            else
                div_count <= div_count + 1;
            end if;
        end if;
    end process;

    process(state, SW)
    begin
        next_state <= state;
        dispense <= '0';
        case state is
            when S0  => TODO_FROM_0_CENTS;
            when S5  => TODO_FROM_5_CENTS;
            when S10 => TODO_FROM_10_CENTS;
            when S15 => TODO_DISPENSE_AND_RESET;
        end case;
    end process;

    process(slow_clk, KEY)
    begin
        if KEY(0) = '0' then
            state <= S0; dispensed_latch <= '0';
        elsif rising_edge(slow_clk) then
            state <= next_state;
            if TODO_DISPENSE_CONDITION then dispensed_latch <= '1'; end if;
        end if;
    end process;

    credit <= to_unsigned(0, 4)  when state = S0 else
              to_unsigned(5, 4)  when state = S5 else
              to_unsigned(10, 4) when state = S10 else
              to_unsigned(15, 4);

    LEDR(7) <= TODO_DISPENSE_LED;
    LEDR(3 downto 0) <= std_logic_vector(credit);
    LEDR(6) <= '0';  -- replace this line with change_latch in the 3-C1 extension
    LEDR(5 downto 4) <= (others => '0');
    LEDR(9 downto 8) <= (others => '0');
    HEX0 <= seg(credit);
end architecture rtl;

Build the controller on the real board, feed it coins along two different paths, and confirm the dispense LED latches.

Upload your evidence. After three nickels make the machine dispense, capture a camera screenshot with LEDR(7) lit, and attach it below.

Optional checkpoint if your teacher wants an extension: this fixes the unfair case you just identified. When the machine reaches 20 cents — the only over-payment path, S10 followed by a dime — it should light a second LED, LEDR(6), meaning "return 5c change," in addition to dispensing on LEDR(7). Every other dispense (exactly 15c) returns no change.

This is a small, surgical change to the FSM. You need a second latched output, change_latch, driven to LEDR(6), set whenever the machine dispenses *from the 20-cent path*. The cleanest way is to add a combinational change signal alongside dispense, assert it only in the S10 + dime branch, latch it exactly like dispensed_latch, and replace the base line LEDR(6) <= '0'; with LEDR(6) <= change_latch;.

This is the expected behavior after your change:

Expected checkpoint behavior:

- Three nickels (5+5+5): credit reaches 15c; wait one extra coin tick, then LEDR(7) dispense = yes, LEDR(6) change = no, return to S0.
- Nickel + dime (5+10): credit reaches 15c; wait one extra coin tick, then LEDR(7) dispense = yes, LEDR(6) change = no, return to S0.
- Dime + nickel (10+5): credit reaches 15c; wait one extra coin tick, then LEDR(7) dispense = yes, LEDR(6) change = no, return to S0.
- Nickel + nickel + dime (5+5+10): credit reaches 20c, LEDR(7) dispense = yes, LEDR(6) change = yes, return to S0.
- Two dimes (10+10): credit reaches 20c, LEDR(7) dispense = yes, LEDR(6) change = yes, return to S0.

Implement it, then verify on the board that LEDR(6) lights only on a 20-cent path and never on an exact-15-cent path.

Upload your evidence. On a 20-cent path (e.g. two nickels then a dime), capture a camera screenshot showing both LEDR(7) (dispense) and LEDR(6) (change) lit, and attach it below.

Capture your lab code. Save your modified blink.vhd in the lab, then use the code evidence control below to submit the checkpoint 3-C1 version with change return. If your teacher asks for a state diagram, submit that separately.

This bonus checkpoint makes the machine sell two products: a soda at 15 cents (selected with SW(2)) and a coffee at 20 cents (selected with SW(3)). The machine should dispense only when the credit reaches the price of the selected item — so with soda selected it dispenses at 15c, and with coffee selected it waits until 20c.

The important idea here is that this enlarges the state space. The machine can no longer be described by credit alone, because its behavior at, say, 15 cents now depends on *which item* was selected: dispense if soda, keep waiting if coffee. The machine must remember both the credit and the selection. Combine them — for example a state is the pair *(selected item, credit level)* — and work out which combinations can actually occur and what each one does.

Draw the expanded state diagram first, decide how many states you genuinely need, then implement it. There is no single "right" encoding, but there is a minimum number of distinct states your behavior requires — and from that, a minimum number of flip-flops.

(Bonus) Submit your design. Attach your expanded state diagram for the two-product machine and paste your modified VHDL, or attach the code as a .txt file.

The base machine shows credit as a single hex character (0, 5, A, F), which is compact but not how a real machine displays money. This bonus checkpoint shows the credit as a two-digit decimal on HEX1:HEX0 — 00, 05, 10, and 15. Only show 20 if you build a separate extension with an explicit 20c display state or display latch; the 3-C1 change-return design still returns the credit display to 00 while LEDR(6) indicates change. HEX0 shows the ones digit, HEX1 shows the tens digit.

This reuses the seven-segment decoder idea from Lesson 2: a decoder helper, named seg_dec here so it can coexist with the base seg function, that maps a single decimal digit 0..9 to the active-low segment pattern {g,f,e,d,c,b,a}. Split the credit into a tens digit and a ones digit, decode each, and drive HEX1 and HEX0. Remember to declare HEX1 : out std_logic_vector(6 downto 0) in the entity's port list — the base entity example in this lesson exposes only HEX0, so HEX1 must be declared, exactly as you did for the two-digit decoder in Lesson 2. Also replace the original HEX0 <= seg(credit); line; do not leave both HEX0 assignments active.

A decimal seg_dec helper (the same shape as Lesson 2's seg function) and a split for the base credit values (0, 5, 10, 15) is all you need:

-- Add HEX1 to the entity port list, then complete the display helper.
HEX0 : out std_logic_vector(6 downto 0);
HEX1 : out std_logic_vector(6 downto 0)
-- ...
function seg_dec(d : unsigned(3 downto 0)) return std_logic_vector is
begin
    case d is
        when "0000" => return "1000000";
        when "0001" => return TODO_PATTERN_FOR_1;
        when "0010" => return TODO_PATTERN_FOR_2;
        when others => return "1111111";
    end case;
end function;

signal cents : unsigned(4 downto 0);
signal tens  : unsigned(3 downto 0);
signal ones  : unsigned(3 downto 0);
-- ...
cents <= TODO_CREDIT_AS_CENTS;
tens  <= TODO_TENS_DIGIT;
ones  <= TODO_ONES_DIGIT;
HEX0 <= TODO_ONES_DISPLAY;
HEX1 <= TODO_TENS_DISPLAY;

(Bonus) Upload your evidence. Capture a camera screenshot of HEX1:HEX0 showing a two-digit decimal credit (for example 10 or 15), and attach it below.

You have now built, on real hardware, the core path through digital logic:

- Gates (Lesson 1): AND, OR, NOT, NAND, NOR, XOR — the atoms of every circuit, and the idea that VHDL *describes hardware* rather than running like a program.
- Combinational design and minimization (Lesson 2): truth tables, canonical SOP, Karnaugh maps, and optional POS/MUX/decoder extensions — turning a specification into a simpler circuit that meets it.
- Memory (Lesson 3): the flip-flop and the parallel-load register — the moment a circuit gains the ability to *remember*.
- Counters (Lesson 4): a sequential building block driven through a clock divider, plus the discipline of checking that a constant fits its register; optional extensions introduced BCD and shift-register behavior.
- Finite state machines (Lesson 5): a Moore traffic light acting on a remembered state, with an optional Mealy sequence-detector extension.
- An FSM capstone (this lesson): a vending-machine controller you *ran and explained* from a transition table; optional checkpoints let you add change return, item selection, or a decimal display and, if attempted, reason about state count and flip-flop count.

That is the core of an introductory digital-logic course, and you ran the required path on a real FPGA.

Where this goes next. A few directions, all optional, if you want to keep going:

- Timing — setup and hold. Real flip-flops require their input to be stable for a short window around the clock edge; respecting these *setup* and *hold* times is what lets a design run at a target clock frequency. This is the gateway to static timing analysis.
- Arithmetic and ALUs. Combining adders, comparators, and logic into an arithmetic-logic unit — the computational heart of a processor.
- Pipelining. Splitting a long combinational path into clocked stages to raise throughput, a central technique in fast hardware.
- Other HDLs and simulation. Advanced VHDL topics and *simulation* with testbenches and waveforms let you verify a design before it ever touches a board.

Optional further reading. The free FPGA Academy courses (<https://fpgacademy.org/courses.html>) cover this same DE1-SoC family in depth, and Harris & Harris, *Digital Design and Computer Architecture*, chapters 1-3, is an excellent text for the gates-to-FSMs material you have just worked through. Neither is required — they are here if you want to go further.