5. Examples from Class - FSM Car Security Alarm
5.1 State Transition Diagram
Here we continue from the Car Security Alarm presented in Example 2. Review that
if you like. Remember the problem was to devise a circuit for a car security alarm
which would sound a horn if the system was energized (K=1) while either the door
was open (D=1) or an ultrasonic intruder detector signalled movement inside the car
(U=1).
But there was one problem with the circuit of logic gates we developed; when the
door was opened and the alarm sounded, the alarm would stop if the door were
closed. Not exactly a secure security alarm.
What we need to do is to “latch” the fact that the door has been opened so that if it is
closed the alarm still sounds. This is a job of a FSM description, and here’s the State
Transition Diagram:
StateA
H=0
(KDU)=
000
001
010
011
100
101
110
111
000
001
010
011
StateB
H=1
100
101
110
111
First the states. StateA is the unattacked car. The horn is off. StateB is trouble, there is
an intruder and the horn is on and remains on in this state. Now the transistion arrows.
Each is labelled with a “Key Door Ultrasonic” triplet. Let’s have a look at the four
sets of transitions shown.
1. From StateA to StateA. Any possible combination of door open or intruder
detected leads back to this state when the system is not energised (ie K=0).
This means you have not armed the alarm. But if you have armed the alarm,
then you remain in this state if there is no intrusion (D=0 AND U=0). The care
is not under attack.
2. From StateA to stateB there is a transition if the car is being attacked. In all
three cases the system is armed (K=1) and the cases enumerate either door is
opened, intruder is detected or both. We transit to stateB and the horn sounds.
3. From StateB to StateB. This is important. We remain in StateB whatever
happens to the door or intruder detector, providing the system remains armed
(K=1).
4. Only can we transit from StateB to StateA (where the horn will become slient)
if the system is disarmed, (K=0).
5.2 Reading the VHDL Code.
Here’s the VHLD which will implement this system.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
--------------------------------------------------------------------- CBP Feb 2006
--- Car Security System discussed in class
-------------------------------------------------------------------library ieee;
use ieee.std_logic_1164.all;
entity state_machine is
port ( clock : in std_logic;
KDU : in std_logic_vector (2 downto 0);
Horn : out std_logic);
end state_machine;
architecture Behavioural of state_machine is
type statetype is (stateA, stateB);
signal state: statetype := stateA;
begin
next_state_logic: process (clock,KDU,state)
begin
if(rising_edge(clock)) then
case state is
when stateA =>
if(KDU = "000" ) then state <= stateA;
elsif (KDU = "001") then state <= stateA;
elsif (KDU = "010") then state <= stateA;
elsif (KDU = "011") then state <= stateA;
elsif (KDU = "100") then state <= stateA;
else state <= stateB;
end if;
when stateB =>
if (KDU = "100") then state <= stateB;
elsif (KDU = "101") then state <= stateB;
elsif (KDU = "110") then state <= stateB;
elsif (KDU = "111") then state <= stateB;
else state <= stateA;
end if;
end case;
end if;
end process;
44
45
output_logic: process(state)
46
begin
47
case state is
48
when stateA =>
49
Horn <= '0';
50
when stateB =>
51
Horn <= '1';
52
end case;
53
end process;
54
55 end Behavioural;
Off we go, let’s analyze this lot! First an overview of the whole caboose:
1. Lines 11-15 define the state_machine, and the wires in and out (the “port”).
We have a clock signal, the KDU 3-bit bus and the horn output. This should
be familiar from our previous readings.
2. Lines 17-55 (ouch that’s lot of lines) describe the behaviour of our
state_machine. This is not “dataflow”, we do not specify what goes where,
rather we describe how the circuit should work, and we let the VHDL
compiler produce the detailed circuitry for us. There are two distinct blocks
within this behaviour architecture declaration:
3. Lines 22-43 describe the “next_state_logic”; how we get from one state to the
next depending on inputs to the FSM, and also
4. Lines 45-53 where we specify how a particular state generates the output
signals, in this case a single bit (0 or 1) to our Horn.
OK, so now let’s turn to some details. First the “next_state_logic” code:
1. Line 24 is an “if” which says that the rest of this code block gets executed if
there is a “rising edge” of the clock. Here’s some rising edges:
clock
Rising edges
2. Lines 25-41 Tell us what to do when we are in stateA or stateB.
3. So if we are in stateA (Lines 26-31) then we test the values of KDU. If KSU is
000,001,010,011,100 then we remain in stateA. Why? Because in each of
these cases, either K=0 (and the system is disarmed) or (K=1 and D=0,U=0),
the system is armed but there is no intrusion.
4. Line 32 if KDU does not match any of the above, then we fall here. In other
words, we are armed and there’s an intrusion, so we must transit to stateB.
5. Lines 34-48: Here we are in stateB and we test the KDU values to keep us in
this state. These are all combinations of “system is armed” and there’s a Door
or Ultrasonic intrusion input. But the most important is line 35 where we have
no intrusion input, but they key is armed. This is saying we have had an
intrusion alert, so we’d better output the alarm until the system is deactivated
(K=0).
6. Line 39 We only can get here if K=0, ie the system has been deactivated.
Then we transit to stateA where the alarm is switched off.
Finally we must have a look at the “output_logic” block. This converts our “state”
into a bus-full of logic signals which provides the output or action of our system. Here
there is only one output bit, to the “horn”. So we have simply
1. Lines 48-49 If we are in stateA then we output a ‘0’ to the horn, turning it off.
2. Lines 50-51 If we are in stateB then we output a ‘1’ to the horn, turning it on.
5.3 Simulating the Circuit with Xilinx and Modelsim
As usual, we must produce a “Test Bench Waveform” in Xilinx which will be used to
drive our “Modelsim” simulation of this circuit. Here’s one I have used:
The system clock is ticking at the top. The KDU bus vector is shown under that.
Remember that we count down (see the VHDL source), so that K is KDU[2], D is
KDU[1] and U is KDU[0]. WE don’t specify the Horn – that’s the output which will
be generated by the simulation.
So what have I done here? Well note that K is off until 350ns, so the system is deenergised. So even though the door is open (at 200ns) and the clock inputs this info
into the FSM (at 300ns) we do not expect the horn to go off. Because K=0.
We energise the system at 400 ns (K=1) and after this we expect any rising edge of
the clock to trigger the alarm if either D or U or both are 1. Let’s see what Modelsim
produced for this TBWaveform.
Yep. It seems to be OK. First we note that when K=0 ([2]), even though D=1 (the
door is opened)([1]) the horn does not go off. The system is not energised. Only when
the system is energised, does the horn go off, at a rising edge of the clock.
ACTIVITY1: OVER TO YOU:
Construct several Testbench Waveforms to test out other interesting situations. Here’s
some suggestions:
1. The alarm has gone off (because an intruder opened the door) and the door is
closed by the intruder
2. The alarm has gone off (because you opened the door while the system was
armed), but then you deactivate the system (setting K=0).
3. The intruder has opened the door and set the alarm off. He then moves around
wildly and triggers the ultrasonic intruder detector.
5.4 The Circuits Synthesized By Xilinx for Spartan-3.
Let’s have a quick glance at how the circuit synthesis has proceeded. Generate the
“Technology Schematic” as usual and right-click on the functional block and “Push
into the Selected Instance”. You’ll get the Xilinx floor components which are being
used. Here’s what I got:
So there’s the usual LUT (“Look-up Table”) and then a FD (D-Flipflop) which feeds
its output back into the LUT. Let’s check-out the signals going into the LUT:
KDU[2] (that’s K) goes into LUT i2, KDU[1] (that’s D) goes into LUT i1 and
KDU[0] (that’s U) goes into LUT i0. That’s straightforward. This is what we expect
according to our understanding of digital electronic finite state machines. So far so
good. Remember what the LUT does? Yep, this implements the combinatorial logic
needed to tell the FSM how to move from one state to the next. Let’s have a look at
the contents of the LUT:
Right-click on the LUT and choose “Show LUT Content”. Here’s what I got (I’ve
taken the liberty of adding some labels to help us out in our discussion);
P
R
T
Q
S
The input i3 comes from the output of the D-Flipflop. This is the “feedback” from
current to next state.
Let’s take a couple of examples; you can provide the rest!
1. Say we are in stateA (logical 0), so i3=0. So let’s say we have sensory inputs
(KDU) = (110), the system is energised and the door is open. So we have
(i3,i2,i1,i0) = (lastState,K,D,U) = (0,1,1,0). The And-gate P outputs 0 since
i3=0. But the AND-gate Q gets two inputs “1” and so outputs a “1”. This
passes through the OR-gates S and T and emerges as an input “1” into the DFlipflop which latches it on the next clock input. This puts us into state
(logical 1) = stateB. Alarm!
2. Say we are in stateB(logical 1) and the alarm is sounding. The door is open
(D=1). You set K=0, so we have (i3,i2,i1,i0) = (lastState,K,D,u) = (1,0,1,0).
So what does this LUT circuit give us now? Since K=0 the output of P is 0.
Since i2=0, the output of Q is 0. Since k=0 the output of R is 0. So T does not
receive a 1 on either of its inputs, so it’s output is 0. This is fed to the DFlipflop which puts us back into state 0. That’s right, since you set K=0, ie
you disarmed the alarm.
3.