FPGA Based DSP Learning Design

Final Report
Sponsor:

Mentor:

1|Page

Digilent Inc.
1300 NE. Henley Court
Pullman, WA 99163 United States
Jack Hagemeister

Team:

Bryan Lambrecht
Gaelen McCrary
Kyle Doty
Scott Rojas

Duration:

January 10th to May 6th, 2010

Course:

EE416 Electrical Engineering Design

Instructor: P.D. Pedrow
School of EECS
Pullman, WA 99164

Table of Contents
Executive Summary..................................................................................................3
Introduction...............................................................................................................5
Project Management.................................................................................................6
Results.......................................................................................................................8
Modeling, Simulation, and Engineering Analysis..............................................9
DSP Modeling and Design.............................................................................9
Simulink HDL Coder.......................................................................................13
VHDL Environment.........................................................................................13
Scripting..........................................................................................................14
Demonstration Prototype......................................................................................16
Description of Final Design...................................................................................17
VHDL Environment..........................................................................................18
Scripting and GUI.............................................................................................20
Impact Analysis..........................................................................................................29
Conclusions................................................................................................................31
Limitations and Recommendations for Future Work.............................................32
Hardware Recommendations..........................................................................33
Software Recommendations...........................................................................33
Scripting Recommendations...........................................................................34
Acknowledgement.....................................................................................................35
References..................................................................................................................36
Appendixes.................................................................................................................38
Appendix A - Resources..................................................................................38
Appendix B - GUI User Manual........................................................................40
Appendix C - Intro to Difference equation.......................................................44.
Appendix D - Echo tutorial...............................................................................47
Appendix E - Sample Rate Conversion...........................................................50

2|Page

Executive Summary:
The project for Team Gobi was to create a learning tool to assist students learning
Digital Signal Processing, or DSP, in an academic environment. The learning tool was to
incorporate MATLAB DSP components realized in a VHDL (VHSIC hardware description
language) library, end-to-end examples of applications of DSP functions for Digilent FPGA
boards, user friendly documentation for all components, and application notes. This report
details the results of the teams research and design process to achieve these goals.
The teams first step in creating the MATLAB DSP library was to become familiar with
the Simulink environment so that the right configuration settings for the VCDL coder and the
correct blocks could be chosen. This step did not take much time and the group was able to
construct a simple system that would add an echo or change the sample rate of an audio
stream. The function was then tested in MATLAB to confirm that it was working and plotted the
output. However the team still needed to wait to construct the environment on the FPGA board
to fully test the functions and fine tune the settings. The team was also able to look at more
complex functions such as FIR and IIR filters and design several different types such as lowpass, high-pass and notch type filters.

At the same time the team was also able to complete the environment to be
implemented on the FPGA board. The environment consists of a VHDL environment that will
record a digital signal via an input device, such as an analog to digital converter or a
microphone, store it in memory, and play back the digital recording. With the basic environment
created the team simply needed to insert the modular DSP function on the output of the
environment to apply the function. This however, turned out to be easier said than done as the
team ran into some data mismatch problems and had to go back to the Simulink HDL coder to
correct the functions. With this fixed the team was able to successfully implement the simple
functions very easily. The more complex functions, such as the filters, still had some problems
which will be discussed in greater detail later in this report.

In order to streamline the process of inserting the Simulink generated code into the
FPGA environment the team decided to use a scripting program called AutoHotkey that is able
to perform complex actions within windows. The scripting portion of the project was originally
intended to automate and perform checks during the processes between DSP project
development in the Simulink environment, and programming the FPGA development board. The
3|Page

script also includes a simple Graphical User Interface (GUI) for the users to interact with and
steps the user through the process of designing, encoding and uploading with minimal
interaction with the programs that are being run behind the scene. The user only needs to know
how to use Simulink to design DSP functions, and then make 6 mouse clicks to encode and
upload the design onto the FPGA board.

The team had also created documentation to allow others to follow the steps that have
been taken in order to create the example functions and gives some background on what the
functions actually do. The team also created a brief documentation on the scripting tool and how
to use it. The documentation doesnt cover all the material that is typically covered in a DSP
class, but by itself, makes a great introduction to DSP.
The team did encounter a problem that they didnt account for when the project was
started which has hindered the potential of this project as a learning tool for DSP. The problem
started when the team began to look at designing and implementing the filters on the FPGA
board. The filters were easily designed and encoded onto the board, but resulted in a lot of
static and noise when the digital signal was played back using the filters. After trying several
different types and forms, the team decided to consult an expert and contacted a faculty
member at WSU that did not wish to be named in this report. The faculty member stated that
there is a known problem in implementing filters on FPGA chips, especially when using the
Simulink HDL encoder, in that the HDL coder is rather sloppy when encoding and the multipliers
on the FPGA chips cant carry the high precision that are necessary in order for more precise
filters to work properly .

During the project development, the team designed the system to work on the Nexys2
board produced by Digilent Inc. that is powered by the Xillinx Spartan-3E chip as it was a
relatively powerful board that didnt have big price tag, which was important when considering
that the project is to be used in an academic setting by students. However, when speaking with
the aforementioned WSU faculty member, the team was informed that a chip with more precise
multipliers would be needed to realize more complex functions, and in particular, it was
recommended that the team use a Virtex-5 based system. Digilent does make several boards
that utilize Virtex-5 chips and it would be a fairly simple process to convert the project to work on
them. Unfortunately the starting price on these boards is $449 with an academic only discount
and $995 otherwise, which isnt a realistic price for students to pay for one DSP class in addition
4|Page

to tuition and books. But the team made an effort to design the scripting tool in a way that it
could be used on different boards and it would be fairly simple to add new boards. The team
even included a drop down list in the GUI that allows the user to select different boards to build
their project for.

In conclusion The MATLAB DSP library project does work with simple DSP functions but
is still falling short of its maximum potential. The learning tool is functional and extremely simple
to use, however, as a learning tool, the use would be very limited in a DSP course as it currently
stands. To fully realize the potential of this project in as a reasonable tool for students, Digilent
would have to create an extremely precise FPGA board that isnt so expensive that college
students cant afford it.

Figure 1: Team Gobi working on final design.

Introduction:
This project was designed and brought to prototype by Bryan Lambrecht, Scott Rojas,
Gaelen McCrary and Kyle Doty. The purpose of this design was to create a learning and
demonstration tool set for use in Digital Signal Processing. It was the goal of the project to
5|Page

create a final project which, once completed, would allow users to create DSP functions and
designs in a user friendly environment, without a dependence on users having a previous
understanding of the VHDL design language. As the following report will demonstrate this was
done by creating a bridge, linking the user friendly Simulink environment to be used for DSP
development, to the hardware testing environment offered by an FPGA board. This bridge
utilizes existing, free, programs linked together using scripting that will only require 6 button
clicks from the user to implement their DSP functions. An important aspect of our final product is
that the DSP library associated with our project will continue to expand through user generated
DSP functions. As a result of this it is likely that our final design will require modifications to
meet new user requirements from the automation process and associated filed.

This report covers the work done on this project during the spring of 2011. It is presented
in a compartmentalized approach with each section covering a different piece of subject matter.
The first section is the Project Management section, which covers the timeline, responsibilities
of the team members, and handling important deadlines and how they would be met. Following
that is the Results section, which is broken down into four subsections including Modeling and
Engineering Analysis, Demonstration of Prototype, Description of Final Design, and Impact
Analysis. This section covers the use of technical engineering analysis and details, covering
how the design works, what was used to generate it, and what the final product does in detail.
The Conclusions section the report will briefly summarize previous sections and state the
teams important conclusions regarding the project. Finally, the Limitations and
Recommendations for Future Work sections addresses the teams recommendations for how
the project could be continued if further resources are put into it.

Project Management:
The team used several methods to manage the project and meet the deadlines. To
organize and simplify what needed to be done, the main tasks were broken into three different
sections, each with subsections defining the various sub-problems being solved. These main
sections were the Simulink DSP Library, the FPGA environment, and the software automation
linking the Simulink HDL coder to the Adept software. Each of these main sections had several
sub tasks associated with them. The progress of each of the main sections was defined by the
progress and completion of their corresponding sub tasks.

6|Page

Each group member worked independently on a section of the project to utilize their
particular skill sets. To ensure that during the development of these sections members
remained up-to-date on the expectations or assumptions of other members, weekly meetings
were held at the project teams headquarters for a general discussion and problem solving
session. This methodology helped to showcase each members progress to the rest of the team,
allowing members to receive help if they were falling behind on their section, and allowing team
members to offer solutions to problems faced by the others. If a problems to which the team
could not develop a solution, meetings with various professor and other experts were held so
that their experience could be utilized for the project. On a few occasions these meetings both
defined the project and helped reveal major holes in the design process which required the
utilization of contingency plans. An example of this was the data type issue between the HDL
coder and the VHDL environment.

Throughout the process of design two contingency plans were put into play. The first
plan dealt with a precision issue which arose when the high precision filters from the DSP library
were placed into the FPGA board. The second plan was put into play when different members
were forced to miss group meetings and when scheduling conflicts prevented members from
meeting in person to collaborate on work. The solution to this plan involved utilizing online tools
to remotely collaborate on work and provide feedback to others.

Several tools were utilized by the group to keep the progress at an acceptable pace.
One of the most vital tools was Google Documents, which was used to upload and collaborate
on files for the project, even when physical meetings were not possible. This was especially
useful for the documentation and testing section of the design prototyping as it allowed the
entire team to simultaneously edit the same document, removing the need for version control.

The following Gantt chart shows the breakdown on a timeline of the project progression
and section ordering. The first section, DSP Examples Library, is shown in blue and displays the
steps that were processed in generating working DSP functions. The second is Software linking,
shown in green shows the steps to creating different parts of the scripting algorithms. As a subsection of each portion was completed it allowed the project team to report on the current status
of each section during weekly meetings.

7|Page

Figure 2: Gantt chart demonstrating the teams project timeline.

Results:
The following sections demonstrate the final product and technical information pertaining
to our project. The first section, Modeling, Simulation, and Engineering Analysis, demonstrates
the development of each portion of the project and the theories applied to bring it together. Next
the Demonstration Prototype section described the system that was prepared and setup for
8|Page

review at the EECS poster session. Finally the Description of Final Design discusses the Final
design of our project in great detail. The DSP section for the Final Design section was excluded
mainly as it was discussed instead in appendix C though E in the form of tutorials and sample
modules.

Modeling, Simulation, and Engineering Analysis

Simulink DSP Environment:

The first task of creating the MATLAB and Simulink based library was to generate test
functions in Simulink and verify that the correct blocks and settings are being chosen. The first
test was a basic Direct from I model that is shown below in Figure 3. This system is one of the
most basic DSP models that can be made, and was one of the first models that some of the
team members created in their DSP class. The basics of what this function does is adding a
scaled, time delayed version of the input to the output, essentially adding an echo to the input
signal.
Figure 3: Direct Form I Echo Generator

In order to test the function the group modified the block diagram to add a test sine wave
to the input, then modeled the signal in the MATLAB workspace to that the group could plot the
input vs. the output. The results of the simulation can be seen below in Figure 4. This process
was used for initial function testing as the VHDL environment had not yet been fully created,
and this proved to be a simple and effective way of verifying the results of a filter.

9|Page

Figure 4: Direct Form I Simulation

Figure 5: Simulation Results

10 | P a g e

As can be seen from Figure 5, the input is a standard sine wave of amplitude 1 and
continues for a duration of 100 samples. The output can be observed to be amplified magnitude
of the input and delayed by about 90 degrees. This confirms that the output does have the
desired general effect of an echo function from the chosen model, although the echo is louder
than our input signal. This however is due to the gain values chosen and can be changed to
achieve a more normal occurring echo. After the FPGA environment was created the team had
to configure the HDL encoder to select the proper data types for the filter blocks created in
Simulink. This process took some trial and error but eventually a good configuration was found
that allowed the blocks to be initialized so that they would use integers to properly store the data
values sent from the analog to digital converters.

Once the team had the data type problem solved and a working FPGA environment, the
simple functions that had been constructed earlier were testing in the environment. The results
were perfect; the team was able to implement a basic echo function and a down sampler. Using
the echo generator, the team was able to record a voice on the FPGA boards on-board
memory, and then play it back through the echo filter, resulting in a perfect echoed version of
the recorded signal. The down sampler took the number of samples, reduced the output
samples and interpolated the bits to make it smoother. However the output signal still contained
more white noise than if it wasnt down sampled, but this is to be expected from a down
sampler, as the signal will have inherently less data transmitted, and therefore a lesser quality
signal.

The next step was to start creating more complex functions. The team decided to try and
focus on designing some high and low pass type filters for more complex functions. A first
attempt was at designing an IIR low pass filter as it would have the fastest response while
having a low order. Using a tool in MATLAB called filter builder, which allows the user to set
certain constraints of the filter, such as poles, type and band pass requirements, the team was
able to quickly get filter parameters with great precision. This tool turned out to be extremely
helpful in designing the filters for the project as it could export the designed filter directly into
Simulink using basic blocks. Unfortunately when these filters were implemented in the range of
audible voices, the result was a large amount of static that drowned out the barely audible voice
the filter was applied to. The team tried several different approaches to try and fix the problem,
including using FIR filters, limiting and maximizing poles, increasing transition bands, but
nothing seemed to work.
11 | P a g e

Figure 6: Direct Form II IIR System

At this point the team decided to seek outside help, and scheduled a meeting with a
faculty member that was recommended to us by Dr. Pedrow as an expert in the field of FPGAs.
The field expert did not wish to have his name mentioned in this paper. After meeting with the
expert, the team learned that there are known problems with implementing filters on FPGAs,
due to their multiplier blocks not having a high enough precision. The team also learned that
the chip-set being used, the Spartan 3E, is known to have lower precision than what this project
would need to implement filters on them. The expert also informed that team that it might be a
possibility on a more power full FPGA, and recommended the Virtex 5 from Xilinx. The team
decided to look into the Virtex 5 as Digilent Inc. does make some FPGA project boards that
utilize it. However, the boards cost far more than could expected of a college student to spend
on a supplemental educational tool. At this point the team decided to stick with some of the
simpler functions as a proof of concept, and allow Digilent Inc. to decide if they would like to
further expand the project to a more powerful FPGA. With this in mind the project design was
modified somewhat to make it more modular so that it can easily be expanded to support other
boards.

12 | P a g e

Simulink HDL Coder:

Overall, the HDL coder that is included in the Simulink environment isnt very flexible, but
it isnt a horrible tool either. For simple Simulink blocks it works decently, but still is kind of
wonky to get used to. One particular quirk is that delay blocks get converted to flip-flops, like
might be expected with FPGA resources, which results in very long compile times, but the delay
does work efficiently. Other attributes of the HDL coder is that gain blocks are converted to a
signal multiplied by a constant, and summing blocks just add two data signals together. Overall
the HDL coder wasnt too bad to use, in that it was unusable by us, but it still could use some
improvements to add some coding constraints.

VHDL environment:
When designing the VHDL environment the first step was to define the environment
specifications and requirements. One requirement on the system was the design of an alterable
function block in which the HDL coders generated file could be embedded. Another requirement
was to meet the teams preference for an audio I/O system, and as such a block would be
required to accommodate A/D and D/A peripheral modules. In order to test the filters from
Simulink, the environment also needed a signal to filter. It was also decided that it would be a
good idea to store the input data so that users could record then play back a recorded signal. In
order to accomplish this, a block was needed to get the data from the microphone or A/D
converter Pmod. For testing purposes the team decided to use the microphone Pmod as it
allowed the team to record a signal and play it back through a speaker to hear the differences.
By applying the filters to a voice the effects of the filter would be obvious simply by listening as it
was played back. Digilents public website had pre-designed code for extracting data from the
microphone Pmod that met the teams requirements, so this was implemented in the
environment. The next step was to find a way to output the voice data. One common way of
doing this is to implement a pulse width modulation (PWM) design. After that was written, Xilinx
synthesizer was used to program it to the test board to verify that everything is working properly.
Next the memory controller and button controller were programmed to allow audio to be
recorded to the on-board RAM chip. In the process of this design pieces of debugging arose
due to the requirements from the different peripheral devices and the design preferences used
to create the environment connecting incorrectly.

13 | P a g e

Figure 7: VHDL Environment Flowchart

Scripting:
When developing the script that automates the project compilation, building and
programming process, one of the most useful tools was developing an overall flow chart to
analyze the script with. In the first iteration of design development, a separate script was made
for each part of the development process, and each of these scripts were called by an overall
script. Once a framework was in place and each of the smaller scripts was being integrated into
an overall script a problem occurred in the integration of each of the smaller parts, so a flow
chart was developed that included error checking done by the script. This analysis tool allowed
the team to determine weak points in the error checks and direct information flow between
subsections.

14 | P a g e

Figure 8: scripting flowchart

During the development of the smaller scripts for each of the subsections it was
necessary to extract certain information about each of the intermediate programs that would be
used in the project, and their control windows. In order to do this, a basic information extraction
script was written that could be used on any active window. This analysis tool extracted
information such as a windows title and class, how many controls existed in the window and
what their names were. Once control information was collected for a certain window a second
information extraction script was used to step through the controls and determine what type of
control they were and what sort of information the control contained and could be altered. As
15 | P a g e

the scripts extracted information it was dumped to a text file that could then be used as a
reference for the rest of the scripting.
Demonstration Prototype:
Displayed at the WSU EECS poster session, the teams prototype demonstrated a
possible design which the project could be based upon. The physical setup for the prototype
included a laptop, running Simulink and installed with all the required programs and the script,
was set up and connected to a Digilent Inc. Nexys2 board. The Nexys2 board had two Digilent
Pmods attached, a PmodMIC and a PmodAMP1. The PmodMIC and PmodAMP1 are A/D and
D/A converters, respectively, and act as the physical I/O devices for the prototype. The
PmodAmp1 possesses two headphone jacks, one of which, for the prototype demonstration,
was connected to a speaker.

Using the software portion of the prototype, the demonstration allowed users to open a
list of different DSP functions that the team had designed, such as the one shown below in
Figure 9, and if desired change values to meet their specifications. Potentially a user could
have generated their own DSP function in the Simulink environment and then continued
Figure 9: Simulink Program Example

16 | P a g e

The process began with the script, compiled into an executable program, being run. The
user was able to use the GUI generated by the script to open an existing project, or create a
new one. After a valid DSP project was opened, the user was able to interact with the GUI to
progress the DSP project through the steps of generating the necessary HDL code, compiling
and building the project, and programming the Nexsy2 board. To the user, what becomes
visible is a progress bar and several buttons the user is to click in order to direct the scripting to
move onto the next step, once it has completed its current tasks. This process ends with the
user being prompted to load the file created to the FPGA board using the opened Adept
window. In the background far more was occurring. The script took the DSP example open and
begins its first compile by calling the Simulink HDL Coder to generate a VHDL file from the
DSP function. This scripting then takes the VHDL files and embeds it into the developed VHDL
environment to generate the compiled VHDL file using Xilinx. Finally it prepared the file in Adept
for the user to load.
Figure 10: GUI Scripting Progress

Once loaded the user was then able to record and play audio using the Nexys2 built in
buttons. A switch could be used to turn DSP filter on or off so that its effects on the audio could
be heard. If a new DSP was to be tested, the process could simply be restarted and once the
new file is uploaded it would overwrite the old DSP filter while preserving the environment
functions such as the button control and the on-board display.

Description of Final Design:

Following the poster session the prototype received input from the ideas given by
peers and the technical community present, as well as further research. As a result
modifications were made to the project as well as new recommendations for future work to
expand the project. It was decided that for this section the DSP examples would be excluded
and instead will be referred in Appendix C though E for the DSP tutorials and documentation.

17 | P a g e

VHDL Environment:
The team had created the FPGA environment for the DSP function to be inserted into.
This environment was built in Xilinx ISE WebPACK, which is the free version of the software
from Xilinx, which can be used to design VHDL projects. The project can then be synthesized
and converted into a bit file that can be used to program one of the many Xilinx FPGA chips. In
order to get the sound from the microphone Pmod, which was used to capture the users voice,
a block was designed to transform the serial input from the microphone Pmod into a parallel
signal. The next segment to be designed was a memory controller state machine to store the
sound data from the microphone so that it can be played back whenever the user wants. This
block takes the data coming from the microphone Pmod and stores it to the build in RAM chip
on the Nexys2 board specifically, but could work on any board with a RAM chip.

The next step was to create a controller to tell the memory controller when to record data
and when to play data depending on what buttons are pushed. The controller was designed to
give the user 4 buttons: record, stop, play and reset. Once the user presses record, the board
will keep recording data until stop is pressed. Once the user presses play, the board will keep
on playing the recorded data until stop is pressed. A counter to display how many seconds of
audio has been recorded was also designed. Whenever a record signal is being sent to the
memory controller, it would also send a count enable signal to a special 16 bit counter. The
counter is made up of four 4-bit counters that overflow at 10 rather than 16 so that each counter
is a single digit for a decimal number. The 16 bit counter gets sent to a seven segment display
encoder that displays the value of the counter on the built in seven segment display.

The team then developed a pulse width modulation (PWM) block to convert the data
from the memory controller to an analog form. Pulse width modulation works by outputting a
signal that is high for a period of time, then low for a period of time, then sending the resulting
signal through low pass filter to smooth the signal. The ratio between the amount of time high
versus low will average out to an analog signal rather than a digital number. After the team got
this to work without a filter, it was decided to put the Simulink block in between the output of the
memory controller and the PWM block. This would allow the filter to be applied to signals that
are played from memory rather than just recorded from the microphone Pmod. The team also
added a two input mux controlled by one of the switches. The two inputs are the filtered and
unfiltered signals. This would allow the user to switch the output between the filtered and
unfiltered signals in order to compare the differences.
18 | P a g e

Figure 11: VHDL Controllers

Figure 12: Block Diagram of VHDL Environment

19 | P a g e

Script and GUI:

The initial script design was to create an overarching script that called other scripts for
each section of the project development process. Since then the design has been modified to a
single script with subsections, which are similar to functions.

File Management:
The script has been developed to manage project and system files in a very specific and
standardized way. The files needed for the script need to be stored in folders in the
same directory as the script program and are stored in two folders; the environment
folder and the system folder. The environment folder contains all the VHDL and other
files needed by Xilinx to compile the finished project, and the system folder contains the
sys.ini file, which stores program paths and other folder information, and the simconfig.m
file that gets copied to a project folder when a new project is made.

20 | P a g e

Figure 13: File Structure for Scripting Program

In each project folder there are a series of files with standard names. Each file has a
project.ini file that keeps track of project attributes and timestamps for each process
through the project development process. The project folder also includes a simconfig.m
file which is copied over when a new project is created. This file is the MATLAB script
that is run for configuring the user development environment. As the project is
developed more files are added to the project file, including the generated dsp_filter.vhdl
and dsp_filter.bit files, and the environment files.

21 | P a g e

Figure 14: File Structure for Standard Project

GUI
The functionality of the script operates behind a GUI that was designed to simplify the
project creation process as much as possible, and to help guide the user through the
necessary steps. The GUI itself was created in Auto Hotkey using built in functions (also
on the Auto Hotkey website is a software tool called SmartGUI Creator which can
simplify the GUI creation process) and is a simple Windows environment window with
the title bar hidden. The main body of the GUI uses the Windows environment built-in
control types, all of which can be created, configured and modified using Auto Hotkey,
such as buttons, text boxes, and drop down lists. The main body is also divided into 5
main subsections with each subsection dependant on the subsequent sections, except
for the 5th section, the Exit button. In addition, each control has an associated tooltip
that appears if the mouse pointer is hovered over a control for a short period of time.
These tooltips contain basic information about what each control does and are based off
an Auto Hotkey project developed by Micahs and can be found on the Auto Hotkey
forums. The original functions, as developed by Micahs, have been included in the
script to utilize the tooltips. Another feature added to the project to make it more intuitive
and user friendly is that button are disabled until certain prerequisites are met, then they
are enabled. When the GUI is initially launched, only the New, Open, Set Xilinx path,
22 | P a g e

and Exit buttons are enabled by default (see the following sections to see details about
when buttons are enabled).
Figure 15 - GUI and Subsection Outline

Section 1:
The first subsection of the GUI contains three buttons and a progress bar. The
first button creates a new project and is one of only three buttons that are always
enabled. When the user selects the new button a standard Windows environment folder
selection window opens and the user can select a base folder to use for a new project,
or create a new folder. Once a selection has been made and the user clicks ok, the
folder is checked for a project.ini file, one of the first files created when making a new
project. If the folder contains a project.ini file the script assumes a project already exists
in this folder and informs the user that the selected folder is invalid and they are
presented with the choice to cancel the folder selection process or reopen the folder
selection window. Once a valid folder selection is made the project development
environment is set up and organized for the user (see Progress Bar paragraph below for
development environment setup details).
The second button is the Open button, which is also the second button thats
always enabled, and works much the same way the new button does. If the Open
button is clicked a Windows environment folder selection window is opened, this time
without the option to create a new folder, and the user is prompted to select a folder that
contains a valid project. Once a folder is selected it is, like with the New button, checked
for a project.ini file, but in this case if the project.ini file does not exist the user is
informed of an invalid folder selection and the choice to choose a new folder or quit the
folder selection process is offered to the user. Once a valid folder selection is made the
project development environment is set up and organized for the user (see Progress Bar
paragraph below for development environment setup details).

The third button is the Save button and is enabled once a project is open. This
button is somewhat redundant as the intermediate programs will themselves prompt the

23 | P a g e

user to save their files, but when the save button is clicked project.ini is updated for the
current project, save commands are sent to any open intermediate programs, and
unnecessary files are deleted. A project can be built, compiled, programmed to the
board and closed without using the Save button and without losing and data pertinent to
the project, but as the project expands other scripting functions may be added to the
Save button that may make it more necessary.

The final control in this subsection of the GUI is the progress bar. When the GUI
is initially launched the progress bar is at zero, but as the script moves through the New,
Open or Save project process the progress bar is updated. For the Save project
process the progress bar updates as the project.ini file is updated, subsequent programs
save their corresponding project files, and unnecessary files are deleted. For the New
and Open project processes the progress bar updates as a valid folder is selected and
the project development environment is set up. Once a valid folder has been selected
the script launched MATLAB in server mode (as a command console) and waits for the
MATLAB window to be ready to accept input, then prompt the MATLAB environment to
run a .m file MATLAB script. The choice to have MATLAB run its own script to configure
the development environment was made because MATLAB uses its own GUI windows
management, and it proved to be extremely difficult to get the script to interact directly
with MATLAB window controls. By using a MATLAB .m file script it allows the MATLAB
environment to handle its own defined protocols for opening the Simulink development
window and the Simulink Library window. While MATLAB executes its script the original
script monitors its progress and updates the progress bar accordingly. Once the
MATLAB script has been successfully executed the original script takes over completely
again and modifies the Simulink workspace window and the Simulink Library window to
fit side by side on the screen and beneath the GUI.

24 | P a g e

Figure 16 - Project Development Environment Layout

Section 2:
This small subsection of the GUI contains only a single button and a progress
bar. The button is the Generate HDL button and is enabled once a project has been
opened, at the same time that the Save button from the previous subsection is enabled.
When the button is clicked a command is sent to the MATLAB console to use the
Simulink HDL coder to generate a VHDL file using MATLABs built in makehdl() function.
Among the parameters passed to the function is the file language type, in this case
VHDL, and the working directory of the current project. This is accomplished by using
AutoHotkeys sendInput function, which emulates an un-interpretable string of characters
to the corresponding control, essentially typing and executing a command defined in the
script into the MATLAB console. Once the process has finished the project folder is
checked to make sure that a valid dsp_filter.vhdl file exists, indicating the process has
completed successfully, then the Compile Project button is activated.

The other control in this subsection of the GUI is the progress bar for generating
the dsp_filter.vhdl file. This progress bar is much less accurate than the one in the
previous subsection due to the difficulty encountered in reading information from
MATLABs windows controls. The initial progress is shown by monitoring the status bar,
25 | P a g e

one of the few controls with accessible information, of the Simulink project window.
Once the status bar has changed from the default Ready state, the progress bar
increments at a steady rate with a max cap at 80%. The status bar continues to be
monitored until it again displays the Ready status, indicating that Simulink has finished
the HDL coding process. Once this flag occurs the cap on the progress bar is raised
and it continues to increment as MATLAB takes over for the HDL coder and begins to
actually generate the file. On the standard school computers this progress bar proved to
be relatively accurate, but on slower systems it would hang at the caps for a significant
time. With more research it may be possible to develop a better monitoring system for
this process to provide a more accurate progress bar.

Section 3:
The next subsection of the GUI is the largest both in terms of the number of
controls and the scripting that occurs behind the GUI. The subsection is divided into
three rows with the Set Xilinx Path button on top next to a text display of the path. On
the second row are two dropdown lists that allow the user to select which FPGA chipset
they are building their project for, and which clock they want the program file to use. To
the left of row 1 and 2 is the Compile Project button, and beneath everything else,
stretching the entire width of the subsection is a progress bar.

The Set Xilinx Path button and the Xilinx path text were added because when the
Xilinx toolsuite is installed it doesnt add its path to the Windows environment %PATH%
variable, so a system call to Windows to run one of the Xilinx tools doesnt work. The
default path is set to C:\Xilinix, which is the default installation directory when Xilinx is
installed, but in case it cant be found the user must select the root Xilinx path. Like New
and Open a folder selection window is opened and the user can select the correct
directory. When the Compile Project button is clicked the script checks the defined
Xilinx directory for the settings32.bat file, used to define the functions available to
cmd.exe, the standard Windows environment command console, which is needed for the
environment and filter compilation process. Once a valid folder has been selected, the
folders path is stored in the system.ini file for later use. The button is initially enabled
but if the Compile Project process is run and settings32.bat is found successfully in the
specified path the control is disabled until the Compile Project process is run again and

26 | P a g e

the settings32.bat file is not found. This could occur if the Xilinx tool suite is upgraded or
reinstalled to a different directory.

To the right of the Set Xilinx Path button is a line of text that shows the full
system path to the Xilinx folder. The text is updated if the path is changed, but otherwise
serves no purpose to the operation of the script.

On the second row is the first drop down list used to select the chipset being
used for the project. Currently only one option is in the list as the team only had access
to a single board for development testing, however it would be quite simple to add other
options to the list, and as the list is tied to a variable that can be monitored some simple
checks on the variable are used to define the parameters of the function calls made
during the Compile Project process.

The other drop down list only contains two options; JTAG and CCLK. These
choices correspond to the system clock to be used for the final project, which dictates
which portion of the project boards memory is programmed during the Program Board
process. The team was unfortunately unable to determine the exact parameter that is
necessary during the Compile Project process to produce the different programming
files, but the Compile Project process has been observed enough times through the
Xilinx tool suite to say conclusively that the parameter is defined in the final command.
More research into the functions used by compilation process needs to be done to
determine the exact parameter, but like the other drop down list this one is tied to a
variable that can be monitored to specify the necessary parameters.

The other button is the Compile Project button that, when clicked, makes calls to
the Xilinx command console to compile the project into a file that can be used to
program the FPGA board. The button begins disabled when the GUI is first launched,
but once a project is opened the project directory is checked for a valid dsp_filter.vhdl file
(generated in the previous subsection) which indicates that the Generate HDL process
has already been run on this project, and if it is the button is enabled. Otherwise it is
enabled at the end of the first successful completing of the Generate HDL process. The
first thing this process does when it begins is to check the Xilinx path that is currently
specified. If settings32.bat isnt found the user is informed and the process exits. If
27 | P a g e

settings32.bat is found the Set Xilinx Path button is disabled and the compilation begins.
First all the necessary environment files are copied from the system folder into the
current project directory, and then the first call is made to the Xilinx command console.
The Xilinx command console actually uses the cmd.exe shell, but with its own function
definitions found in settings32.bat. In order to make the command calls cmd.exe is
called along with a CD command to change to the project directory, a .bat parameter
defined by the file path to settings32.bat, and the function calls and parameters needed
for each command call. The first call synthesizes the project, the second and third
translate the synthesis into a hardware definition, the fourth maps the system resources,
the fifth places and routes the project blocks, the sixth runs a timing sequence to make
sure all the time constraints are met, and the seventh generates the dsp_filter.bit file
which is used to program the board. In a general sense the dsp_filter.vhdl file from the
Generate HDL process is inserted into the dsp_filter block in the environment, and then
the whole environment is compiled and built into a dsp_filter.bit file. Once the process is
complete, the project folder is checked for the dsp_filter.bit file, and if it exists, indicating
the process completed successfully, the Program Board button is enabled.
The final control in this GUI subsection is the progress bar. This progress bar
follows the process of compiling and building the dsp_filter.bit file used to program the
board. The first progress update is shown in the bar when the necessary environment
files are copied to the project directory. The next several updates occur as each of the
console command calls to Xilinx finish. Unfortunately the output of the command
console proved to be quite difficult to monitor with the script, so the progress bar moves
in chunks that are comparable to the percentage of the overall progress each command
call represents.

Section 4:
This is another small subsection of the GUI, containing only a single button and
progress bar. The button is the Program Board button, and like most of the buttons is
disabled when the GUI is initially opened. Once a project is opened, the folder is
scanned for a valid dsp_filter.bit file, and if found the Program Board button is enabled.
If the file does not exist, the button is enabled at the end of a successful completion of
the Compile Project process. When this button is clicked, the script checks to see
Digilent Inc.s Adept software is open. If it is, the Adept window is activated, bringing it
28 | P a g e

into focus, otherwise Adept is opened and activated. Unfortunately the Adept software
also proved to be somewhat difficult to interact with, but once the software is open and
the user clicks the button to select a file to program the board with, the dsp_filter.bit file
in the current project directory is automatically selected.

The progress bar is somewhat redundant, as the Adept software contains its own
progress bar. In addition there are very few significant points during the programming
process that can be used to update the progress. A new monitoring system needs to be
implemented in order to increase the accuracy of the progress bar.

Section 5:
The Exit button is the third and final button that is always enabled for user use.
When the Exit button is pressed, shutdown signals are sent to any open intermediate
software. Because it is a shutdown rather than a kill signal, each program runs through
its standard shutdown sequence, which usually involves prompting the user to save any
unsaved work. The GUI is then destroyed and the script exits.

Impact Analysis:

One of the important aspects during the engineering design process is an analysis of
project impacts. The team analyzed a variety of different aspects of the project, and its potential
to affect the different stakeholders upon completion. The main stakeholders that were identified
for this project are the students and other members of academia that would use this tool, the
schools that decide to implement this tool, and of course Diligent Inc.

The first thing considered was the affect on both a local and global economy. As the
economy has its ups and downs, students continue to enter the job market. Students entering
the job market that have made use of the teams learning tool for DSP would have more hands
on experience with designing DSP functions, such as filters to remove noise, than other
students that didnt have access to the teams learning tool. As a result students that
supplemented their education could be more valuable to companies as they could potentially
integrate themselves into DSP application than if they have not had the hands on experience.

29 | P a g e

This would benefit the students, the schools using the educational tool, and of course Digilent
Inc. itself.

However, it was also considered that the jobs these students will pursue could be
outsourced by students who learned from our tools and offer their services for a lower price. If
our tools were used so that students who wouldnt have otherwise learned and applied our
theories gain access to them through Digilents internet tools it would be possible for those new
students companies to compete for those jobs, or contracts, with offers of cheaper research
and development costs. As a result jobs could become outsources to other countries with
talented engineers hungry for jobs with engineers in the source location, Pullman for example.

One of the most exciting aspects of the groups project is the potential is has to bringing
a hands on tool to digital signal processing education. Up to this point, as several of our team
members can attest to, DSP education has involved a lot of lecturing with most of the
experience gained from solving equations on paper, or using software simulations. The
completion of this project represents a physical tool that students will be able to utilize at
relatively low cost. While the teams product would require access to some fairly expensive
software, in this case MATLAB, many universities and colleges have local computer labs that
would contain this software available for the use of the students. Other pieces of software
necessary for the finished product to work correctly are the Xilinx development tools, and
Digilent's Adept software for programming the FPGA boards. The Adept software can be
downloaded for free from the Digilent Inc. website, and as for the Xilinx development software,
the team has made an effort to ensure that the project will work with the free WebPACK tools
that Xilinx offers. This means that given access to MATLAB through school resources, for only
the price of an FPGA board, students in DSP classes could utilize a tool that would allow them
to physically experience the results of their efforts. Having access to this product would go a
long ways towards increasing the understanding and conceptualization for students in the DSP
field.

Expanding this from the local to the global, we see a different problem. Looking at the
countries and surrounding regions which receive these new jobs different consequences could
be seen. One impact could be that the developing country suddenly boom economically, which
with all economic booms could create positive, new jobs and increased quality of life, or
negative, crime rates or corruption, changes to the society. Another potential impact could be a
30 | P a g e

current event. With the rise in revolution and political turmoil in regions in and around the Middle
East if a country in the region received these new jobs and economic boom it could cause a
mass movement of people. Fleeing groups from their politically upset countries could view this
growing and fruitful location as a good place to settle for work and stability. The result of such a
thing would create a wave of various effects on the native population of the boom country(s).

Another concern was an environmental concern about the increase in demand of these
boards will create more waste from the boards and the manufacturing of the boards. While we
have found that the Digilent boards are ROHS compliant and use lead free solder and
components, they still need to be disposed of properly and cannot simply be thrown out. This
technological waste has been given the name of tech waste, as it has started to become a
problem since the explosion of cheap computers and electronics. The production of the circuit
boards themselves requires harsh chemicals that if not handled properly, could cause serious
damage to the environment. A strategy that we have seen many large companies do to keep up
with demand is to contract out the fabrication of these boards to other companies in other
countries, which is also cheaper. The problem with this is that these factories often have less
safety standards both for the worker and for the environment.
Conclusion:

In conclusion, the DSP Library project has met great success in some aspects but
require more research in others to fully realize the potential of this project. In order to fully
analyze the outcome of this project, it is easier to break it into several major components. The
major components that make up this project are; DSP design in Simulink & HDL coder, the
VHDL environment and the automation of the process via the scripting tool.

While using the Simulink environment, we found it extremely simple to realize DSP
functions in direct form. While it did take some time to design some of the more advanced
functions such as filters, we were able to create them with some effort.

The VHDL environment was designed around the Nexys2 board and was intended to be
a sandbox environment for the DSP functions to be loaded in. However when we tried to
upload more complex functions such as FIR and IIR filters we could hear the audio being played
back but was almost overpowered by noise. We consulted with an expert in the field of FPGAs
31 | P a g e

that wished to not be mentioned, and told us that the chipset would not work for high precision
functions. Knowing this, our simple functions that dont require much precision from our
multipliers do work, but more advanced functions will not be able to be realized on the Nexys2
board.

The scripting tool was where we feel our project really made huge strides for the use
ability of our project. The scripting tool has many features that streamlines the process of
designing DSP functions in Simulink, encoding them, and uploading it to the FPGA board
without having to do any complex actions, other than designing the functions of course. The
team wanted to make sure the experience needed only knowledge of Simulink and DSP so that
the user could focus on learning the material at hand and not learning the intricacies of the
VHDL language or any of the intermediate software. The results was that a user could
implement a DSP function in 6 simple guided mouse clicks and would not require the Xilinx
software or the programmer tool to be opened (other than in command line calls).

To summarize, the team was able to successfully construct and code DSP functions with
relative ease in a Simulink environment. The team encountered some success with
implementing these functions onto the FPGA board, but is currently limited to simple functions
that do not require high precision multiplication. In addition, the team had extreme success with
the scripting tool to streamline the process of implementing the functions onto the board. Over
all the team feels it was fairly successful in this project but further work could be done to allow
more advanced functions to be implemented.

Limitations and Recommendations for Future Work:

If Digilent chooses to continue to invest in this project or a new senior design team
decides to expand upon the existing work, team Gobi has a list of recommendations for them to
go off of. The recommendations fall under three categories, hardware, scripting, and software,
recommendations.
Within each category there is room to improve in different ways which will be discussed.
The most important improvements that could be made would be solving existing problems within
the final design; however we have also considered improvements that could be made based off
a finished project.

32 | P a g e

Hardware Recommendations:
As mentioned one set of project improvements revolves around altering the hardware
used to implement DSP environment. This involves changing peripheral devices, input/output
(I/O) attachments, as well as the main FPGA chipset.
One main solution that could be addressed by through hardware modification could be
the high precision issue posed by some DSP functions. Currently the FPGA chipset being used
lacks the data precision required to accommodate Simulink generated precision values. A
solution to this could be using a more powerful FPGA chipset, such as one including the Virtex
5. This could potentially solve the problem without increased software modification. However the
downside to this option would be the increased cost on the user, due to the differing price
between the two chipsets.
An alternative reason to altering the hardware being used is to accommodate a new set
of DSP design options. Currently our hardware configuration is specific for audio I/O. A potential
future improvement could be the addition of other types of I/O, such as a monitor and the
appropriate peripherals, which would allow for DSP functions designed for such platforms (such
as image recognition). This could potentially increase the application of the product and expand
its marketability.

Software Recommendations:
Through continued development of the software portion of the project it is possible that
certain solutions to the certain problems and an expanded functionality could be added. The
bonus too implementing these solutions over the hardware counterparts would be that zero cost
change would occur for users.

Two different solutions could be made in the software to potentially solve our precision
issue. The first option involves designing a VHDL library for the environment to handle
arithmetic involving the real numbers which are currently causing problems. This would involve
the arithmetic library receiving all error causing data types used in the VHDL environment and
converting them to functioning data types for the boards capabilities. This would require that a
well defined library could be made as it would be imperative that conversions called by the
library could happen successfully, otherwise it would potentially create a more complex mess
when trouble shooting DSP functions.

33 | P a g e

The second option is more dependent on the application of different editions of Simulink.
Certain newer, more expensive editions claim to have a broader HDL coder and other tools
which can be used to generate VHDL code which would theoretically work in our current design.
This option would require more research to tell if the actual tools work in the methods that are
claimed.

Another possible improvement in our software system would be a broader DSP library
which would expand the user functionality of our product. This step is a logical progression in
the completed version of our project and could potentially be created by users through simple
application of DSP theories in our environment. The downside to this option would be that
certain DSP examples could not be made unless the previously mentioned hardware and
environment expansions allowing for other types of I/O were implemented first.

Scripting Recommendations:
One error that occurred in the script development happened when testing the script on
various Windows systems. AutoHotkey has the ability to identify windows inside the Windows
environment by comparing their title to a string. The comparison can be configured to match the
title in certain ways; the windows title must start with the specified string to be a match, a
windows title can contain the specified string anywhere inside of it to be a match, or the
windows title must match the string exactly to be a match. In Windows Vista and 7, a style
upgrade allows for the full directory path to appear in some windows. However this path is also
considered by AutoHotkey to be part of the windows title, so if the path is shown and happens to
contain one of the strings used in the script to find a window, there is a possibility that a window
can create an incorrect positive match. There are a couple ways this could be fixed, including
creating more constrictive comparisons, but the recommended method would be to add a
portion to the scripting that would monitor the windows Windows environment handle. This
would be a fairly significant modification to the script, but would provide a solution guaranteed to
work in any Windows environment.

A minor fix would be to position the script GUI at the top of the screen rather than the
bottom, with the MATLAB and Simulink windows positioned below it. While this fix doesnt
directly affect the workings of the script, it prevents the GUI from blocking the Windows
environment taskbar, providing of course that the user hasnt manually positioned it elsewhere.

34 | P a g e

A purely cosmetic recommendation would be to fix some of the progress bars. Currently
the progress bar for creating a new project or opening an existing one is pretty accurate, but the
other two are not. The second progress bar details generating the HDL file with the Simulink
HDL Coder. Simulink has a built in progress bar the covers part of the file generation, but due
to the way MATLAB handles its own window process the typical way to monitor a progress bar
didnt work, so the progress was defined by prompts read from the MATLAB output console.
These could be modified and more checks could be added to make this bar more representative
of the actual progress of the file generation. The third progress bar follows the progress of the
programming file generation through the Xilinx compiling tools. Seven command calls are made
to the Xilinx command console and the progress bar simply increments by an amount
approximately equivalent to the percentage of the overall progress after each command call
finishes. Through further research a way to extract more specific information from a command
prompt console window could be found and used to create more reliable and accurate prompts
for advancing the progress bar.

Acknowledgement:

We would like thank the WSU facilities operators for the test equipment, office space
and dedication to the continued quality of the WSU facilities. Digilent Inc. for sponsoring this
project and giving us the resources to implement our project with, which otherwise our project
wouldnt have been possible. Our mentor Jack R. Hagemeister and Clint Cole, whom generated
the concept of our project and helped us on our design process. Dr. Fischer whom was the
instructor for our Digital Signal Processing class, which without we would not have been able to
design the DSP portion of our project.

35 | P a g e

References:
Barancev, A.V., S.G. Groshev, and V.A. Omelchenko. "Generation of Test Scripts for
Application with GUI Optimized for Manual Execution." Software Engineering Conference in
Russia (CEE-SECR), 2009 5th Central and Eastern European. Moscow. 137-42. Web.
Basegmez, F. "Extending a Scientific Application with Scripting Capabilities." Computing in
Science & Engineering 4.6 (2002): 52-59. Print.
"Backgrounder." Xillinx. Xillinx, 05 FEB 2007. Web. 10 Apr 2011.
<http://www.xilinx.com/company/press/kits/v5sxt/backgrounder.pdf>.
"Command Reference." AutoHotkey Documentation. Ed. Chris Mallett. Web.
<http://www.autohotkey.com/docs/>.
"DSP Platforms for Virtex-6 / Spartan-6 FPGAs." Xilinx, 2010. Web. 29 Apr 2011.
<http://www.xilinx.com/publications/prod_mktg/TDP_DSP_Product_Brief.pdf>.
"Enabling High-Precision DSP Applications with the FPGA Industrys First Variable-Precision
Architecture." ALTERA. ALTERA, 2011. Web. 12 Apr 2011.
<http://www.altera.com/literature/wp/wp-01131-stxv-dsp-architecture.pdf>.

Hall, Tyson. "A Framework for Teaching Real Time Digital Signal Processing with Field
Programmable Gate Arrays.." IEEE TRANSACTIONS ON EDUCATION. 48.3 (2005): 551-557.
Print.
Loui, Ronald P. "In Praise of Scripting: Real Programming Pragmatism." Computer 41.7 (2008):
22-26. Web.
MathWorks - MATLAB and Simulink for Technical Computing. The MathWorks, Inc., 2011. Web.
<http://www.mathworks.com/>.
Morin, Rich, and Vicki Brown. "Scripting Languages." MacTech 15.9 (1999). Web.
Morris, Kevin. "Xilinx Targets DSP (Again) New Platforms Optimized for Varied Flows."
Electronic Engineering Journal (2010). EE Journal. Techfocus Media, Inc. Web. 7 Feb. 2011.
<http://www.techfocusmedia.net/archives/articles/20101207-dsp/>.
Proakis, John G., and Dimitris G. Manolakis. Digital Signal Processing: [principles, Algorithms,
andApplications]. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. Print.
Ulrich, Karl T., and Steven D. Eppinger. Product Design and Development. 4th ed. New York:
McGraw-Hill Higher Education, 2008. Print.

36 | P a g e

Vera, Alonzo. " An Undergraduate Course and Laboratory in Digital Signal Processing With
Field Programmable Gate Array." IEEE TRANSACTIONS ON EDUCATION. 53.4 (2010): 638645. Print
"Virtex-5 features DSP enhancements." Design Article 2011: n. pag. Web. 20 Apr 2011.
<http://www.eetimes.com/design/signal-processing-dsp/4016943/Virtex-5-features-DSPenhancements>.
Wakerly, John F. Digital Designs: Principles and Practice. Upper Saddle River, NJ:
Pearson/Prentice Hall, 2005. Print.
Zhang, Juan, Hai-bing Su, and Qin-zhang Wu. "Research of Multi-mode Tracking Based on
Multi- DSP and FPGA." IHMSC 2010: 2010 Second International Conference on Intelligent
Human- Machine Systems and Cybernetics : Proceedings, 26-28 August 2010, Nanjing,
Jiangsu, China. Vol. 1. Los Alamitos, CA: IEEE Computer Society, 2010. 230-34. IEEE Xplore
(IEEE). Web. 4 Mar. 2011.
<http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=05590660&tag=1>.
Zach, Steve, and Suhel Dhanani. "DSP Co-Processing in FPGAs: Embedding HighPerformance, Low-Cost DSP Functions." White Paper: Spartan-3 FPGAs(2004): n. pag. Web.
29 Apr 2011. <http://www.xilinx.com/support/documentation/white_papers/wp212.pdf>.

37 | P a g e

Appendixes:
A. Resources
AutoHotkey

AutoHotkey is a free, open-source utility for Windows. With it, you can:
Automate almost anything by sending keystrokes and mouse clicks. You can write a mouse

or keyboard

macro by hand or use the macro recorder.

Create custom data-entry forms, user interfaces, and menu bars. See

GUI for details.

Remap keys and buttons on your keyboard, joystick, and mouse.

Respond to signals from hand-held remote controls via the WinLIRC client script.
Convert any script into an EXE file that can be run on computers that don't have AutoHotkey installed.
http://www.autohotkey.net/~Lexikos/AutoHotkey_L/AutoHotkey_L_Install.exe
AutoIt3 Window Spy
AutoIt3 Windows spy is a free program that comes with AutoHotkey. It's a basic script used for extracting windows
information such as:
Window Title & Class
ahk_class
Mouse position on screen and in active window
Active window position

http://www.autohotkey.net/~Lexikos/AutoHotkey_L/AutoHotkey_L_Install.exe
SciTE4AutoHotkey
SciTE4AutoHotkey is a free, SciTE-based AutoHotkey script editor. v3 is the next generation of SciTE4AutoHotkey.
It provides the following functionality:
Syntax highlighting
AutoIndent
AutoComplete
Calltips (also known as IntelliSense)

http://www.autohotkey.net/%7Efincs/SciTE4AutoHotkey_3/web/
SmartGUI Creator 4.0
SmartGUI Creator is a program that creates standard Windows environment GUIs and creates AutoHotekey script
for them. Some of its features include:
Completely 'What You See Is What You Get - Move / Resize / Rename / Modify controls to see what the generated
GUI will look, in real time.
GUI Stealer - make copies of existing windows
Grid background (optional) is skinnable
Existing GUI scripts created using SmartGUI are re-editable

http://www.autohotkey.com/download/smartgui.zip
MATLAB
MATLAB is a high-level language and interactive environment that enables you to perform computationally
intensive tasks faster than with traditional programming languages such as C, C++, and Fortran.
http://www.mathworks.com/products/matlab/

38 | P a g e

Simulink
Simulink is an environment for multidomain simulation and Model-Based Design for dynamic and embedded
systems. It provides an interactive graphical environment and a customizable set of block libraries that let you
design, simulate, implement, and test a variety of time-varying systems, including communications, controls, signal
processing, video processing, and image processing.
hhttp://www.mathworks.com/products/simulink/

Adept 2.0
Digilent Adept is a unique and powerful solution which allows you to communicate with Digilent system boards and
a wide assortment of logic devices:
Configure the Xilinx logic devices. Initialize a scan chain, program FPGAs, CPLDs, and PROMs, organize and keep
track of your configuration files
Transfer data to and from the onboard FPGA on your system board. Read from and write to specified registers.
Load a stream of data to a register or read a stream of data from a register.
http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,828&Prod=ADEPT2

Xilinx ISE WebPACK

ISE Foundation integrates everything FPGA designers need in a complete logic design environment for all
leading Xilinx FPGA and CPLD products. Easy-to-use, built-in tools and wizards make I/O assignment, power
analysis, timing-driven design closure, and HDL simulation quick and intuitive.
ISE combines advanced technologies such as Proactive Timing Closure with a flexible, easy-to use graphical
interface to enable the best possible design results with the least time and effort.
http://www.xilinx.com/support/download/index.htm

39 | P a g e

B. GUI User Manual

Digilent Inc. DSP Project Developer GUI User Manual

The GUI for the Digilent Inc. DSP Project Developer has been designed to make it as intuitive
and easy as possible, but just in case you get stuck this manual contains all the information you
need to know.

The GUI Layout

The GUI is laid out in a straight-forward fashion. There are 5 main sections of the GUI, each
working off of the previous sections. At any time during use the user can hover their mouse
pointer over a button or drop down list and a tooltip will pop up, providing basic information
about the button or drop down list.

Section 1 Project Management

The first section of the GUI contains buttons that control creating a new project, opening an
existing project, or saving a project currently in progress.

1.1 - The New Button

The New button allows the user to create a new project. A folder
selection window is opened in which the user can select an already
existing folder, or create a new folder. Once a valid folder selection has
been made the development environment is opened and configured for
easy use.

1.2 - The Open Button

The Open button allows the user to open an existing project. Clicking
the button opens a folder selection window in which the user can select
a folder that contains a valid project. Once a valid folder selection has
been made the development environment is opened and configured for
easy use.

40 | P a g e

1.3 - The Save Button

The Save button saves the current project files, and deletes unnecessary
files from the project folder. This button is not specifically needed at
any point during project development as the intermediate programs will
save the files they need through the process, but due to the project
cleaning aspect of the Save button it can cut down on the size of a
project folder if space is a concern.

Section 2 HDL Generation

The second section of the GUI contains the HDL Generation button, which is enabled once a
valid project has been opened or created from Section 1.

2.1 - The Generate HDL Button

The Generate HDL button sends a command to the MATLAB command
console to generate a VHDL file of the project currently being
developed in Simulink. This file is necessary to compile and build the
project.

Section 3 Project
Compilation/Building
The third section of the GUI contains all the controls necessary to compile the project and build a
file that can be used to program an FPGA board.

3.1 - The Compile Project Button

The compile project board sends commands to the Xilinx command
console to compile and build the project. The parameters that define the
what type of board the project is being built for and which system clock
the user wants to use for their project are selected in the drop down lists
of this section of the GUI.

41 | P a g e

3.2 - The Set Xilinx Path Button

Due to system limitations, the GUI cannot always find the correct file
path to the Xilinx command console. As such this button provide the
user the option of specifying the path. Once a path has been verified the
button is disabled unless the user tried to compile their project again and
the command console cannot be found. This could occur if Xilinx is
updated or reinstalled to a different directory.
WARNING: A project can NOT be compiled without a valid path to the
Xilinx folder.
Note: As new features are developed to automate the process of finding
the necessary intermediate programs, this button will be removed.

3.3 - The Chipset Selection Drop Down List

In order to generate a programming file that's compatible with the FPGA
development board, the correct chipset needs to be selected from the
drop down list.

3.4 - The Project Clock Selection Drop Down List

When programming an FPGA development board, there are two clock
resources available. This drop down list can be used to select which
clock resource is to be used for the programming file that is generated.

Section 4 Board Programming

This section of the GUI allows the user to program their FPGA development board.

4.1 - The Program Board Button

Once a project has been compiled and built, a program file is generated
that can be used to program an FPGA development board. This button
opens the Digilent Inc. Adept software that is used to program boards.
Once the software is open the user can click browse and the program file
will be automatically selected. Next click the program button and the
board will be programmed.

42 | P a g e

Section 5 - Exit
The final section of the GUI contains the button for exiting the program.

5.1 - The Exit Button

The Exit button sends a shutdown command to all intermediate software
which is open, then closes. As each intermediate software carries out its
shutdown process it will prompt the user to save their files.

43 | P a g e

C. Intro to Difference equation:

For a Discreet Linear Time invariant system you can represent the output

as:
(1.1)

Which is derived from the convolution summation equation,

(1.2)
where

is the unit sample response. For some systems it is possible to expand the

summation into a more manageable form called a constant coefficient difference

equation. The general form is as fallows,

(1.3)
Where

and

are constant coefficients of a time delay of the input and output of the

system. This form can be especially useful when designing a system as you can easily
create a visual representation to help us analyze and understand how the system works.
There are actually two different types of visual representations that are widely used
which are called Direct Form I and Direct Form II.
Direct Form I is probably the easiest model to create from equation (1.3)
Figure 1.1 Direct From I

Where

is a unit delay that corresponds to a delay of one iteration. You can see that

the unit delay cascades down and add together to get the higher delay values necessary
to create the system. The triangles represent a multiplication of the corresponding signal
which is then summed with the other signals for that iteration. You can also see that the
input and output signals are separated on either side which makes drawing this from an
equation fairly easy. However this is not as efficient as the Direct Form II model, which
takes the fallowing form.

44 | P a g e

Figure 1.2 Direct From II

You can see that there are many similarities between the two models, but Direct Form II
is somewhat simplified by using only one unit delay less per order of the system. While it
may not save you that much time if you are simply representing the model, the real
efficiency is in the design process. While designing the system you save same some
complexity from adding extra unit delays from the system which scales with the order of
the system.
Intro to Z-transform
The z-transform of a discrete time signal

is defined as the power series

(1.4)

Where z is a complex variable. A more common way of representing

which is often

used in filter designs is:

(1.5)
Where

has to be less than 1 for the system to be stable. While this is a simple first

order system you can easily expand the model to accept higher order by adding more
poles, and you can even add zeros to the numerator as well to accommodate certain
systems.
How to go between the two.
For a given difference equation of the form:

You can re-write this using a property of the z-transform that states a time delay
translates to a multiplication by
, more specifically,
(1.6)
45 | P a g e

And
(1.7)
And so you can see that the equation can be easily switched in the time domain to the zdomain, and you can also fine the transfer function using this method as,
(1.8)
For example you can write the simple difference equation as a function of z as follows:
Given:

You first want to change everything into the z domain.

Simplifying

And finally putting into a transfer function form

This is a really compact way to represent a digital filter, and allows a lot to be discovered
about the properties of the system.

46 | P a g e

D. Echo tutorial
For this example you will be creating a Direct Form I block diagram of the following equation:

This function is one of the simplest DSP function to make but its results are very noticeable.
What basically is happening is the signal is being divided by two, delayed then the delayed
version is added back into the present signal, which forms a slight echo.
To Create the Direct From I model in simulink you first need to add the input and output blocks
which can be found under Simulink->Souces->In1 and Simulink->Sinks->Out1.
The difference equation from the above equations can be transformed to a z transfer function
as follows:

Since you can see that this is a 1st order system, and there is only one

element, you will

need to add one delay element in the Simulink model. This can be found under Simulink >Discrete-> Unit Delay.
Next you will need to add two summation blocks found under Simulink->Math Operations>Sum
Finaly you need to add 2 Gain blocks which can be found under Simulink->Math Operations>Gain
The final step in creating the echo generator is to connect the blocks in the Direct Form I format
as shown below and assign the proper values and names to components:

47 | P a g e

Figure1.1 Direct Form I Echo Generator

1

.5

x(n)

b_0

y(n)

0.5

z
Unit Delay

b_1

In order to make the function work with the FPGA Environment you need to make the data types
for the blocks a 16 bit integer type. The blocks you need to make changes to are the gain
blocks, the sum blocks and the input/output blocks. To make these changes you simply
need to double click the block and go to the Signal Attributes (and Parameter Attributes for
the gain block) and choose the Output data type as int16 as shown below.

Figure 1.2 Block properties

Now you simply need to upload the program to the board (see user manual for help in this step).
If you record your voice then play it back you might be able to hear a slight variation in your
voice. The echo is only slight because the delay amount is only 1 sample, and since the system
is sampling at 44 kHz, the actual time delay is extremely small.

48 | P a g e

This small of a delay is pretty hard to hear with the human ear, so it is desirable for this tutorial
to increase the delay amount. To do this you will need to replace the Unit Delay with an Integer
Delay which can be found in the same category. To increase the delay amount, double click
the Integer Delay block and under Number of delays, change the value to 2000. Recompile,
and upload the new function to the FPGA board. Now when you play back a recorded voice,
you should hear a much more noticeable echo.
Figure 1.3 2000 Unit Delay Echo Generator
1

.5

x(n)

b_0

-2000
Z
Integer Delay

49 | P a g e

0.5
b_1

y(n)

E. Sample Rate Conversion.

Sample- Rate Conversion
Introduction
Sample -Rate conversion is the process of converting a signal from a given rate to another rate.
It is used in many applications such as multirate signal processing systems and
telecommunication system. The process itself is widely accomplished one of two ways,
converting to the analog domain and re-sampling the signal, using D/A and A/D converters to do
so, or through conversion entirely in the digital domain. The advantage of the later method is
that it does not suffer the same signal distortion of the first method caused by quantization
effects due to signal converters. For this reason the method presented here examines how the
sample rate conversion can be conducted in the digital domain and then demonstrates one
method of doing so.
DownSampling/ Decimation
Downsampling, also called decimating, a signal is to decrease the sampling rate by a
rational factor. Assume a example signal x(n), with spectrum X(w), which is desired to be
downsampled by a integer factor of M. It can be assumed that X(w) is within the frequency 0
|w| . Simply taking every Mth value of x(n) would result in in aliasing of the signal, therefore
in order to properly downsample the signal a filter must first be passed to reduce the bandwidth
to wmax= /M. It cant then be downsampled by taking every Mth term [y(n) = x(n*M)].
Figure 2.1: DownSampling Realization

UpSampling/ Interpolating
Upsampling, or interpolating, a signal is to increase the sampling rate by a rational
factor. Examining the theory behind upsampling is similar to downsampling, in this case, first the
upsampling occurs. Numerically speaking, the output from the upsample of a rational factor L is,
y(n) = x(n/L) when n = 0, L, 2L, 3L... and y(n)= 0 otherwise.
This results in images of X(w) at higher frequencies however, therefore it is important to use a
low pass filter after the upsampling to cut off frequencies above the range of w= / L.
Figure 2.2: UpSampling Realization

Sample Rate Conversion by Rational Factor L/M

The down side to both Up and Down sampling a signal is that the rate conversion is
limited to a rational factor. However, by cascading an Upsampler with a Downsampler it is
possible to convert a sample rate by an arbitrary factor, thus granting the versatility of analog
sample rate conversion mentioned earlier. Combining the low-pass filters from the two systems
50 | P a g e

is simple since they are directly connected, the only question is which cutoff frequency should
be used. In this case the desired frequency is the minimum of either the initial sampling rate or
the new one. The order of this filter must be large in order to reduce the attenuation time to as
low as possible.
Figure 2.3: Arbitrary Factor sample rate conversion

Simulink Tutorial:
A sample rate conversion block can be created quite simply using pre-made Simulink
DSP blocks. The first step in this design is creating by pulling them from the Simulink Library
Browser. If problems arise in searching for different blocks, remember, using the 'Search bar'
located at the top of the Simulink Library Browser allows for a search of all sub-libraries for
possible related blocks.
After opening Simulink and clocking on 'Create New Project' there are several libraries to
visit in the generation of blocks for a simple sample rate converter. First, go to the 'Signal
Processing Blockset' 'Signal Operations' Library and click and drag the 'Down Sampler' or
'Upsampler' blocks into the new project window. If integer sample rate conversion is the only
goal of the project. Otherwise, drag in both blocks to allow for the arbitrary factor sample rate
conversion described previously in this document. Next, go to the general Simulink block sets
and select the 'In' and 'Out' blocks from the 'Sources' and 'Sinks' libraries, respectively. These
will act as your input and output ports for your project. As such they should be named x(n) and
y(n) respectively. This can be done by clicking on the name of the block within the project and
simply retyping the name. It is important that this be done as it could potentially cause problems
during the automation process if the names do not match the environment. Finally, a filter block
is added by going to the Simulink's basic library 'Discrete' and draggin the 'Discrete Filter' block
into the program. Arranging the blocks as shown in Figure 2.3, above, it is then possible to use
the methods previously explains to design the filter and sampling rates to meet design
specifications. To edit the blocks values to meet an L or M values or their specific filter's transfer
function, double clicking on a block opens a operations window, which can then be used to input
the desired values. Once the design is completed in Simulink, follow the 'Scripting Tutorial' will
allow for implementation and testing of the DSP functionality.
Note, high precision values should be avoided in the filter block while using the current
implementation of this project as low precision boards are not capable of meeting gain values
and this increase the noise factor of the resulting system.

51 | P a g e