Hardware Reference
In-Depth Information
Figure 9.1
Simulation results from the VHDL code for the car alarm of i gure 8.21c.
1) Regarding the use of registers: The circuit is not overregistered. This can be observed
in the
elsif rising_edge(clk)
statement of line 44 (responsible for the inference of
l ip-l ops), which is closed in line 46, guaranteeing that only the machine state (line
45) gets stored (besides the timer, of course, designed in the previous process). The
output (
siren
) is in the next process, which is purely combinational (thus not
registered).
2) Regarding the outputs: The list of outputs (just
siren
in this example) and time
parameters (
t
max
) is exactly the same in all states (see lines 54-55, 62-63, 70-71, . . .),
and the corresponding values are always properly declared.
3) Regarding the next state: Again, the coverage is complete because all states are
included (see lines 53, 61, 69, . . .), and in each state the conditional declarations for
the next state are always i nalized with an
else
statement (lines 58, 66, 74, . . .), guar-
anteeing that no condition is left unchecked.
The total number of l ip-l ops inferred by the compiler on synthesizing this code
was 28 for sequential or Gray encoding, 29 for Johnson, and 34 for one-hot. Compare
these results against your predictions made in exercise 8.14.
Simulation results are shown in i gure 9.1.
1 ------------------------------------------------------------------
2 library ieee;
3 use ieee.std_logic_1164.all;
4 ------------------------------------------------------------------
5 entity car_alarm_with_chirps is
6 port (
7 remt, sen, clk, rst: in std_logic;
8 siren: out std_logic);
9 end entity;
10 ------------------------------------------------------------------
11 architecture moore_fsm of car_alarm_with_chirps is
12
13
--FSM-related declarations:
14
type state is (disarmed, armed, alarm, chirp1, chirp2, chirp3,
15
chirp4, chirp5, wait1, wait2);
