Summary: Students are to implement and optimize a frequency shift keying (FSK) digital transmitter and pseudo-noise (PN) sequence generator.
Note: Your browser may not currently support MathML. See our browser support page for additional details. You can always view the correct math in the PDF version.
Note: You are viewing an old version of this document. The latest version is available here.
In this lab you are to implement and optimize the frequency shift keying (FSK) digital transmitter and pseudo-noise (PN) sequence generator shown in this figure. For the lab grade, you will be judged on the execution time of your system (memory usage need not be minimized).
You will implement and optimize the complete system shown in this figure. over the next two weeks. You may write in C, assembly, or any combination of the two; choose whatever will allow you to write the fastest code. The optimization process will probably be much easier if you plan for optimization before you begin any programming.
Once you have planned your program strategy, implement the PN generator from Figure 2 and verify that it is working. If you are programming in assembly, you may wish to refer to the description of assembly instructions for logical operations in Section 2-2 of the C54x Mnemonic Instruction Set reference. Initialize the shift register to one.
In testing the PN generator, you may find the file
v:\ece320\54x\dspclib\pn_output.mat helpful.
To use it, type
load v:\ece320\54x\dspclib\pn_output
at the Matlab command prompt. This will load a vector
pn_output into memory. The vector contains 500
elements, which are the first 500 output bits of the PN generator.
Be prepared to prove to a TA that your PN generator works properly
as part of your quiz.
For your transmitter implementation you are to use the
data-block-to-carrier-frequency mapping in
this table
and a digital symbol period of
Viewing the transmitted signal on the oscilloscope may help you
determine whether your code works properly, but you should check it
more carefully by setting breakpoints in Code Composer and using
the Memory option from the
View menu to view the contents of memory. The
vector signal analyzer (VSA) provides another method of testing.
The VSA is an instrument capable of demodulating digital signals. You may use the VSA to demodulate your FSK signal and display the symbols received.
Configuring the VSA: The VSA is the big HP unit on a cart in the front of the classroom. Plug the output from the DSP board into the ``Channel 1'' jack on the front of the vector signal analyzer, and then turn on the analyzer and follow these instructions to display your output:
After powering the signal analyzer up, the display will not be in the correct mode. Use the following sequence of keypresses to set it up properly:
Viewing the signal spectrum on the VSA: The VSA is also capable of displaying the spectrum of a signal. Hook up the output of your PN generator to the VSA and set it up properly to view the spectrum of the random sequence. Hit ``Instrument Mode'' and then F1 (Scalar) to see the spectrum. Note that you can also use your Lab 4 code for this purpose.
Does what you see match the Matlab simulations?
One purpose of this lab is to teach optimization and efficient
code techniques. For this reason, for your lab grade
you will be judged primarily on the total execution
time of your system. You are not required to optimize
memory use. Note that by execution time we mean cycle count, not
the number of instructions in your program. Remember that several
of the TMS320C54xx instructions take more than one cycle. The
multicycle instructions are primarily the multi-word instructions,
including instructions that take immediates, like
stm, and instructions using direct addressing
of memory (such as ld *(temp),A). Branch and
repeat statements also require several cycles to execute. Most C
instructions take more than one cycle. The debugger can be used to
determine the exact number of cycles used by your code; ask your TA
to demonstrate. However, since the number of execution cycles used
by an instruction is usually determined by the number of words in
its encoding, the easiest way to estimate the number of cycles used
by your code is to count the number of instruction words in the
.lst file or the disassembly window in the
debugger.
We will grade you based on the number of cycles used between the
return from the WAITDATA call and the arrival at the next WAITDATA
call in assembly, or the return from one WaitAudio call and the
arrival at the next WaitAudio call in C. If the number of cycles
between the two points is variable, the maximum possible number of
cycles will be counted. You must use the
core.asm file in
v:\ece320\54x\dsplib\core.asm or the C core file
in v:\ece320\54x\dspclib\core.asm as provided
by the TAs; these files may not be modified.
You explicitly may not change the number of samples read and written
by each WAITDATA or WaitAudio call! We reserve the right to test
your code by substituting the test vector core file.
This is a two-week lab. Your prelab is due a week after the quiz for Lab 4, and the quizzing occurs two weeks after the quiz for Lab 4.
Grading for this lab will be a bit different from past labs: