Reminders and Announcements
 Lab 2 is due today at 5pm
 Bring your work to the lab and let the TA check you out
 Announcement of Lab 3
 VGA interface on Basys2 board
 Due Monday 3/7
 Class is canceled on Thursday 2/25
ECE 351 Digital Systems Design
1
Midterm Exam
 Midterm exam March 8
 Tentative time: 5pm – 7pm
 If you have time conflict, let me know before this Sunday
(2/28)
 Late request of time change will NOT be accepted
 Cover everything from the beginning of class until
“Behavioral Design”
 Close book, close notes
 No makeup exam will be provided
 Midterm review class on March 3
ECE 351 Digital Systems Design
2
Recap from last class
 State machines
 Mealy machine
• Outputs depend on states and inputs
 Moore machine
• Outputs are functions solely of the current state
 State machine design steps
 Hello-world example: sequence detector
 State machine in VHDL
 State memory
 Next state logic
 Output logic
ECE 351 Digital Systems Design
3
ECE 351
Digital Systems Design
Behavioral VHDL Design - 4
Wei Gao
Spring 2016
4
State Machines in VHDL
 1. State memory
 Use a process to update the states
 State memory using “user-enumerated” or “pre-defined”
data types
 Synchronous and asynchronous reset
 2. Next state logic “F”
 3. Output logic “G”
ECE 351 Digital Systems Design
5
1. State memory
 We use a process that updates the “Current_State”
with the “Next_State”
 We describe D-FlipFlop’s using (CLK’event and
CLK=‘1’)
 This will make the assignment on the rising edge of
CLK
STATE_MEMORY : process (CLK)
begin
if (CLK’event and CLK='1') then
Current_State <= Next_State;
end if;
end process;
ECE 351 Digital Systems Design
6
1. State Memory
 State memory using “User-Enumerated Data Types“
 We always want to use descriptive names for our states
 We can use a user-enumerated type for this
type State_Type is (S0, S1, S2, S3);
signal Current_State
signal Next_State
: State_Type;
: State_Type;
ECE 351 Digital Systems Design
7
1. State Memory
 State memory using “Pre-Defined Data Types"
 We haven’t encoded the variables though, we can either
leave it to the synthesizer or manually do it
subtype State_Type is BIT_VECTOR (1 downto 0);
constant S0 : State_Type := “00”;
constant S1 : State_Type := “01”;
constant S2 : State_Type := “10”;
constant S3 : State_Type := “11”;
signal Current_State
signal Next_State :
: State_Type;
State_Type;
ECE 351 Digital Systems Design
8
1. State Memory
 State Memory with “Synchronous RESET”
STATE_MEMORY : process (CLK)
begin
if (CLK’event and CLK='1') then
if (Reset = ‘1’) then
Current_State <= S0;
-- name of “reset” state to go to
else
Current_State <= Next_State;
end if;
end if;
end process;
 This design will only observe RESET on the positive edge of
clock (i.e., synchronous)
ECE 351 Digital Systems Design
9
1. State Memory
 State Memory with “Asynchronous RESET”
STATE_MEMORY : process (CLK, Reset)
begin
if (Reset = ‘1’) then
Current_State <= S0;
-- name of “reset” state to go to
elsif (CLK’event and CLK='1') then
Current_State <= Next_State;
end if;
end process;
 This design is sensitive to both RESET and the positive edge
of clock (i.e., asynchronous)
ECE 351 Digital Systems Design
10
2. Next State Logic “F”
 We use another process to construct “F”
NEXT_STATE_LOGIC : process (In, Current_State)
begin
case (Current_State) is
when S0 => if (In=‘0’) then Next_State <= S0;
elsif (In=‘1’) then Next_State <= S1; end if;
when S1 => if (In=‘0’) then Next_State <= S2;
elsif (In=‘1’) then Next_State <= S0; end if;
when S2 => if (In=‘0’) then Next_State <= S0;
elsif (In=‘1’) then Next_State <= S3; end if;
when S3 => if (In=‘0’) then Next_State <= S0;
elsif (In=‘1’) then Next_State <= S0; end if;
end case;
end process;
ECE 351 Digital Systems Design
11
3. Output Logic “G”
 We use another process to construct “G”
 The expressions in the sensitivity list dictate
Mealy/Moore type outputs
ECE 351 Digital Systems Design
12
Mealy-type Outputs
OUTPUT_LOGIC : process (In, Current_State)
begin
Need to execute process
case (Current_State) is whenever input changes
when S0 => if
elsif
when S1 => if
elsif
when S2 => if
elsif
when S3 => if
elsif
(In=‘0’) then
(In=‘1’) then
(In=‘0’) then
(In=‘1’) then
(In=‘0’) then
(In=‘1’) then
(In=‘0’) then
(In=‘1’) then
Found <= 0;
Found <= 0; end if;
Found <= 0;
Found <= 0; end if;
Found <= 0;
Found <= 0; end if;
Found <= 0;
Found <= 1; end if;
end case;
end process;
ECE 351 Digital Systems Design
13
Moore-type outputs
OUTPUT_LOGIC : process (Current_State)
begin
case (Current_State) is
when S0 => Found <= 0;
when S1 => Found <= 0;
when S2 => Found <= 0;
when S3 => Found <= 1;
end case;
end process;
ECE 351 Digital Systems Design
14
General Picture of State Machine Design
Process 1
Case current_state is
when idle =>
next_state <= grab_data;
when grab_data =>
next_state <= wait_ack;
when wait_ack =>
if go_pulse = ‘1’ then
next_state <= send_data;
else
next_state <= abort;
end if;
… etc.
Process 2
If reset = ‘1’ then
current_state <= idle;
Elsif rising_edge(clk) then
current_state <= next_state
End if;
Process 3
Signal_sending <= ‘1’ when current_state = send_data else ‘0’;
Machine_ready <= ‘1’ when current_state = idle else ‘0’;
ECE 351 Digital Systems Design
15
FSM Implementation
 Both combinatorial and sequential logics could be
used
ECE 351 Digital Systems Design
16
State Encoding
type traffic_states is (red, yellow, green, fl_yellow, f_red, turn_arrow );
signal current_state, next_state : traffic_states;
 Sequential states: encodes the states as binary
numbers
 000, 001, 010, 011, 100, 101
 Is this the only way of encoding?
 Encoding options
 One-hot encoding
 Compact encoding
 Gray encoding
ECE 351 Digital Systems Design
17
State Encoding
 One-Hot encoding
 The "One-Hot" encoding option will ensure that an
individual state register is dedicated to one state. Only
one flip-flop is active, or hot, at any one time.
 One-hot encoding is very appropriate with most FPGA
targets where a large number of flip-flops are available.
 It is also a good alternative when trying to optimize speed
or to reduce power dissipation
type traffic_states is (red, yellow, green, fl_yellow, f_red, turn_arrow );
signal current_state, next_state : traffic_states;
 100000, 010000, 001000, 000100, 000010, 000001
ECE 351 Digital Systems Design
18
State Encoding
 Compact encoding
 The "Compact" encoding option will minimize the number
of state variables and flip-flops. This technique is based
on hypercube immersion.
 Compact encoding is appropriate when trying to optimize
area.
type traffic_states is (red, yellow, green, fl_yellow, f_red, turn_arrow );
signal current_state, next_state : traffic_states;
 000, 001, 010, 011, 100, 101
 The number of flip-flops used: N mod 2 + 1
ECE 351 Digital Systems Design
19
State Encoding
 Gray encoding
 The "Gray" encoding option will guarantee that only one
state variable switches between two consecutive states.
It is appropriate for controllers exhibiting long paths
without branching.
 This coding technique minimizes hazards and glitches.
 Very good results can be obtained when implementing the
state register with T or JK flip-flops.
 Remember to specify your FSM encoding methods in
XST
ECE 351 Digital Systems Design
20
State Encoding
 Why might state encoding make a difference?
 Speed: combinatorial decode of the state variable to
determine outputs and next state can be made simpler via
one-hot for instance.
 State transitions: if combinatorial decode of output is
desired to have no glitches, the encoding makes a
difference.
 Size: how many FF’s are
required to represent all
your states?
ECE 351 Digital Systems Design
21
Illegal States
 Given our states: (red,yellow,green,fyellow,fred,turn_arrow)
 000, 001, 010, 011, 100, 101
 If they are encoded as above, we have 2 illegal states
 Undefined in FSM
 What will logic do when those states are encountered?
case current_state is
when red => next_State <= turn_arrow;
when turn_arrow => next_state <= green;
when green => next_state <= yellow….
…etc.
 We don’t really know…
ECE 351 Digital Systems Design
22
Dealing with Illegal States
 Consequences of illegal state entering is unknown,
but frequently result is “wedged” machine, which
doesn’t recover
 The system will stuck once entering an illegal state
 Faulty Reset Circuitry (or none) could have you
power-up in an illegal state
 The initial system state would be random!
 Synchronization Errors on inputs
 Setup/hold violation
 Metastability
ECE 351 Digital Systems Design
23
Example FSM
 Suppose we use One-Hot encoding
type statetype is (s0,s1,s2,s3,s4,s5);
signal cs : statetype;
signal digit : std_logic_vector(3 downto 0);
ECE 351 Digital Systems Design
24
FSM Implementation : Onehot
Imagine :
Current State = “100000”
Button is pressed “near” clock edge
Line A will go from 1 – 0
Line B will go from 0 – 1
Possible Outcome at Clock Edge :
S0 -> 0
S1 stays 0
What happens now?
ECE 351 Digital Systems Design
25
Dealing with Illegal States
 These problems are not specific to Onehot encoding.
They are simply magnified with the scheme, since
there are far more illegal states!
 Have a reset state obviously
 Carefully synchronize all inputs
 If design is in an inaccessible place and can not be
“rebooted”..etc. Make a “safe” state machine
ECE 351 Digital Systems Design
26
“Safe” State Machines
 “Others” clause is typically not implemented by the
FSM extractor
 There are no others, since every one in the ennumerated
type is covered)
 The synthesizer may call this the result of “reachability”
analysis. So it may be up to you to generate reset logic
which will reset the machine and place it in a known state.
 Some synthesis tools provide attributes for encoding
machines that include: safe,onehot ; safe,grey …etc.
ECE 351 Digital Systems Design
27
“Safe” state machines
 Cite from XST reference manual again…
 Safe Implementation means that XST generates additional
logic that forces an FSM to a valid state (recovery state) if
an FSM gets into an invalid state.
• By default, XST automatically selects reset as the recovery state.
• If the FSM does not have an initialization signal, XST selects power-
up as the recovery state.
• The recovery state can be manually defined via the
RECOVERY_STATE constraint.
ECE 351 Digital Systems Design
28
“Safe” state machines
 To activate Safe FSM implementation from Project
Navigator
 Select the Safe Implementation option from the HDL
Options tab of the Synthesis Process Properties dialog box
in Project Navigator.
 To activate Safe FSM implementation from your HDL
code
 Apply the SAFE_IMPLEMENTATION constraint to the
hierarchical block or signal that represents the state
register in the FSM.
ECE 351 Digital Systems Design
29
FSM in RAM
 Current State and Inputs comprise the address input
to the RAM
 The contents of that location will be next state, and
outputs
 Block RAM is not resettable,
so nebulous consequences
to “safe” implementations
ECE 351 Digital Systems Design
30
Summary
 More issues in FSM design and implementation
 Combining processes in FSM design
 FSM implementation
 State encoding
 One-hot encoding
 Compact encoding
 Gray encoding
 Dealing with illegal states
 “Safe” state machines
 FSM in RAM
ECE 351 Digital Systems Design
31
Announcement of Lab 3
 Write VHDL code to operate the VGA interface on the
Basys2 board
 Implement a checkerboard pattern on the attached
VGA monitor
 The highlighted red block
can be moved using the onboard buttons
 How to fit the refreshing rate
of VGA monitor (60Hz)?
ECE 351 Digital Systems Design
32
Announcement of Lab 3
 Lab 3 is due March 7th 6:00pm
 7% of your final score (8% for Lab 4)
 You need to work on your own
 No collaboration is allowed on ALL labs
 You need to have the TA to check off your code
during the lab hours
ECE 351 Digital Systems Design
33