SCOMP-based Self-test for the DE2Bot
Troy O’Neal
Louae Tyoan
Richard Nagendran
Taylor Burdette
Zack Tufford
ECE 2031, Digital Design Lab
Section L07
Georgia Institute of Technology
School of Electrical and Computer Engineering
Submitted
April 11, 2013
1
Executive Summary
The purpose of this project is to create a self-test for the DE2Bot to ensure proper functionality.
The test consists of six major parts including basic DE2 I/O, FPGA functionality, battery charge, motor
sensors and actuators, audio beeping, and sonar function. Testing the DE2 I/O involves inputting values
into SCOMP and using them to output to the LCD, seven-segment display, and LEDs. The FPGA test
will involve manipulating stored values in memory with SCOMP functions and comparing them with
expected outputs. The battery test will involve testing the A2D for correct value communication and then
checking the battery for sufficient voltage. There will then be a short beep to test the audio. Then, the
motors will run at various speeds and check for appropriate speed readings from the optical encoders.
Finally, the sonar will activate each sensor and allow the user to check for acceptable distance values.
Naturally, some minimal human interaction will be needed for most tests in order to make sure that the
real-world components are acting as they should. Care was taken to ensure that users can still continue
with the test suite even if one or two tests fail.
2
SCOMP-based Self-test for the DE2Bot
Introduction
The DE2Bot consists of an Altera DE2 attached to a commercial AmigaBot product. The
problem at hand is to create a "self-test" that will allow the robot to test all of its major functions. Due to
the complex nature of some of the robot's features like the sonar sensors and display outputs, some human
interaction will be necessary, but this will be minimized to maintain the capability for the robot to test
much of itself autonomously. This report examines the team's approach to create a comprehensive
assembly file, several VHDL implementations, and simple computer schematics that will start from the
most fundamental of robot functions, such as basic SCOMP functions, to more complex and worldlyoriented functions such as the sonar sensors, wheel rotation, and LCD displays. Should any aspect of the
self-test fail, error code values will be displayed in order to focus on what caused the error for efficient
repair.
Technical Approach
Problem Description
The goal of this project is to design and implement a self-test for a DE2Bot using an SCOMP
program communicating with peripherals using the SCOMP I/O bus. The self-test, as currently planned
by the team, will encompass testing the following features of the DE2Bot, in the following order:
1. Basic DE2 output, including LCD, LED, and seven-segment displays
2. Core FPGA functionality, especially correct execution of SCOMP instructions
3. Battery charge
4. Motors and wheels, including the optical encoders
5. Audio beep function
6. Sonar function
Figure 1. Flowchart depicting current testing sequence. When any test fails, the user is notified.
Overall Approach
The tests will be implemented by a program running in SCOMP. The team had to decide in what
order the DE2Bot subsystems should be tested. Deciding that without basic I/O, the system has no
reliable way of communicating with the user at all, the team then reasoned that basic I/O should be the
first thing in the test sequence. The core FPGA functionality was another subsystem critical for the
remainder of the tests, and the team decided to place it second in the test sequence. The team realized that
a third subsystem that could possibly adversely affect subsequent tests is the battery, so the battery test
was placed third in the test sequence. The ordering of the remaining subsystems is arbitrary, as none
depend on each other.
Basic DE2 Output
The team decided that basic DE2 output will be tested first, because if output fails, there will be
no reliable way of indicating a failure on a subsequent test. Basic output will be tested by lighting up 16
of the LEDs, displaying a phrase on the LCD, and lighting up all segments of four characters of the seven
segment display. The LCD display will be expanded to provide full ASCII support to each of the four
available digits, and the word displayed will account for that implementation. This implementation will be
primarily to facilitate information provided to the user whilst minimizing user input. After this initial
display, the user will then be asked to examine the output devices and ensure that they are displaying
values as stipulated by the self-test assembly code. The success or failure of the output devices will be
judged by the user, who will then press KEY1 to proceed with subsequent tests.
KEY1 will also be implicitly tested here, because if pressing KEY1 fails to elicit a response, such
as the darkening of the previously lit displays and the movement on to the next test, the user will know
that there exists a problem with KEY1. Because the LEDs, the LCD, and the seven segment display are
all being provided input before KEY1 is pressed, the test will prove if a problem exists with the key or
with any of the output displays. The KEY1 implementation will be arbitrary, however, as any peripheral
device could be used to confirm a successful test with similar methods of testing allowing similar
identification of malfunction. Such devices would enable the robot to be used remotely in future
scenarios, a concept the team keeps at the core of the
test.
--------
RobotTest.asm (ASM)
This code provides an assembly file implementing the initial
test of DE2 display through LEDs and seven segment display.
Values of defined words and addresses are in Appendix A.
Taylor Burdette
ECE 2031 L07
04/09/2013
ORG
&H000
;Begin program at x000
Init:
;; Basic I/O
LOAD
STORE
OUT
OUT
OUT
LOAD
OUT
LOAD
OUT
Zero
FailCode
SONAREN
LVELCMD
RVELCMD
AllOnes
LEDS
Eights
SEVENSEG
; Disable sonar
; Stop motors
; See if LEDs are working
; See if Seven segment is working
Figure 2. Assembly code implementing the initial output test of the DE2 board peripherals.
Core FPGA
The team decided that core FPGA functionality should be tested after basic DE2 output. While
the team realized that some FPGA functionality is inherently tested by testing basic DE2 output, the team
decided to run a more thorough test. The test of core FPGA functionality is implemented by a series of
operations testing much of the SCOMP instruction set. Instructions that are tested include LOAD, ADD,
SUB, AND, OR, XOR, SHIFT, JZERO, and JUMP. Appendix A contains assembly code depicting the
SCOMP instruction set. Tests of these instructions are created by storing two operands in memory,
performing one of the listed operations, then comparing the result of the operation to a third location in
memory. If the result matches this third location, the test succeeds. If not, the user is notified through a
failure indication on the seven-segment display. Because of the ASCII implementation on the LCD
functionality, the failure can be displayed on the LCD screen as well.
Battery and Analog to Digital Converter
After core FPGA functionality, the team decided to test the battery. The team reasoned that if the
battery charge was too low, it might adversely affect other subsystems that would be tested, especially the
motors. To test the battery, an initial value 0x0080 will be read in from I2C_COMMAND. The value
will then be checked for correctness before proceeding. Then, a signal of 0x1090 is written to
I2C_COMMAND, to prepare it for writing. A signal of 0x0000 is written to I2C_DATA. This resets the
battery's internal logic and prepares it for reading. The program then waits for the I2C_BUSY flag to be
0 before proceeding. Then, a signal of 0x0190 is written to I2C_COMMAND, which tells I2C to read in
data from the battery. The program then waits for the I2C_BUSY flag to be 0 before proceeding. Then,
the program reads I2C_DATA to obtain information about the battery's level. The program will then
compare this value against a minimum threshold battery level of 108, and notify the user if failure
occurred. The user may then press KEY1 to move on to the test of the next subsystem.
Basic Audio
After the battery charge, the team decided that basic audio output should be tested. To
accomplish this, a one-second beep is emitted through the audio subsystem. To emit the one-second
beep, the team designed a new SCOMP I/O module for toggling the audio output on or off. The SCOMP
program sends a toggle command to this module, starting the beep, then loops, waiting for a timer to
elapse by one second. It then sends a second toggle command to this module, cutting off the playback of
the beep. The user is asked to judge whether the beep occurred. A method of differentiating between a
problem with the audio system and the implementation of the input/output module exists. The user can
switch on SW[16] on the DE2 board, which is set up in an XOR fashion with the input module. Only one
can be on at a time, so if a problem exists with the switch, the module will not turn off or make sound
alone, whereas if only the switch makes sound, there is an issue with the module, and if neither works, the
audio system is physically damaged. If the audio was successfully output, the user then presses KEY1,
moving on to the next test. If it did not, then the user knows that the audio subsystem has failed, and can
optionally press KEY1 to move on to the next test anyway. Appendix B, figure 1 contains
implementation of the switch and audio module. The VHDL code associated with the audio control
module is located in Appendix C.
---------
RobotTest.asm (ASM)
This code provides a segment of an assembly file for the initial
test of DE2 audio output which switches on the audio on an
input of any kind. Values of defined words and addresses are
in Appendix A.
Taylor Burdette and Troy O’Neal
ECE 2031 L07
04/09/2013
AUDIOCHECK:
;; push a 1 second beep
LOAD
One
OUT
AUDIO_CTL
AUDIOWAIT:
IN
TIMER
ADDI
-10
JNEG
AUDIOWAIT
LOAD
Zero
OUT
AUDIO_CTL
; Loop here until 1 second passes
; Shut off DAC beep
Figure 3. Assembly code implementing a toggle on the DAC audio signal. The value sent to the
module is irrelevant, but it helps readability to keep it labeled One and Zero for on and off.
Motors and Optical Encoders
After the battery is tested, the team decided that the motors and optical encoders should be tested
next. To test the motors, an enable signal will be sent to LVELCMD and RVELCMD. A low speed
value will initially be sent to LVEL and RVEL, which the optical encoders will then read. The speed
value that will be sent to LVEL and RVEL will then be compared with the velocity read from the optical
encoders. This process will be then repeated for a medium speed value and a high speed value for both
forwards and backwards velocities. Ideally, implementations to check for potential fluctuations in signal
due to latency or damage to the motor will be compensated for by checking for a short period of time.
Any deviation from the sent speed will be assessed to judge if it is worth noting to the user. Provided a
deviation from the sent velocity signal is worth alerting, the user will then be notified of such major
discrepancies in the velocity comparison. The user will then press KEY1 to move on to the next test.
Sonar
After the motor and wheel tests, the team decided that the sonar function should be tested. The
team plans to test each of the eight sonar units individually. The seven-segment display will indicate
which sonar unit is currently being tested. The LCD will show a hexadecimal representation of the
current sonar unit’s distance reading. The user will be asked to use a common, lightweight, planar object
(such as a notebook or folder) and move the object closer and farther away from the current sonar unit.
The user will then be asked to judge whether the LCD distance indicator is changing appropriately with
the physical movement of the planar object. If the user judges that the current sonar unit is performing
satisfactorily, the user then presses KEY1 to move on to testing the subsequent sonar unit. If a sonar unit
fails, the user is asked to note this result, and then optionally continue with the remaining units by
pressing KEY1. When no more sonar units remain to be tested, pressing KEY1 will move to the PASS
state, where all tests have been completed.
--------
RobotTest.asm (ASM)
This code provides a segment of an assembly file for the initial
test of DE2 sonar system. Values of defined words and
addresses are in Appendix A.
Louae Tyoan
ECE 2031 L07
04/02/2013
;; sonar test
OUT
LOAD
OUT
MAINSON1:
LOAD
OUT
IN
STORE
CALL
IN
ADDI
JNEG
TIMER
;timer to repeat until 2 sec is reached
One
SEVENSEG
; Output sum of wheel velocities to 7-seg
;FUNCTION TO DISPLAY SONAR1 DISTANCE FOR 2 SEC
EnSonar0
SONAREN
;Turn on the Sonar
DIST0
HexValue
;Implemented ASCII messages on LCD
HexToLCD
TIMER
-20
MAINSON1
Figure 4. Assembly code implementing a test of the sonar odometry system. More code will be
implemented for the other 7 sonar devices as well as a means to test resolution accuracy.
Management Plan
The two major milestones in this project occur on April 11th and April 25th. The former case is
the due date of the proposal, as well as a due date for creating a working copy of each test. This is so that
a solid test (though not necessarily completely working) is available for testing and debugging for the
remainder of the time. The second milestone is the final due-date of the project, at which point the test
and supporting documents should be finished. If time permits before the final due date, some additional
modifications may be made to help facilitate feedback to the user, such as implementing a full ASCII
LCD screen.
Contingency Plan
At the point of the project of the first milestone, the individual tests should be completed. If one
or more of these tests are still ongoing, the deadline will extend beyond the 11th, while the other working
tests are debugged. Some tests, such as the motor encoder, may need some extra work if new elements to
testing have been discovered. From here, most of the other processes are parallel, but focus will be given
to the debugging processes should it extend though their deadlines. Supporting documents should be
written after their corresponding tests are fully functional, with the final manual created after the complete
test is compiled.
Appendix A: Assembly Code Files
Appendix B: BDF Schematics
Figure 1. Schematic implementing an audio control module passed to an XOR with SW[16]. The IO_WRITE signal allows the whole DAC
to be toggled anytime a signal is sent to the control module.
Appendix C: VHDL Code Files
-------
AUDIO_CTRL.VHD (a peripheral module for SCOMP)
This module drives the UP3 board DAC independent of the switch and
latches data on the rising edge of CS.
Taylor Burdette
ECE 2031 L07
04/03/2013
LIBRARY IEEE;
LIBRARY LPM;
USE
USE
USE
USE
IEEE.STD_LOGIC_1164.ALL;
IEEE.STD_LOGIC_ARITH.ALL;
IEEE.STD_LOGIC_UNSIGNED.ALL;
LPM.LPM_COMPONENTS.ALL;
ENTITY AUDIO_CTRL
PORT(
RESETN
:
CS
:
DAC_CTRL
:
);
END AUDIO_CTRL;
IS
IN STD_LOGIC;
IN STD_LOGIC;
OUT STD_LOGIC
ARCHITECTURE a OF AUDIO_CTRL IS
SIGNAL DAC_CTRL_EN : STD_LOGIC;
BEGIN
DAC_CTRL <= DAC_CTRL_EN;
PROCESS (RESETN, CS)
BEGIN
IF (RESETN = '0') THEN
DAC_CTRL_EN <= '0';
ELSIF (RISING_EDGE(CS)) THEN
DAC_CTRL_EN <= NOT DAC_CTRL_EN;
END IF;
END PROCESS;
END a;
Appendix D: Gantt Chart
3/6/09
3/13/09
3/20/09
3/27/09
4/3/09
4/10/09
4/17/09
4/24/09
5/1/09
Brainstorming
Determine Tests Needed
Determine Implementation
Write Proposal
Proposal and Testing Due
DE2 and Peripherals
AD Converter
Battery
Motor Encoder
Motor
Sonar
Audio
Format Fail Code
Combine Code
Test and Debug
Final Modifications
Refine Code
Perform Final Tests
Create User Manual
Presentation Files
Demo and Presentation
Final Demo
Completed
Remaining