ECE 477 Final Report

batterycopperInternet και Εφαρμογές Web

12 Νοε 2013 (πριν από 3 χρόνια και 4 μήνες)

220 εμφανίσεις






E
C
E 477 Final Report



Spring 2009

Team 6



ALF


Team Members:


#1:
Andrew Hartnett




Signature: ____________________ Date: _________


#2:
David Eslinger




Signature: ____________________ Date: _________


#3:
Curt Schieler




Signature: ________________
____ Date: _________


#4:
Ken Pesyna





Signature: ____________________ Date: _________



CRITERION

SCORE

MPY

PTS

Technical content

0 1 2 3 4 5 6 7 8 9 10

3


Design documentation

0 1 2 3 4 5 6 7 8 9 10

3


Technic
al writing style

0 1 2 3 4 5 6 7 8 9 10

2


Contributions

0 1 2 3 4 5 6 7 8 9 10

1


Editing

0 1 2 3 4 5 6 7 8 9 10

1


Comments:

TOTAL




ECE 477 Final Report


Spring 2009


-
ii
-

TABLE OF CONTENTS


Abstract

1


1.0
Project Overview

and Block Diagram

1


2.0
Team Success Criteria

and
Fulfillment

3



3.0
Constraint Analysis

and
Component Selection

4


4.0
Patent Liability Analysis

9


5.0
Reliability and Safety Analysis

17


6.0
Ethical

and
Environmental Impact Analysis

21


7.0
Packaging Design Considerations

25


8.0
Schematic Design Considerations

28


9.0
PCB Layout Design Considerations

31

10.0
Software Design Considerations

34

11.0
V
ersion
2 Changes

42

12.0 Summary and Conclusions

43

13.0 References

44

Ap
pendix A: Individual Contributions

A
-
1

Appendix B:
Packaging

B
-
1

Appendix
C
: Schematic

C
-
1

Appendix
D
:
PCB
Layout Top
and

Bottom Copper

D
-
1

Appendix
E
: Parts List Spreadsheet

E
-
1

Appendix
F
: Software Listing

F
-
1

Appendix
G
: FMECA Worksheet

G
-
1

ECE 477 Final Report


Spring 2009


-
1
-

Abstract


This report is a complete presentation of the design of ALF. The report contains the analysis,
constraints, and considerations developed throughout the design process, as well as the final
design. The final design includes
the documentation fo
r the hardware, software, and packaging.


1.0

Project Overview

and Block Diagram


ALF is a device that can record and store audio to memory, playback audio from memory, and
manipulate audio while streaming. The audio manipulation that ALF is capable of is to a
dd a
flange effect. The original intent of ALF was also to implement the FLAC audio compression
algorithm, specifically rice coding, while storing audio to memory and also implement FLAC
audio decompression during audio playback. However due to the complex
ity of the FLAC
algorithm, implementing FLAC was not reasonably achievable in the time available. ALF has a
line
-
in jack to accept analog audio input for recording and streaming. In addition, there will be a
line
-
out jack to connect audio output to headpho
nes or speakers for playback and streaming.
ALF can store up to 20 seconds of audio data in the onboard memory. ALF has an intuitive user
interface in the form of 3 pushbuttons and an LCD that allows the user to control the record,
stream, playback, volume
, storage, and manipulation modes. The user will be presented with a
menu for each of these modes and can select between different options within each menu and

cycle through the menus using the pushbuttons.

The block diagram and final picture of the
projec
t are shown below.



ECE 477 Final Report


Spring 2009


-
2
-

Figure
1
.1
: Block Diagram



Figure
1.2
: Completed Project



ECE 477 Final Report


Spring 2009


-
3
-

2.0

Team Success Criteria and Fulfillment


Revised Project Specific Success Criteria



An ability to store data in external memory.



An ability to display

relevant information on an LCD.



An ability to send commands from a microcontroller to an FPGA.



An ability to capture audio from a CODEC.



An ability to manipulate audio (i.e. produce an effect or filter) while streaming audio.

Old Project Specific Success
Criteria



An ability to encode streaming audio into a FLAC format using the Rice compression
algorithm.



An ability to decode FLAC for playback.



An ability to store data in external memory



An ability to compute latency between input audio and playback.



An a
bility to display relevant information on an LCD.

All of the revised Project Specific Success Criteria were fulfilled. Th
re
e

of the old Project
Specific Success Criteria were not achieved.


ECE 477 Final Report


Spring 2009


-
4
-

3.0

Constraint Analysis and Component Selection


3.1
Introduction

Th
is project will be able to receive an analog audio input, compress it into a FLAC file, and
then decompress the FLAC file for audio playback. The FPGA will do the linear predictive
coding and rice coding computations. The design will be powered

from a wall

outlet, implying
loose power constraints. The device should also be able to store at least one minute of
compressed audio data. Finally, the user needs an intuitive interface that will control the audio
recorder and

cycle through

the information displayed

on the LCD.


3.2


Design Constraint Analysis

One constraint that will guide the selection of the parts is the

objective of

achieving

CD
quality audio, a well
-
justified objective when dealing with lossless compression. Another major
constraint is the computati
onal requirement of the FLAC coding, which will be

done solely in the
FPGA, for two

reasons. First, the computations can be done quickly in the FPGA and second,
the

purpose

of this project lies in implementing Rice coding in an FPGA. The microcontroller
wi
ll be using an SPI interface to connect to the LCD. Four pushbuttons will also be connected to
general purpose I/O pins of the microcontroller for user interface. The microcontroller should
also have a UART so that the data on SRAM can be dumped for debugg
ing. In order to get about
30 seconds of audio at an estimated compression ratio of 60%, a 4 MB SDRAM chip is required:



When ALF is compressing audio, we will collect 4096 samples of audio to have one
‘block’ of audio which will then be comp
ressed. ALF will compress one block of audio while we
are collecting samples for the next block of audio. It will take




To collect enough samples for one block of audio, meaning that we have 8,533,000 clock cycles
to do all the computations

for compression as well. This should be an ample amount of time to
perform compression. There are very few constraints for the microcontroller; it needs to be able
to refresh the LCD fast enough via UART, and communicate with the FPGA via SPI.

ECE 477 Final Report


Spring 2009


-
5
-

3.3


Computatio
n Requirements

In order to achieve CD quality audio, the incoming audio will need to be sampled at a rate of
at least 48 kHz. All computations for FLAC encoding will need to be done fast enough to keep
up with the sampling rate if ALF is to be able to comp
ress a “live” stream of audio. Also, the
FLAC data needs to be decoded fast enough for continuous playback.

For each sample in a
frame, the design is going to compute the autocorrelation between the previous samples and the
current sample.

Based on the

aut
ocorrelation of the frame, it will assign a predictor from a set of
fixed predictors. The design will then compute the residual between the predicted value and the
original data. The residual is then encoded in one pass using the Rice coding algorithm. Bec
ause
the Rice coding is a simpler algor
ithm than the linear predictive coding, the latter

will likely be
the bottleneck of the design. One feature of the design will be the capability to calculate latency
from

encoding to decoding,

which can be done in eit
her the FPGA or the microcontroller. This
computation is fairly straightforward,

and will not

create

a system bottleneck.


The latency
displayed will either be a running average, a windowed average, or the current latency.

3.4


Interface Requirements

An Audi
o CODEC chip will be used to

sample the audio and play back

the uncompressed
data, using an internal ADC and DAC. There are 8 pins that will be needed for this chip to
communicate with and transfer data to and from the FPGA. Also, there will need to be 38
pins
for connecting the FPGA and SDRAM: a 16 bit data bus, a 12 bit address bus, and 10 additional
pins for configuration. An

SPI interface will be used to connect the microcontroller to the LCD.
Four pushbuttons will be used to allow a user to start and s
top recording, play back stored data,
cycle through the information being displayed on the LCD, and select whether the recorded data
will be saved

to external memory or immediately played back to determine latency.

The

microcontroller has a maximum of

25
mA that it can sink or source on

any given I/O pin

with a
total of 200 mA that it can sink or source across all pins. The microcontroller interfaces with the
LCD using SPI and pushbuttons through

general purpose I/O. However, the digital VOH for the
microc
ontroller is Vdd (nominal 2.5V) and the LCD runs on 5V. Therefore, a DC voltage
controller will be needed to allow for proper SPI communication between these two devices. The
FPGA has a minimum DC output current per pin of

-
25mA and a maximum of

40mA
.



ECE 477 Final Report


Spring 2009


-
6
-

3.5


O
n
-
Chip Peripheral Requirements

The microcontroller of this design will need two SPI modules and a UART module. One SPI
module will be used for interfacing with the LCD while the other SPI module will likely be used
to communicate with the FPGA. The UART wi
ll be used to dump the data received from the
external memory chip onto a computer for debugging.


3.6


Off
-
Chip Peripheral Requirements

One possible method to achieve CD quality audio is for the design to have a 1 channel 16 bit
parallel ADC (and matching DAC
). However, the design will instead use an Audio CODEC that
has these things built in. This Audio CODEC should have headphone drivers and a
programmable sample rate and resolution. The incoming audio data will then be pa
ssed from the
CODEC to the FPGA
. Aft
er compression, the data will be stored on off
-
chip, on
-
board SDRAM.
The uncompressed audio will then be passed back to the CODEC for playback over the line
-
out
jack
.



3.7


Power Constraints

The PIC [1]

microcontroller

has an input voltage requirement

of

2.2

-

3.6V. The Cyclone III
FPGA [2]

has input voltage requirement of 1.2V for the core logic. The SDRAM [3]

has an input
voltage requirement of 3.3V and operates at a maximum supply current of 145 mA. The
audio

CODEC [4] has an input voltage requirement
3.3V
. The LCD

[5] has an input voltage
requirement of 5V and operates at 380 mA with the backlight on and 9mA with the backlight off.
ALF will have 3 LDOs; a 9V to 5V regulator, a 5V to 1.2V regulator, and a 5V to 3.3V/2.5V
regulator. Since we are using a 4 la
yer board, each of these voltages will go to its own section of
the power plane.


3.8


Packaging Constraints

This design is not constrained by size or weight. Within reason, the package should be
portable and not sensitive to small movements. There should be
easy access to a port for the
analog input and output (microphone, speaker, etc)
.

The final project fits in a 6.3” by 6.3” by
2.4” project box, with the PCB being approximately 5.25” by 5.25”.


ECE 477 Final Report


Spring 2009


-
7
-

3.9


Cost Constraints

As this design is not directly competing wi
th any existing projects (it is a research project),
low
-
cost is a benefit but not a constraint. Cost for the final project may be high because this is a
high
-
quality audio recorder. This design will be sponsored up to an amount of $1000; however
this amou
nt should be more than required
.


3.10
Component Selection Rationale


Table 3.
1
:
Major Component Selection

Component needed

Possible parts

Part Chosen

FPGA

Xilinx Spartan 3a, Altera
Cyclone III

Altera Cyclone III

Microcontroller

PIC24F, Atmel AT89

PIC24F

Memory

SDRAM, SRAM

SDRAM (specific part
that is on development
board)

Audio Sampling

CODEC, our own circuit

CODEC (specific part
that is on development
board)


The Altera Cyclone III and the Xilinx Spartan 3a are two FPGAs tha
t fit the needs of this
project. The Spartan 3a costs less, but more support and resources are available for the Cyclone
III. Consequently, the Cyclone III will be used for this project. The Microchip PIC24F and the
Atmel AT89 are both microcontrollers tha
t fit the needs of this project. The PIC24F is a 16
-
bit
microcontroller that operates at 32 MHz with 64
kB

of FLASH. The AT89 is an 8
-
bit
microcontroller that
operates at 20 MHz with 4 kB

of FLASH. Both of the microcontrollers
have SPI and UART modules; ho
wever, the AT89 only has one SPI module while the PIC24F
has two. The AT89 could overcome this by

being the master for two slave

devices. The benefit
of the AT89 is that it is smaller, which agrees with the low microcontroller resources required
by the pro
ject. However, the PIC24F will be chosen because of familiarity with the product, the
fact that it has two SPI modules, and the flexibility of the microcontroller to handle unforeseen
ECE 477 Final Report


Spring 2009


-
8
-

tasks. SDRAM, SRAM, and FLASH are all available types of memory that cou
ld be used to
store compressed data. However, it is easier to obtain large SDRAM than SRAM.FLASH will
not be used because data will have to be written to memory frequently. This leaves SDRAM as
the obvious choice for the design. In order to facilitate imme
diate prototyping, the IS42
S16400
SDRAM chip,
the same as on the development board
, will be used
. Two systems could be used
for the analog audio input/output. One system entails purchasing a16 bit ADC and DAC, and
using a preamp and post
-
DAC filter. The ot
her option simply uses an Audio Codec with these
features built
-
in. The Audio CODEC is a very low
-
cost system, and easily integrates into the
design. The Audio CODEC will be used because using a separate ADC and DAC only adds
unnecessary complexity. In ord
er to facili
t
ate immediate prototyping, the proposed Audio
CODEC, WM8731SEDS, will be the same as on the development board.


3.11
Summary

This project’s main design constraints are

strongly determined

by

two primary objectives:
achieving high
-
quality audi
o and performing FLAC
-
related computations faster than the audio
sampling rate. Other design constraints

arise from the need to store large amounts of data, and
the need

for user

control and display. Given these constraints, the

FPGA will act

as the core,
performing the FLAC compu
tations, while the Audio CODEC

will handle the

audio input and
output. SDRAM will be the external memory used for storing data, and

a microcontroller will
provide the SPI and UART necessary for interfacing between the FPGA and user

(LCD and
pushbuttons).

Because of the nature of

the project, the cost, power, and packaging constraints
are largely minor.

The component

selection

was mainly guided by familiarity and availability of
products. In the end, the Altera FPGA was chosen

becaus
e of the

local development board,
and

the Audio CODEC was chosen

because it merged audio input and output into a simple
environment. As for the other major components, the SDRAM was chosen

because of

size
requirements, and the PIC

because of familiarity
.



ECE 477 Final Report


Spring 2009


-
9
-

4.0

Patent Liability Analysis



4.1
Introduction

ALF allows a user to
record
audio
using lossless compression
from a line
-
in and either store
the compressed file for later playback, or decode immediately to calculate the latency of the
compression algorit
hm.

The audio will be compressed into the Free Lossless Audio CODEC
(FLAC) format, so that performance of the Rice Encoding method can be analyzed when
performed on an FPGA.
The audio input and output will consist of line in and line out jacks, and
an Audi
o CODEC chip that handles analog and digital conversion. ALF will be able to store at
least one minute of compressed audio, which will be stored in SDRAM; there will also be an
RS232 connection for dumping the memory for external viewing.
The FPGA performs

all of the
actual compression, decoding, and interfacing with the
SDRAM and the left and right audio
channels via an Audio CODEC.
The user will have four pushbuttons that are accessible, one to
begin/stop recording, one to play audio currently saved in in
ternal memory, one to change what
is currently displayed on the LCD, and one to select either to save the audio into internal memory
or immediately decode the audio. There will be a small LCD to display to the user information of
interest about the audio,
such as latency, size of file saved, and duration of recorded audio. All
requests by the user will be initially handled by the microcontroller, which will then pass any
necessary information to the Field Programmable Gate Array (FPGA).
ALF could certainly
be
susceptible to patent infringement since audio compression is by no means a new concept, and
has been implemented in many devices currently patented and on the market. Whether ALF's
goal of implementing FLAC (and Rice coding) in an FPGA has been patente
d is the purpose of
this liability analysis.


4.2


Results of Patent and Product Search

After an extensive patent search, three patents have been identified which ALF is most
likely to infringe upon. The first patent

[11]
, titled "Rice Lossless Compression Mod
ule," filed
by Honeywell International, is a patent for implementing a Rice coding compression module in
an FPGA. The second patent

[12]
, titled "Lossless compression/decompression of digital audio
data," filed by Merging Technologies, is a patent for a me
thod of compression and
decompressing audio losslessly using waveform prediction methods and Huffman coding tables.
The third patent

[13]
, titled "Lossless compression method and apparatus for data storage and
ECE 477 Final Report


Spring 2009


-
10
-

transmission," is a patent for compressing dat
a and storing it to a storage device as well as
decompressing it and sending it to an external device. Below are abstracts provided by each
patent as well as relevant claims that ALF may infringe upon.


4.2.1

United States Patent

#7430328

Title:

Rice lossl
ess compression module

Filing Date:

12/01/2004

Assignee:

Honeywell International Inc.


Abstract:

A Rice coding data compression module includes a memory interface operable to receive sensor
data from memory, a data normalization module operable to normaliz
e received sensor data, an
encoder operable to apply a Rice compression algorithm to the normalized data to produce
compressed sensor data, a data management module operable to apply packet formatting to the
compressed sensor data to produce formatted comp
ressed sensor data packets; and a memory
interface operable to store the formatted compressed sensor data packets to memory.


Key claims of potential infringement:

1. A Rice coding data compression module, comprising: a memory interface operable to receive

sensor data from memory; a data normalization module operable to normalize received sensor
data; an encoder operable to apply a Rice compression algorithm to the normalized data to
produce compressed sensor data; a data management module operable to apply

packet formatting
to the compressed sensor data to produce formatted compressed sensor data packets; and a
memory interface operable to store the formatted compressed sensor data packets to memory.


2. The Rice coding data compression module of claim 1, w
herein the module is embodied in a
FPGA (Field Programmable Gate Array).


4.2.2

United States Patent

#5884269

ECE 477 Final Report


Spring 2009


-
11
-

Title:

Lossless compression/decompression of digital audio data

Filing Date:

12/01/2004

Assignee:

Merging Technologies (Puidoux, CH)


Abstract:

An

audio signal compression and decompression method and apparatus that provide lossless,
real
-
time performance. The compression/decompression method and apparatus are based on an
entropy encoding technique using multiple Huffman code tables. Uncompressed au
dio data
samples are first processed by a prediction filter which generates prediction error samples. An
optimum coding table is then selected from a number of different preselected tables which have
been tailored to different probability density functions

of the prediction error. For each frame of
prediction error samples, an entropy encoder selects the one Huffman code table which will yield
the shortest encoded representation of the frame of prediction error samples. The frame of
prediction error samples

is then encoded using the selected Huffman code table. A block
structure for the compressed data and a decoder for reconstructing the original audio signal from
the compressed data are also disclosed.


Key claims of potential infringement:

1. A method of
encoding audio data comprising the steps of:

--
generating a frame of prediction error samples from a frame of audio data samples;

--
determining the cost of coding the frame of prediction error samples using each of a plurality of
code tables, said pluralit
y of code tables each corresponding to a different probability density
function of a distribution of the prediction error samples;

--
determining which one of the plurality of code tables will provide the lowest cost of coding the
frame of prediction error
samples; and

--
coding the frame of prediction error samples using the one of the plurality of code tables
providing the lowest cost of coding the frame of prediction error samples.


2. The method of claim 1, wherein the cost of coding the frame of predicti
on error samples
includes the number of bits used to represent the encoded frame of prediction error samples.


ECE 477 Final Report


Spring 2009


-
12
-

3. The method of claim 1, further comprising the step of forming a block of encoded audio data
by adding a header to the frame of encoded predict
ion error samples.


4. The method of claim 3 further comprising the step of forming an index file, the index file
including block length and level information for each of a plurality of blocks of encoded audio
data.


4.2.3

United States Patent Application

#20060010151 (Patent pending)

Title:

Lossless compression method and apparatus for data storage and transmission

Filing Date:

05/25/200

Author:

Star Sung, Chih
-
ta (Glonn, DE)


Abstract:

The present invention provides method and apparatus of a lossless data

compression to reduce
the amount of data to be transmitted or to be saved into a storage device. In the VLSI
implementation, a data path module combined with some state machines support multiple
formats of data file and to execute the function of the loss
less data compression. The amount of
the program data of a File System is reduced by a lossless compression method before it is saved
into the storage device and to be recovered to execute the function of a File System. Before
transmission, the data file c
ompressed by the lossless compression algorithm coupled with the
corresponding decompression code will be packed into a data stream and the receiving node will
recover the data file by executing the decompression code.


Key claims of potential infringement
:

1. A method of performing lossless data compression and decompression for data storage,
comprising: reading a target data file from an external device; compressing the target data file by
a corresponding lossless compression algorithm according to differ
ent file formats into
compressed data; storing the compressed data into a storage device; reading a compressed target
data file from a location of a storage memory; decompressing a target data file by a
ECE 477 Final Report


Spring 2009


-
13
-

corresponding decompression algorithm according to di
fferent file formats; and sending the
decompressed data into the external device;

...

3. The method of claim 1, wherein a micro
-
controller engine is implemented to control the data
flowing between an external device, a semiconductor memory and a lossless c
ompression and
decompression engine.

...

5. The method of claim 1, wherein a storage memory is an SRAM or a DRAM.


4.3


Analysis of Patent Liability

It

can be concluded that ALF has literal infringement with one patent, identified above, and
also
possible
infr
ingement under the doctrine of equivalents with the other two patents identified.

Under the first patent, titled "Rice Lossless Compression Module," the claims state that there
is a Rice compression module implemented in an FPGA. It can be determined that
ALF has
literal infringement with this patent. Though ALF actually implements the FLAC compression
algorithm, FLAC uses Rice coding to code the residuals of the difference between the actual
input audio waveform and the waveform prediction. Thus ALF's adde
d function of using FLAC
does not eliminate the infringement upon this patent. Since ALF is performing exactly the same
function, lossless audio compression, in exactly the same way, using Rice coding in an FPGA, it
can be concluded that ALF has literal in
fringement with this patent.

Under the second patent, titled "Lossless compression/decompression of digital audio data,"
claim 1 states that a frame of prediction error samples is generated from a frame of audio data
samples. These prediction error samples

are then coded using one of a set of Huffman Code
tables. Within the FLAC algorithm that ALF will use, prediction error samples will be created
from the audio input samples. Therefore ALF will infringe upon this part of the claim. However,
ALF will then e
ncode these error samples, called residuals, using Rice coding and not code
tables. Thus, ALF does not infringe upon this part of the claim. ALF also infringes upon claims
2, 3, and 4. For ALF, the cost of encoding the residuals
is

the number of bits used
to represent
the encoded frame of residuals. In addition, each frame will contain a header to form a block of
encoded data and there will also be an overarching index file which will contain critical
information about the FLAC file such a block length. Aft
er analyzing these claims, it could be
ECE 477 Final Report


Spring 2009


-
14
-

concluded that ALF performs substantially the same function in substantially the same way as
this patent. If so, ALF would infringe upon this patent under the doctrine of equivalents. It could
also be debated, however
, that since FLAC is a "Free Lossless Audio Codec" and is open
-
source,
it is not patentable and does not infringe upon the software algorithms mentioned in the claims
above.

In the FLAC license, its developers mention that "Neither the FLAC nor Ogg FLAC
fo
rmats nor any of the implemented encoding/decoding methods are covered by any known
patent."

Thus, one could argue that ALF is not actually infringing on this patent
.

Under the third patent, titled "
Lossless

compression method and apparatus for data storag
e
and transmission," claim 1 states that the data compression is done by reading the data from an
external device, compressing it according to a file format (such as FLAC), and storing the
compressed data to a storage device. It also states that decompress
ion is done in the opposite
manner by reading the data file from storage memory, decompressing it according to a file
format and sending the decompressed data to an external device. In ALF, data will be retrieved
by samp
l
ing it from streaming audio input.
Therefore, ALF does not infringe upon this part of
the claim. However, ALF will compress the d
ata according to the file format
FLAC, and will
then have the option to store this compress
ed data to SDRAM. Thus, ALF may

infringe upon this
part of the claim. C
laim 3 of the patent states that a microcontroller is used to control data flow
between the external device, the memory, and the compression and decompression engine. ALF's
microcontroller will not control the data flow between the input data, our FPGA, an
d the
memory. Conversely, our microcontroller is merely used to signal the FPGA when to begin
sampling, compressing/decompressing, and storing data. Thus ALF does not infringe upon this
claim. Claim 5 states that the storage memory is SRAM or DRAM.
ALF use
s SDRAM which is
a synchronous from of DRAM. Though it may sound similar to DRAM, SDRAM is actually
functions quite different
l
y than DRAM which is asynchronous. Therefore, ALF most likely
would not infringe on this claim. After analyzing these claims, it i
s unclear as to whether ALF
would infringe upon this patent. On one hand, it could be concluded that ALF performs
substantially the same function in substantially the same way as this patent. If so, ALF would
infringe upon this patent under the doctrine of

equivalents. However, it could also be concluded,
based upon the claims mentioned above, that ALF is performing a slightly different function in a
slightly

different way since ALF is sampling streaming in input (instead of reading a data file
from storage
) and is using an FPGA instead of a microcontroller to control data flow.

ECE 477 Final Report


Spring 2009


-
15
-

4.4


Action Recommended

For the Honeywell patent, the literal infringement forms the basis for our entire project:
implementing rice coding in an FPGA. Thus, there is fundamentally no wa
y to work around this
patent. As a result, if ALF was commercialized, it would be practical to buy a license for this
patent or pay royalties to the inventor for each device created.

With respect to the Merging Technologies patent, ALF may be able to get a
round this patent
by mentioning that FLAC is a "Free Lossless Audio Codec" and is open source software.
Therefore, from a purely software viewpoint, FLAC itself

is not patentable. T
hough many of the
algorithms in FLAC seem to match up with the algorit
hms i
n this patent, FLAC, as open
-
source
software, may not
actually

be

infringing on them. Thus, one could argue that ALF is not actually
infringing on this patent
.

With respect to the Star Sung patent, the only part of the patent that ALF could be infringing
u
pon is the compression and storage claims. Since the main purpose of the patent is to store
compressed data to a storage device and decompress data from this device, ALF could easily
avoid infringing upon this patent by eliminating storing the compressed d
ata at all. ALF could, if
necessary, merely compress the data and immediately decompress it and still achieve its purpose
of implementing Rice Coding in and FPGA. However, as mentioned earlier, it could be
concluded that ALF performs a different enough fun
ction in a different enough way to not
infringe upon this patent in the first place.

4.5


Summary

There are three primary patents which ALF has potential to infringe upon. The first patent
titled "
Rice lossless compression module" filed by Honeywell Internatio
nal patents
implementing a Rice Coding module in an FPGA. Since this is the primary purpose of ALF,
ALF has literal infringement with this patent. The second patent titled "Lossless
compression/decompression of digital audio data" filed by a company called

Merging
Technologies patents a method of compressing and decompressing an audio signal to provide
lossless, real
-
time performance using waveform prediction methods and Huffman coding tables.
ALF may be able to get around this patent by claiming that the F
LAC codec is open source, and
therefore, from a software standpoint, even though it uses similar compression methods, does not
infringe upon this patent. The third patent titled "
Lossless

compression method and apparatus for
data storage and transmission,"

filed by
Star Sung
is a patent for compressing data and storing it
ECE 477 Final Report


Spring 2009


-
16
-

to a storage device as well as decompressing it and sending it to an external device. From a
high
-
level

viewpoint, it appears that ALF may be infringing upon this patent since it performs
a
similar function. However, looking more closely at the individual claims, it can be determined
that there are a number of claims that show that ALF implements this function in a slightly
different way.

In conclusion, w
hen looking at the
se patents altoget
her,
it is likely that one would
most likely need to buy licenses or pay royalties to inventors in order to commercialize ALF

as
is
.


ECE 477 Final Report


Spring 2009


-
17
-

5.0

Reliability and Safety Analysis




5.1
Introduction

ALF allows a user to
record
audio
using lossless compression
from

a line
-
in and either store
the compressed file for later playback, or decode immediately to calculate the latency of the
compression algorithm. The audio will be compressed into the Free Lossless Audio CODEC
(FLAC) format, so that performance of the Rice
Encoding method can be analyzed when
performed on an FPGA.
The audio input and output will consist of line
-
in and line
-
out jacks, and
an Audio CODEC chip that handles analog and digital conversion. ALF will be able to store at
least
thirty seconds

of compr
essed audio, which will be stored in SDRAM; there will also be an
RS232 connection for dumping the memory for external viewing.
The FPGA performs all of the
a
ctual compression, decoding, and

interfacing with the
SDRAM

and the left and right audio
channels
via an Audio CODEC.
The user will have
three

pushbuttons, one to begin/stop
recording, one to play audio currently saved in internal memory, one to change what is currently
displayed on the LCD, and one to select either to save the audio into internal memo
ry or
immediately decode the audio. There will be a small LCD to display to the user information of
interest about the audio, such as latency, size of file saved, and duration of recorded audio. All
requests by the user will be initially handled by the mic
rocontroller, which will then pass any
necessary information to the Field
Programmable Gate Array (FPGA). In this report, the
reliability and safety of ALF is analyzed. In order to identify the possible failures that could
occur, the schematic for ALF wa
s broken into several functional blocks to analyze separately.
The most critical safety issue concerning ALF is the possibility of a fire resulting from a short in
a power regulator. A few of the most critical components that will be analyzed for reliabi
lity are
the Microchip PIC24FJ64 microcontroller [1], the Altera EP3C40 FPGA [2], and the Diodes Inc.
AP111
7 five volt linear regulator [
14
]
.


5.2


Reliability Analysis


The three components most likely to fail in the design are the FPGA, the PIC micro
-
control
ler, and the five volt regulator. These components were chosen due to their complexity,
criticality to the product functioning, and power dissipation.

The following tables show the parameters used for each component to calculate the number
of failures per

10
6

hours and mean time to failure (MTTF). All three of these components use
ECE 477 Final Report


Spring 2009


-
18
-

the following model from page 25 of the Military Handbook


Reliability Predi
ction of
Electronic Equipment [15
]:


L
Q
E
T
P
C
C





2
1



and


1


P
MTTF

.


Table
5.1
: F
PGA (Altera EP3C40)

Parameter

Value

Assumptions

C
1

0.29

MOS Digital and Linear Gate/Logic Array, 30,001 to
60,000 Gates

π
T

2.8

Linear, temp of 70
°
C

C
2

0.0748

140 Functional Pins, Nonhermetic

π
E

2

Ground Fixed

π
Q

10

Commercially manufactured component

π
L

1

More than 2 years in production

λ
P

9.616

Failures/10
6

hours

MTTF

103,993.3444 hours = 11.871 years


Table
5.2
: Microcontroller (Microchip PIC24FJ64)

Parameter

Value

Assumptions

C
1

0.28

16 bit, CMOS

π
T

2.8

Linear, temp of
70
°
C

C
2

0.01

22 Functio
nal Pins, Nonhermetic

π
E

2

Ground Fixed

π
Q

10

Commercially manufactured component

π
L

1

More than 2 years in production

λ
P

8.04

Failures/10
6

hours

MTTF

124,378.1095 hours = 14.198 years


Table
5.3
: 5V Linear Regulator (Diodes Inc AP1117)

Parameter

Val
ue

Assumptions

C
1

0.01

Linear, MOS device, between 1
-
100 transistors

π
T

2.8

Linear, max temp of
70
°
C

C
2

0.0012

3 Functional Pins, Nonhermetic

π
E

2

Ground Fixed

π
Q

10

Commercially manufactured component

π
L

1

More than 2 years in production

λ
P

0.304

F
ailures/10
6

hours

MTTF

3,289,473.684 hours = 375.511 years



These results are lower than they should be for recommended reliability. The MTTF for the
five volt regulator (Table 3) is especially low for its criticality rating (high). The π
T
used in
the
se calculations contributed to the low results. If a more realistic value (temperature of 50°C)
was used, the MTTFs would increase to more reasonable values.



ECE 477 Final Report


Spring 2009


-
19
-

5.3


Failure Mode, Effects, and Criticality Analysis (FMECA)


There are three criticality levels f
or types of failures in the output of this design. A “High”
failure is one that could result in injury to the user. The only “High” failures for this product are
related to the power supply, and refer to the rare possibility that a short in one of the re
gulators
causes a fire. An acceptable failure rate


for a “High” failure is




10
-
9

because of potential
injury to the user. A “Medium” failure is a failure that could result in major damage to the
many components (or a single component that would be d
ifficult to replace) of the product, but
not cause any injury to the user. An example of a “Medium” failure is the SDRAM getting fried
because the SDRAM chip has 54 pins and would be difficult to replace.
An acceptable failure
rate


for a “Medium” failu
re is




10
-
7
. The third criticality level is a “Low” failure. This
type of failure results in minimal damage to the product and is easily fixed. The pushbutton
wires becoming unconnected is an example of a “Low” failure because no real damage is
cause
d. The wires can be easily reconnected to solve the problem.
An acceptable failure rate


for a “Low” failure is


<

10
-
6
.

The schematic for ALF has been broken into four functional blocks: Power Supply, Audio
Circuitry, FPGA Circuitry, and Microcontroll
er circuitry. These blocks can be found in
Appendix A. Appendix B contains an FEMCA Worksheet that shows the different failure
modes possible for each functional block. It also shows possible causes, effects, and criticality
level of each failure mode.

T
here are two circuit design changes that would dramatically increase the overall safety of
the device. First, the addition of a fuse between the input power jack to the power switch to
protect from excessive and possibly dangerous current draw. Second, dio
de circuitry could be
introduced before the 5V regulator that would protect the board from input power with reversed
polarity.


5.4


Summary


This report has shown the reliability and safety analysis done on ALF’s design. Overall,
ALF is very reliable. Howe
ver, the lifetime of the components could be increased by ensuring
that the temperature coefficient,

T
, is as low as possible. ALF is also a very safe design with
ECE 477 Final Report


Spring 2009


-
20
-

only a few high criticality failures possible. Additional safety measures, the fuse and di
ode
circuitry, would significantly reduce the possibility of these high criticality failures.

ECE 477 Final Report


Spring 2009


-
21
-

6.0

Ethical and Environmental Impact Analysis


6.1

Introduction


ALF allows a user to
record

audio

using lossless compression

from a line
-
in and either store
the co
mpressed file for later playback, or decode immediately to calculate the latency of the
compression algorithm. The audio will be compressed into the Free Lossless Audio CODEC
(FLAC) format, so that performance of the Rice Encoding method can be analyzed wh
en
performed on an FPGA. The audio input and output will consist of line in and line out jacks, and
an Audio CODEC chip that handles analog and digital conversion. ALF will be able to store at
least one minute of compressed audio, which will be stored in S
DRAM; there will also be an
RS232 connection for dumping the memory for external viewing. The FPGA performs all of the
actual compression, decoding, and interfacing with the SDRAM and the left and right audio
channels via an Audio CODEC. The user will have

four pushbuttons that are accessible, one to
begin/stop recording, one to play audio currently saved in internal memory, one to change what
is currently displayed on the LCD, and one to select either to save the audio into internal memory
or immediately d
ecode the audio. There will be a small LCD to display to the user information of
interest about the audio, such as latency, size of file saved, and duration of recorded audio. All
requests by the user will be initially handled by the microcontroller, which

will then pass any
necessary information to the Field Programmable Gate Array (FPGA). In this report, the ethical
and environmental impacts are analyzed. The main ethical considerations for ALF involve
proper credit for source code and safety concerns. A
LF's environmental impact will be mostly
centered around the manufacturing of the PCB, and the disposal of the PCB and LCD. In both
the ethical and environmental anal
ysis, the IEEE Code of Ethics [16
] will act as a guide and
framework.


6.2


Ethical Impact Ana
lysis



A general structure for ethical considerations is laid out nicely in the IEEE Code of Ethics.
Although each of the ten directives of the code would apply to the design and marketing process,
numbers 3, 7, and 9 are most relevant to ALF.


N
umber three in the code is an agreement “to be honest and realistic in stating claims or
estimates based on available data”. ALF will be capable of compressing audio according to the
ECE 477 Final Report


Spring 2009


-
22
-

FLAC format and Rice compression, but it might be tempting to purport to
achieve faster
compression while secretly compromising the FLAC format. For example, one could arguably
follow the “FLAC format” by simply making each audio frame “verbatim”, thus achieving
instant encoding (but with zero compression). However, this claim
would be unethical. There is
an ethical obligation to be honest and realistic about the features of a device, and ALF would
meet this obligation by providing a comprehensive user manual.


Number seven in the Code of Ethics instructs the member to “seek
, accept, and offer honest
criticism of technical work, to acknowledge and correct errors, and to credit properly the
contributions of others”. This ethical consideration tugs at the essence of ALF, because ALF is
built on used code, both in its peripheral

interfacing and in its FLAC encoding/decoding
algorithm. FLAC source code and much of the VHDL code is under the GNU

General Public
License (GPL) [17
], and the challenge in bringing the design to market would be to follow all of
the conditions of the lice
nse. Some of terms and conditions include passing on the same
freedoms that were received, such as making source code available and not allowing patents to
restrict development of the software, and also including the GNU GPL terms. ALF would need
to includ
e an online link to the source code that was modified under the GPL license.


Number nine concerns safety: “to avoid injuring others, their property, reputation, or
employment by false or malicious action”. During ALF's design and prototyping process,
several
safety issues surfaced, and would need to be dealt with well before the marketing and
manufacturing stage. As noted in the Safety and Reliability report, two of the important circuit
redesigns would be a diode circuit to prevent wall
-
wart reverse p
olarity issues and a fuse to
prevent large and dangerous current spikes that could result in a lethal conflagration. Also,
warning labels would need to be added to reiterate the ca
utioning of the LCD datasheet [5
]: “If
the LCD panel breaks, be careful to n
ot get the liquid crystal fluid in your mouth or eyes. Do not
eat the LCD panel”. Another concern with safety would be volume control. The device would
need to be tested to insure that the audio will not be able to be loud enough to injure the user. A
fina
l safety consideration would be warnings for the users (included in the user manual) that
instruct them not to open up the device, and to let an expert handle it. Ethics demand that ALF
not only “avoid injuring others”, but also to avoid injuring the prope
rty of others. To this end,
ALF's design would need to be tested extensively with various external devices (headphones,
ECE 477 Final Report


Spring 2009


-
23
-

speakers, audio input devices) to ensure that other products would not be ruined during use of
ALF.


6.3


Environmental Impac
t Analysis



Tied closely to ethics is environmental analysis, an important part of any product design. How
will the manufacturing process or normal use affect human health and their surroundings? How
should the device be properly disposed of to reduce

environmental impact? Number one in the
IEEE code of ethics is a commitment “to accept the responsibility in making decisions consistent
with the safety health, and welfare of the public, and to disclose promptly factors that might
endanger the public or
the environment”.


ALF's environmental impact is largely due to the printed circuit board and the LCD. The
manufacturing of PCBs affects human health and the environment in a number of ways. First,
the process involves hazardous materials such as arse
nic, which is used to increase conductivity
of semiconductor material; hydrochloric acid, which is used for photoelectrochemical etching;
and lead, which is used in solder. These chemicals and materials often present serious health
risks to facility worker
s because of various waste streams, which often manifest themselves as
airborne particulates o
r industrial waste rinsewater [18
].


To address these manufacturing environmental concerns, ALFs design could use as many
RoHS (Restriction of Hazardous Subs
tances) compliant materials as possible, such as lead
-
free
solder. Unfortunately, lead
-
free solder might compromise the product lifetime because of
weaker and less effective solder joints. Another obvious way to reduce hazardous waste would
be to pack the
board components as tightly as possible and design for a smaller board. It might
not seem useful for one board, but when considering the large numbers involved in
manufacturing, small reductions would add up quickly.


Once the device is past the manufa
cturing stage, the main environmental considerations come
from the consumer's use and disposal of the product. During the “normal use” stage of its
lifecycle, ALF would consume power and could potentially have its LCD screen broken. The
power consumption c
ould be reduced by designing an efficient circuit, and also suggesting in the
user manual to unplug the device when it is not being used. The LCD screen issue could be
handled by placing a warning label on the device (as mentioned above in the ethical anal
ysis
ECE 477 Final Report


Spring 2009


-
24
-

section). ALF will be a passive “household” device and should not present substantial
environmental impact during normal use.


When the device has arrived at its deathbed, the PCB and LCD would require proper disposal,
which would be outlined in t
he user manual. Printed circuit boards can be recycled to recover
copper, nickel, tin, and lead [19
]. Gold, palladium, and silver can also sometimes be recovered,
but in much smaller quantities. The LCD also has proper disposal paths. One way to recycle an

LCD is to incinerate it to generate glass substrates, which can be used as materials for buildings
and ceramics. Also, there are methods that are being developed for recycling th
e liquid crystals
themselves. [20
] The user manual would just need to direct
the user to the proper disposal
channels.


In addition to providing channels for recycling the PCB and LCD, the user manual would also
include general instructions for how to dispose of and recycle the other parts of the product. This
would involve the

pushbuttons and the plastic enclosure.


6.4


Summary


The ethical and environmental challenges that ALF faces are fairly easily managed. The most
important ethical considerations are honesty in device claims, device safety (for both users and
their
products), and source code terms and conditions laid down by the GNU GPL. These
considerations come directly from the IEEE Code of Ethics. The first code of ethics provides the
link between ethics and the environment, and what is expected of a producer. Th
e PCB and
LCD are the main sources of environmental impact, and are an issue mostly in the
manufacturing and disposal processes. The manufacturing

impacts could be reduced by using
RoHS
-
compliant parts and by compacting the board. The proper disposal would

be clearly
outlined in the user manual, and would involve recycling of both the PCB and the LCD.



ECE 477 Final Report


Spring 2009


-
25
-

7.0

Packaging Design Considerations


7.1
Introduction

The project (hereafter referred to as ALF, which stands for
A
udio recording

L
osslessly on an
F
PGA) will
be able to receive an analog audio input, compress it into a FLAC file, and then
decompress the FLAC file for audio play
back. ALF will have a line
-
in jack

to accept analog
audio input for recording. In add
ition, there will be a line
-
out

jack to connect aud
io output to
headphones or speakers for playback. ALF should also be able to store at least one minute of
compressed audio data in the onboard SDRAM.


The user shall have an intuitive interface in the
form of pushbuttons and an LCD that will allow the user

to control the record and playback
modes as well as cycle through information to be displayed on the LCD. The device packaging
will be large enough to contain the PCB board and all necessary components, yet portable
enough to be toted.


7.2


Commercial Produc
t Packaging

Two commercial products that are similar to ALF are the Olympus LS
-
10 Linear PCM Recorder
and the Sony PCM
-
D50 Portable WAV Recorder. These two products have many features that
will be incorporated into ALF. One major difference is that the co
mmercial products are both
handheld devices while ALF will be a table
-
top device.


7.2.1

Product #1

Product #1 is a digital audio recorder, the Olympus LS
-
10. The positive features include 24
-
bit/96kHz recording, a USB interface to a PC, multiple storage formats

(WAV, MP3, WMA),
and 2 GB of internal Flash memory (as
well as SD card capabilities) [6
]. This is a strong contrast
ALF, which will include 16
-
bit/48kHz recording, FLAC format, and 16MB of internal memory.
However, the general packaging of both are very s
imilar: an LCD display, user input buttons,
mic in, and headphone out. The LS
-
10 has a broader range of user controls, to complement its
greater functionality, but ALF will be simple and adequate. One major difference is that the LS
-
10 is battery powered,
but this is unnecessary for ALF because its purpose is for testing a
compression algorithm and a portable device is unnecessary. In addition, there are onboard
speakers, which are also superfluous for ALF. The LS
-
10 is standard (for a device of its type) i
n
durability and size, two packaging considerations that ALF will attempt to copy.

ECE 477 Final Report


Spring 2009


-
26
-


7.2.2

Product #2

Product #2 is also a digital audio recorder, the Sony PCM
-
D50 Portable WAV Recorder. One
positive feature of this device is availability of multiple sampling rat
es: 22.05k
Hz, 44.1kHz,
48kHz, and 96kHz [7
]. Like the first product, a USB interface is included for connecting to a
PC.


However, there is no internal memory; the recorded audio is stored on an external flash
card.


Once again, the general packaging is ve
ry similar.


There is an LCD display, user input
buttons, mic in, and headphone out.


Because of its greater functionality, the PCM
-
D50 also has
many controls that ALF does not have.


The PCM
-
D50 is battery powered.


Like ALF, the PCM
-
D50 does not have onb
oard speakers.


The PCM
-
D50 is standard in durability and size, two
packaging considerations that ALF will attempt to copy.










Table 7.1:
Commercial Product Comparison

Item


Product #1


Product #2

Cost

$400

$600

Weight

165g

365g

Dimensions

13
1x48x22 mm

73x155x33 mm

Ports

MIC in, Line in, Line out,
USB

MIC in, Line in, Line out,
USB


7.3


Project Packaging Specifications

Based upon commercial product packaging and the PCB board Footprint for ALF, ALF is
estimated to be approx
imately 7" long by 4"

wide by 2”

high

(180mm x 100mm x 50mm)
. By
comparison to commercial products and based upon the

approximate

weights of the individual
components in the material list below, A
LF is estimated to weigh about 15

oz.


The LCD and
user interface pushbuttons are

located on the front face of the device, while the mic in, line out,
and
DC
power jacks are on the side.


A drawing of ALF can be found in Appendix A, and a table
of the packaging specifications can be found in Appendix B. The device enclosure will most
l
ikely be made out of plastic, since containers or this sort can be easily purchased from Digi
-
Key

and are non
-
conductive so as to not cause
accidental shorting of

internal
components.


ECE 477 Final Report


Spring 2009


-
27
-

7.4


PCB Footprint Layout

The foremost component of the design is the FPGA,

which will be the EP3C40. This was chosen
from among the various Cyclone III options because it has the fewest number of pins (240) and
is PQFP. An unnecessary excess of pins would only lead to an increase in soldering issues, and
the BGA packages of the
other Cyclone IIIs would be nearly impossible with the available
equipment. The other major components (SDRAM, microcontroller, and Audio CODEC) were
chosen to have surface mount packages (
TSOP, PQFP, SSOP) because a BGA could not be
soldered under our ci
rcumstances

and DIP would be larger. ALF is not very constrained in size,
but choosing the smaller SOIC and SOP packages will make the design more compact, which is
desirable.

An initial PCB footprint layout can be found in Appendix C.

7.5


Summary

It is not n
ecessary for ALF to improve upon the packaging of current commercial products;
however, ALF will mimic their small size and durability. Since ALF is intended to only record at
specific parameters, its functionality will be limited. There will be 3 ports on

ALF: 1 for DC
power in, a mic in, and a line out. Also, there will be an LCD and 3 pushbuttons. One negative
aspect of current commercial products is that the devices have numerous features and are often
difficult to learn to use. Because ALF is a simple

design, this should be easily avoidable.


ECE 477 Final Report


Spring 2009


-
28
-

8.0

Schematic Design Considerations



8.1
Introduction

ALF will be able to receive analog audio input, compress it into a FLAC file, and
subsequently decompress the FLAC file for audio playback. The audio input a
nd output will
consist of line
-
in and lineout jacks, and an Audio CODEC chip that handles analog and digital
conversion. ALF will be able to store at least 30 seconds of compressed audio, which will be
stored in SDRAM; there will also be an RS232 connectio
n for dumping the memory for external
viewing. The FPGA will do all of the audio compression and decompression internally, and will
handle all memory interfacing. Another feature of ALF is a user interface, consisting of an LCD
and three pushbuttons, for c
ontrolling the recorder and viewing relevant information. A
microcontroller will handle the pushbutton and LCD interface (via UART), and will
communicate with the FPGA through SPI.


8.2


Theory of Operation


8.2.1
Memory




The Cyclone III
[2
]

will interface

with an external 64 Mb (Megabit) SDRAM chip
[3
]
, whose
purpose is to store about half a minute of compressed audio. The FPGA is connected to the
SDRAM via a 12 bit address bus, 16 bit bidirectional data bus, and control flags. An SDRAM
module will be prog
rammed into the FPGA to handle this communication. To allow for a
memory dump onto an external computer, a UART module will be programmed into the FPGA.
The purpose of this memory dump is to verify that the compression is correct.

The UART will be
connecte
d to an RS232 transceiver through a 3.3V to 5.0V level translator.



8.2.2

Audio Input/Output


The audio path consists of a line
-
in port, ADC, compression and decompression, DAC, and line
-
out for playback. A Wolfson Audio CODEC
[4
]

drives the line
-
in and l
ine
-
out ports, and handles
all of the A/D and D/A internally, including programmable bits per sample and sample rate.

The
audio codec will be configured by the FPGA using I2C, and will transmit data to and from the
FPGA using

a left/right channel clock (96

kHz) for ADC and DAC, and a single data wire for
ECE 477 Final Report


Spring 2009


-
29
-

ADC and DAC. A separate clock, BCLK (3.125 MHz), clocks the individual bits for the ADC
and DAC data.

8.2.3

User Interface




A PIC24F microcontroller
[1
]

will be used to interface to the LCD
[5
]

and push
buttons, and
communicate with the FPGA through a 4
-
wire SPI. The PIC24F will connect to the LCD via
UART, with a 3.3V to 5V level translator in between to accommodate the 3.3V PIC output and
5.0V LCD input levels. The three active low pushbuttons will be c
onnected to the
microcontroller via digital input pin.

8.2.4
Configuration/Reset




The FPGA will be configured using a USB Blaster cable via the active serial (AS)
programming interface
[8
]
. In order to program the FPGA at startup, an EPCS16 EEPROM chip

will be used to store the code. ALF will use ICD2 to program the microcontroller. An active low
pushbutton will be used to reset the microcontroller. The microcontroller will then send an
asynchronous reset to the FPGA via a
GPIO

pin. Finally, the FPGA wi
ll reset the rest of the
components.

8.2.5
Power

Supply and Voltage Regulation


ALF

will be powered

via a wall outlet. A wall
-
wart will be used to convert the

120V AC to 9V
DC which will

power ALF via a DC power port. On the

PCB the 9V rail will be reg
ulated to 5V
using a Diodes Inc. AP1117 5V linear

regulator. The LCD and MAX233 RS
-
232 driver are both
powered by the 5V rail. A
ST LD1117 linear regulator will be used to regulate the 5V to 1.2V in
order to power the FPGA core.
A Diodes Inc. AP 1120 linea
r regulator is a dual output regulator
that will regulate the 5V to 2.5V and 3.3V. The 2.5V rail will be used to power the
microcontroller core, and will also power the analog voltage inputs of the FPGA.

8.2.6
Clock Frequencies


A clock frequency of 100 MH
z (generated by a crystal oscillator) will be used for the FPGA,
because it can not decouple a frequency faster than this

and ALF needs to perform all the linear
ECE 477 Final Report


Spring 2009


-
30
-

prediction and rice coding as fast as possible (to keep up with and outpace the audio sampling

rate of 44 kHz). If necessary, the FPGA can use one of its four PLLs to lower the clock
frequency to reduce skew between the SDRAM signals. Reducing skew is important because
during SDRAM transactions, all signals must be valid for a window of time. The S
DRAM will
be run at 50MHz.


8.3


Hardware Design Narrative

The microcontroller will use one of the two available SPI controllers. The microcontroller
will be set up to be the master controller, and this interface will be used to communicate with the
FPGA. Als
o, a UART will be used by the microcontroller to send characters to the LCD, and
three ports will have to be inputs to receive the input from active low pushbuttons. Only the
transmit line of the UART will be used since the LCD does not send information ba
ck to the
microcontroller.

On the FPGA, three main interface modules will be written; the FPGA will have
to connect to the microcontroller via SPI, will have an SDRAM module, and will use UART to
add the capability to dump information stored on SDRAM to a
computer for debugging/testing.
An advantage to using an FPGA is that pin assignment can be done for all of the inputs and
outputs; ALF will be taking full advantage of this capability for connecting to the SDRAM (for
reasons described in 2.7). Final pin a
ssignments will be determined during the layout process,
when the placement of the various chips is known. All of the SDRAM signals will be kept on
one side of the FPGA.


8.4


Summary

ALF's circuit will be designed to implement high quality audio compression a
nd
decompression in an FPGA.


ALF will be powered off a 9V DC input with a series of linear
voltage regulators that provide a stable power supply to the components.


The FPGA, providing
most of the computational power for ALF, will sit at the center of the

design. This will allow the
FPGA to interface directly to the microcontroller (user interfacing), SDRAM (compressed audio
storage), RS
-
232 driver (communicate with an external computer), and an audio CODEC chip to
provide ADC, DAC, and drive the line
-
in a
nd line
-
out ports. The microcontroller will provide
the user interfacing via pushbuttons and the LCD.

ECE 477 Final Report


Spring 2009


-
31
-

9.0
PCB Layout Design Considerations


9.1


PCB Layout Design Considerations
-

Overall



The FPGA is the main component of ALF, and thus is the centerpie
ce of the PCB. Since the
only analog signals are from
the
line
-
in/line
-
out connectors, the Audio CODEC chip should be
near the edge of the board (and near the connectors) to minimize the EMI from the analog
signa
ls [10
]. After the Audio CODEC, the quantize
d signals are passed to the FPGA for
compression. The I/O pins of the FPGA have been carefully configured to allow a direct path
from the Audio CODEC to the FPGA, allowing for some freedom when designing the PCB
layout; the Audio CODEC just needs to be pla
ced on the correct side of the FPGA.



The SDRAM is a component that places many constraints on t
he layout. Because the
SDRAM [3
] will be running at a
high frequency (
133

MHz
), and because there are 38 traces that
connect the FPGA to the SDRAM, signal
skew is a major concern; this issue can be addressed by
careful PCB layout. The SDRAM should be physically close to the FPGA, and all 38 pins should
be physically grouped together as much as possible. These two concerns can be addressed by
finding the larg
est set of unused I/O pins on one side of the FPGA. Unfortunately, there is no one
side that can accommodate the entire 38
-
pin parade. With this in mind, the key consideration will
be ensuring that the various SDRAM traces are fairly comparable in length,
to prevent signal
skew. This can be accomplished by using a corner of the FGPA and centering the SDRAM along
the same corner.


On another side of the FPGA, there will be the microcontroller, the RJ
-
11 connector for ICD2
(to program the microcontroller)

and the various components that it controls, namely the
pushbuttons and LCD. There are few PCB considerations here, given the low pin and external
component requirements for this part of the board. The remaining side of the FPGA will feature
the
100 MHz c
rystal oscillator and debugging components, such as the RS232 transceiver

and
the header for FPGA debug pins.


The sheer number of components that will connect the FPGA, and the required proximity of
these components (especially the SDRAM and the decou
pling capacitors) demonstrate the need
for a four
-
layer board. There will be a ground plane and a power plane, which will be split into
1.2V, 2.5V, 3.3V, and 5V sections, relieving the board of complicated power routing on the
ECE 477 Final Report


Spring 2009


-
32
-

surface. The 4
-
layer board wi
ll limit PCB size, which was previously unconstrained. Now, the
board will have to stay within 30 square inches because of cost constraints.

9.2


PCB Layout Design Considerations
-

Microcontroller

The microcontroller has a 0.1 uF bypass capacit
or, per the PIC2
4F datasheet [1
], and an internal
oscillator (8MHz). There are few routing concerns with the microcontroller; it runs on 3.3V
alone, and uses only 15 of its 28 pins to connect to various components. For ALF, the FPGA will
have the most considerations. The
needs for board centrality and closeness to SDRAM have
already been discussed. There will be one external crystal oscillator (100 MHz) that will be
placed as close to the FPGA as possible, to reduce the effect of the high frequency noise from the
oscillato
r, and also to preserve it from external noise.

The FPGA [2,9
] will be placed such that it will overlap the 1.2V, 2.5V, and 3.3V sections of the
power plane, because it will be using all of these voltages. The presence of the power plane
sections will make

the power trace routing local; there will simply need to be 50 mil power
traces (compared to 12 mils for normal traces) from the voltage regulators to the corresponding
power islands. The FPGA has 4 analog ground pins for the internal PLLs, and these will

brought
to the outside of the FPGA using surface traces, then connected to a zero ohm resistor, which
will go to a digital ground section in the ground plane. The other analog circuitry (for line
-
out
and line
-
in) will be grounded to a dedicated analog sec
tion of the ground plane, which will then
connect to the aforementioned zero ohm resistor. This layout will provide isolation for the analog
and digital grounds, until they are linked at one point (the zero ohm resistor).

A major PCB design consideration
for the FPGA is the large number of datasheet
-
specified
bypass capacitors. To create 1.2V and 2.5V "power islands", there will be a combination of a
ferrite bead and several parallel capacitors for each of the two levels to isolate the power from
the PLL v
oltage inputs. There will also be 28 0.1 uF capacitors for each 1.2V power/ground pair
and 14 0.1 uF capacitors for each 3.3V power/ground pair. Finally, there are 100 uF capacitors
between 3.3V supply and ground, and 1.2V supply and ground. All of these F
PGA capacitors
will be placed as close to the corresponding pins as possible, and the routing will be local
because of the 1.2V, 2.5V and 3.3V power plane sections.

ECE 477 Final Report


Spring 2009


-
33
-


9.3


PCB Layout Design Considerations
-

Power Supply


As mentioned previously, there will
be a power plane split into 1.2V, 2.5V, 3.3V, and 5V
sections, which will each require a power trace of
50 mils

on the surface from the corresponding
voltage regulator. The voltage regulators will be grouped together, with the 5V LDO supplying
the 1.2V, 2.
5V, and 3.3V LDOs, and will be placed to minimize the power trace lengths.


Several capacitors will need to be placed next the voltage regulators to charge the bypass
capacitors in the rest of the circuit. Immediately after the 5V LDO, there will be a
220 uF
capacitor, and immediately after the rest of the LDOs will be 100 uF capacitors. The larger
capacitor (220 uF) will be used because of the higher current requirement thereafter, from each
of the other regulators and from the components that use a 5V

supply. There might also be a 470
uF capacitor adjacent to the power terminals, for additional protection in case the previously
mentioned capacitors do not supply enough charge.



The ground plane will be split into various sections, to mirror the po
wer plane configuration.
There will be an analog ground section for the audio circu
itry between the Audio CODEC [4
]
and the audio jacks. The CODEC chip, which has digital and analog circuitry, will straddle the
corresponding sections of the ground plane.

9.4


Summary


The printed circuit board layout for ALF consists of an FPGA at the center of the layout. The
FPGA inte
r
faces with SDRAM, the microcontroller, and the audio CODEC all of which are
placed in close proximity. The SDRAM location of the SDRAM, in
particular, was designed
such that the traces going to the FPGA were all of comparable length, so as to prevent signal
skew. Bypass capacitors for all of the components are placed immediately next to power pins to
supply clean, steady power to the componen
ts. There are 4

layers on the board. There are top
layer and bottom layers, which

contain all of
the

components and signal traces. There are also
two inner layers, which consist of a ground plane and a power plane which is split into 1.2, 2.5,
3.3, and 5V
sections. ALF will have a separate analog ground plane to reduce noise coupling on
the digital power lines.


ECE 477 Final Report


Spring 2009


-
34
-


10.0

Software Design Considerations



10.1
Introduction

ALF allows a user to lo
sslessly
compress audio from a line
-
in and either store the
co
mpressed file for later playback, or decode immediately to calculate the latency of the
compression algorithm
. The audio will be compressed into the Free Lossless Audio CODEC
(FLAC) format, so that performance of the Rice Encoding method can be analyzed wh
en
performed on an FPGA. The user will have four pushbuttons that are accessible, one to
begin/stop recording, one to play audio currently saved in internal memory, one to change what
is currently displayed on the LCD, and one to select either to save the
audio into internal memory
or immediately decode the audio. There will be a small LCD to display to the user information of
interest about the audio, such as latency, size of file saved, and duration of recorded audio. There
will be a software reset button

available only when the box is opened (not to the user)
-

as this
will be used only for debugging. If the user wishes to reset the software, a hard reset will need to
be performed by power cycling. All requests by the user will be initially handled by the

microcontroller, which will then pass any necessary information to the Field Programmable Gate
Array (FPGA). The FPGA performs all of the actual compression, decoding, and interfacing with
the
Synchronous Dynamic Random Access Memory (SDRAM) and the left
and right audio
channels via an Audio CODEC.


10.2
Software Design Considerations

The microcontroller has a total of 64 KB of flash program memory, and 8 KB of SRAM
available for use

[1
]
. This is more than sufficient for the simple interfacing for which t
he
microcontroller will be used.


The program flash memory is addressed from 0x0002000 to
0x00AC00. Any static data, such as text to be displayed on
the LCD, can be stored here.
The
FPGA is programmed via a Serial Configuration Device at power
-
up

[2,8
]
. Th
e Serial
Configuration Device is the equivalent to the program flash memory for the FPGA and is 16 KB.
It is connected to the FPGA as shown in Figure 1.

ECE 477 Final Report


Spring 2009


-
35
-


Figure 10.1

Mapping of external interfaces
:

The following table describes the addresses of Ports/regi
sters used:

Map

Address

Description

Timer

0x0100 through 0x0120

Timer registers used to set update LCD flag

UART

0x0220 through 0x0238

Registers for UART (used for LCD)

SPI

0x0240 through 0x0268

Registers for SPI (used to communicate to FPGA)

PortB

0x0
2CA
-
0x02CB

Digital I/O pins for pushbuttons

RP0

0x06C1

Remappable Peripheral pin used to transmit data
to LCD

RP1 through
RP4

0x06C0, 0x06C2, and
0x06C3

Remappable Peripheral pins used for SPI
controller

Table 10.1

Utilization of built in peripherals:


A SPI module, UART module, and Timer will be used by ALF. An 8
-
bit SPI will be used to
communicate information between the microcontroller and the FPGA; the microcontroller will
be the master
controller. Control flags will be used to send appropriate

information to the FPGA,
such as if compressed audio should be recorded, and
to
start

or
stop recording. The

FPGA will
only need to send three different types of information to the microcontroller to be displayed on
ECE 477 Final Report


Spring 2009


-
36
-

the LCD: size of the file in SDRAM, lat
ency, and duration of audio.
Data can be sent via SPI by
one of two methods; with a fixed packet length or variable packet length
. The fixed packet length
will be easier to implement, but will set more constraints as to what data can be sent. The
variable
packet length may be a little bit more complicated, but will allow a greater range of data
to be sent. Because there are three different types of data to be passed from the FPGA to the
microcontroller, the first 2 bits sent will be needed to declare what i
s being sent. If we do a
variable packet length, then the remaining 6 bits could be used to say how many packets to
expect. For a fixed packet length implementation, the 6 remaining bits
(assuming just one
packet)
would be actual data.
Because the latency
should not vary greatly, a fixed packet length
should be sufficient, and if need be a fixed packet length of 2 (instead of 1) will be used.
The
UART module will only use the transmit signal and is what is used to control the LCD. The
Timer will be used to
get new data for the LCD every second, so that the duration of the audio
can accurately be displayed.


Overall organization:



ALF will be flag
-
driven, with flags being set in response to a button being pressed. In essence,
there are only 5 flags to che
ck, one for each pushbutton described earlier and one for the timer.
When the appropriate flag is set, information will be sent to the FPGA informing it to start/stop
recording, or to change whether or not to store the audio. When ALF is recording audio, i
t will
have to request the current average latency (calculated by the FPGA). The rationale behind using
this kind of organization is that ALF should begin/stop recording very soon after a button being
pressed, and because there are only 5 flags (and very l
ittle overhead in any given cycle) the loop
should execute quickly.

FPGA:




Because of the design of an FPGA, there are no particular ports or registers to be concerned
with. Some controllers will be available through SOPC Builder and will allow quick

progress. In
specific, an SDRAM core controller has been found and tested. The FPGA will need to have a
SPI controller, UART controller, and I2C controller. The architecture is included in Appendix
B
to show the general layout, and code is more thoroughly

discussed in section 3.

ECE 477 Final Report


Spring 2009


-
37
-

Debugging:




We have 10 GPIOs available as headers to use through the FPGA. The FPGA will also have a
UART controller solely so that we have the ability to dump the data stored in SDRAM onto the
screen. This will be used to pro
ve that the saved data is in the flac format. If need be, there are
more IO pins to be used on the FPGA, however they are currently not going to a header, so this
will be avoided. On the microcontroller side, the LCD can be used (once functional) as a
debu
gging tool, in addition to the In
-
circuit Debugger that we have available for use as well.

10.3
Software Design Narrative

10.3.1
Microcontroller

Code


Main Loop

(C code)
:



The microcontroller's main purpose is to interface with the user. Within the m
ain loop,
there is
a switch statement with code to run each different menu within each case. There are six different
menus total. Thus, there are six different case statements. They consist of the record, playback,
streaming, memory, volume, and effect men
us. Some of menus can only be accessed during
certain functions. For instance, the effects menu, can only be accessed when the audio is
streaming.

Timer Interrupts

(C code)


Cases are toggled between by hitting one of the pushbuttons. The microcontroll
er scans the
pushbuttons within one of the two timer interrupt service routines described below. If the
pushbutton is hit, the ISR sets flag corresponding to that pushbutton. There are two timer
interrupts in the microcontroller. The first is set to interr
upt every 5ms and scan the 3
pushbuttons ALF has. The other timer interrupt is set to cause an interrupt every 1 second. It is
used to increment the counter which is displayed when ALF is recording, streaming, or playing
audio.

SPI

(C code)


The micro
controller communicates with the FPGA via sending 8 bit SPI signals. The
microcontroller is the master and the FPGA is the slave. The microcontroller has 7 different
commands that it sends to the FPGA. These commands are start or stop recording, start or s