www.igglybob.com
r.e.t.a.r.d.
Requirements and Test Document

the main

 - main page
 - about me
 - l.o.u.n.g.e.
 - r.e.t.a.r.d.
 - s.o.l. meter
 - s.c.r.e.a.m.
 - videos

the l.o.u.n.g.e.

 - overview
 - 2006 edition
 - 2007 edition
 - 2008 edition
 - control

the s.c.r.e.a.m.

 - main page
 - tech review
 - proposal
 - draft summary

the r.e.t.a.r.d.

 - overview
 - assignment
 - proposal
 - requirements
 - timeline
 - the core

the s.o.l. meter

 - overview
 - car modification
 - meter design
 - meter input

I. Objectives and Scope

This document lists the requirements for the design of the core of an audio routing device, known as "RETARD" (Real-time Equalizing Transmogrifying Audio Routing Device). It is not concerned with the physical input/output devices or the filters used to equalize audio channels, only the components which make up the RETARD core. These include the processing unit, the memory, and the "short bus" which the RETARD uses to communicate with the equalizer, physical I/O, multiplexer, and ethernet I/O devices. The audience of this document includes the product marketing engineer, engineers designing components of the RETARD, and possible end users of the audio reouting device. The document is also written with the assumption that the reader has a general knowledge of the RETARD's purpose and is somewhat familiar with its general design. Readers who are not familiar with the RETARD should refer to reference [2]. The inputs, outputs, and functional requirements of the RETARD core will be listed and detailed inside this document. However, design details and constraints of the core will be described in separate documents.

II. Definitions, Acronyms, and Abbreviations

RETARD - Real-time Equalizing Transmogrifying Audio Routing Device
MB/sec - Megabytes per second

III. References

[1] http://www.ece.gatech.edu/academic/courses/spring2007/ece4170/
[2] http://www.igglybob.com/projects/retard/proposal.php
[3] http://www.igglybob.com/projects/retard/short_bus.php
[4] http://www.opencores.org/projects.cgi/web/ethmac/overview

IV. Functional Requirements

1. The RETARD core will interface with other devices using the "Short Bus".
2. The "Short Bus" will be a 37-bit bus; 3 bits are to be used for device addressing, 2 bits for the I/O mode of the device, and 32 bits of data.
3. The RETARD core will accept input from six different devices: physical volume/equalizer/routing I/O, ethernet, an audio multiplexer, an analog-to-digital converter, a digital-to-analog converter, and an analog equalizer controller.
4. UDP packets on a to-be-specified port must be accepted and decoded into commands that control the RETARD, after being decoded by the separate ethernet controller [4].
5. The RETARD core will respond to UDP requests on system information (volume levels, equalizer levels).
6. The RETARD core will communicate properly with DHCP servers. If none is found, it will attempt to assign itself a static IP.
7. ICMP PING requests will be handled correctly.
8. The RETARD core must be able to process audio at 96 KHz.
9. The RETARD core will be able to transmogrify audio according to a given impulse response filter.
10. Audio must be transmogrified in real-time (delay from input to output must be less than 10ms, preferably less than 1ms).
11. The RETARD core must have an audio throughput of approximately 4.7 MB/sec (8 channels of stereo audio, with 3 byte samples at 96 KHz).

V. Input Requirements

1. Digitized audio input will be accepted at 96 KHz, with 24-bit samples.
2. Input from the physical volume/equalizer/routing controls will be in the following format:
    a. The status of the physical controls, equalizer controller, and audio multiplexer will be checked periodically.
    b. The physical controls will report when the volume levels, gain levels, impulse filter, or routing of the audio is being changed.
    c. The equalizer controller will report the gain levels it is implementing for each channel.
    d. The routing controller will report the input channel being used for each output channel.
3. Input from the ethernet interface will be 32-bit words first processed by a separate ethernet controller [4], at speeds of up to 12.5 MB/sec (100 MBit/sec).
4. The following devices will be controllable through input through the ethernet interface (after being processed by the RETARD core): volume, equalizer, audio routing, and impulse filter.
4. Input from the analog-to-digital converter will be 24-bit audio data (with 8 bits specifying the audio channel and the stereo channel).

VI. Output Requirements

1. Transmogrified digital audio output will be sent to the digital-to-analog converter at 96 KHz, with 24-bit samples.
2. UDP and ICMP output packets will be sent to the ethernet controller in 32-bit words.
3. The equalizer controller will accept output from the RETARD core specifying when it should change its gain levels, and what channel the level should be changed for.
4. The physical I/O devices will accept output from the RETARD core specifying volume levels, which input channel is being used by each output channel, and equalizer gain levels.
5. The audio multiplexer will accept output from the RETARD core specifying the input channels associated with each output channel.

VII. Integration Requirements

1. The RETARD core must use the Short Bus [3] exclusively to communicate with other devices.

VIII. Testing and Debugging Requirements

1. Components that need to tested include audio output, impulse filters, input multiplexing, equalizer control, volume control, and the ethernet controller.
2. Testing normal audio output
    a. Audio input can be generated using any device that outputs audio in analog form. Preferably, a computer will be used in conjunction with a media player.
    b. The output of the RETARD can be hooked up to a set of speakers. Then, its output can be compared with the output of the computer. If no filters or equalizing are being applied, both input and output should be identical. This can be verified simply by listening.
3. Testing impulse filters
    a. A simple C program can be written to implement the same sort of impulse filter that the RETARD core implements. The output of this can be compared (by listening) to the output of the RETARD.
    b. This can also be tested during simulation by creating a set of test vectors using the previously written C program.
4. Input multiplexing can be tested using generic audio input, but creating predefined vectors for the audio routing table. The output can be checked by looking at a waveform of the outputs.
5. The ethernet controller can be tested with a simple C program that sends all the control combinations as input.
6. Volume control can also be tested by listening to the output of the RETARD.
7. Simple C programs can be written to test the control signals sent to the devices on the Short Bus by generating test vectors to send input to the RETARD core.

IX. Metrics and Evaluation

1. The open-source simulator GHDL will be used to test the input-output delay time, to verify that it is less than 10ms (or preferably less than 1ms).
2. The RETARD will be tested thoroughly after being loaded onto an FPGA. At this point, the RETARD peripherals will be connected and the RETARD will be used in the way an end user would use it (as a stereo system controller).
3. A large amount of evaluation will be done based on a user's percieved quality of the audio.