For our project, we decided to build an alarm system that offers some extended functionality beyond the basic "open door and trigger" concept. Our alarm allows the user to arm the device using a five-digit code entered on a keypad, and leaves him/her sixty seconds to leave the building before the system is actually armed. Upon activation, the alarm allows the user sixty seconds to enter the five-digit code before sounding a siren, which represents the functionality of a true alarm system, where the alarm system notifies the alarm company or police after a specified time period.

We feel that this adequately includes features found in most modern alarm systems.

This is the top of the hierarchy. Most of the functionality of the alarm system is contained within three modules: HAL, armdarm and 60sec.

HAL

HAL is a state machine which keeps track of the current state of the alarm system (armed, disarmed, counting down to arm, etc.), and controls the other parts of the device, including status lights, speaker and timer.

Armdarm

The armdarm module is responsible for verifying the code. All the keypad inputs go into this module and the verified output goes high, to signal HAL when the correct code has been input. The ClearFF input clears the input pipeline, so the user can begin entering the code, or clear bad input. ClearFF can be driven high either by pressing the pound key on the keypad (debouncing is provided by the circuit named oneshot2) or from HAL (clearff output) HAL will keep its ClearFF output high in all states except those where a keycode is required from the user.

60sec

60sec is a 60 second timer. The timer starts when trigger goes high, the operation of which is controlled by HAL. When a successful passcode is entered, HAL drives the clear signal high, stopping the timer and resetting it to "60". 

This module also signals HAL when 60s have elapsed - msd3 (the highest bit of the decimal digit) goes high. Another copy of oneshot2 is used to ensure the signal stays high long enough to be detected by the synchronous operation of HAL.

MrSpeaker

mrspeaker contains logic to produce speaker tones every second during the last 10 seconds of any countdown, and also to sound the alarm continuously when the alert signal is high.

SevenDecode

sevendecode is a BCD to seven segment decoder, to be wired to the seven-segment display on the Altera board.

HAL is a moore-type state machine implemented in VHDL. See hal.vhd in the appendix for the state transition sequence.

This is a 60 second timer, consisting of 3 cascaded counters. The first counter divides the 25Hz input clock by 25 to obtain a 1Hz (T=1s) clock. The output of the counter is used to clock the next MOD-10 counter which represents the seconds display. The output of this counter clocks the last MOD-6 counter which represents 10s of seconds. Finally, the RS flip-flop at the bottom of the diagram controls operation of the timer (resetting the flip-flop starts the timer)

The function of this module is to verify the code input by the user. Keypad module generates a 4bit number that represents a button currently pressed.

The KeyDetector part of the circuit detects when a key is released, by detecting when the output of keypad changes from the code of the last pressed key to 0 (nothing pressed) and generates a strobe signal. Strobe clocks the pipeline which latches the key code and also clocks the counter which keeps track of the number of keys already input.

Counter - when the counter reaches five, an enable signal (detect_digit5) is sent to the verifier.

compares the five digit code input by the user to a predefined code. The Da output goes high if they match.

The purpose of this module is to debounce the keys and encode each into a 4 bit number. The counter at the top of the schematic divides the 25MHz clock to 25Hz (this simplifies the oneshot circuits). One oneshot is used to debounce each key.

Kdecoder encodes all 11 keys into a 4 bit number (it is assumed that only one key is pressed at a time)

is a modified "one shot" circuit which is used to debounce keys. It functions as follows: when the trigger goes high p_out goes high, however when the trigger goes low, p_out stays high for 2 clock cycles, before it goes low.

is a 12 to 4 bit encoder. It is used to generate a unique code for each key on the keypad.

The project met and exceeded initial parameters as outlined on our project description and approval form. After successful implementation of the initial design, we determined that it would be desirable to make the device more user-friendly. To that end, the following features were added:

1. Ability to disarm device, by entering keycode, after siren sounds. In the initial design, if the user failed to disarm the device within sixty seconds, the siren would sound forever, until the power was shut off. This was particularly inconvenient for us, as designers, because we used the FLEXK20 chip, which requires reprogramming each time the power is turned on. This design would also be an annoyance for the real-world user.
2. Timer "tick" sound during final ten seconds of arming/disarming. During the final ten seconds of the arming phase, or during the last ten seconds of the alarm tripping phase, the speaker will now emit a "tick" sound every second, to notify the user that his/her time is running low.
3. Status LEDs to alert the user to the current condition of the device. We determined that it would be useful to alert the user to the current status of the device – armed, disarmed, arming, or tripped. The original design included only one LED, a "data request" line, to tell the user when a five-digit code was required. Subsequent to our successful implementation of the improved status panel, we decided to cause the data request LED to flash every other second, during both countdowns.

Many other features could have been added, such as those described below in the section "Retrospect Evaluation".

Although the success of our project exceeded our expectations, certain improvements could have been made in the design to eliminate some of the design problems encountered, as well as to optimize and include other features.

One such feature would have been to include the ability to set a custom passcode, rather than forcing him/her to use the code hardwired in the device. In this improved implementation, the user would press a special key, such as "*", and enter a state where s/he would be required to enter the old code and new code in succession.

As indicated, certain problems were encountered during testing and implementation. Some of these problems could have been avoided by using a better design, but some were unavoidable and a consequence of the differences between reality and theory. For instance, the keypad failed to operate in the same manner as was anticipated – the keys exhibited a "bouncing", or signal instability, phenomenon during both the key-press and key-release. Failing to anticipate the bouncing phenomenon during the release stage caused significant difficulties during testing, and required us to rewrite some of our code to handle this behaviour.

Another problem was that many of the internal signals operated asynchronously, while the state machine ("Hal") was synchronous. Such signals were sometimes not active long enough for the state machine to recognize them. In retrospect, it would have been better to design more of the circuit to operate synchronously from the beginning.

Finally, because we were initially uncertain about whether or not we wished to include the pound ("#") key as part of the five-digit keycode, problems arose while attempting to use the key as a reset switch to the circuit. Under this setup, the key counted both as a reset and then as the first key in the keycode, making the five digit key only four digits long. As such, we decided to dedicate the pound key as a reset switch and removed it from processing as part of the code.