1. SOC FPGA Design Lab Discussion 5
SDR Lab Continued:
DSP Blocks (Part I)

3. Agenda Discuss overall DSP architecture Lab 4 Recap
Clock domains
Lab 4 Recap
Channel selection filter
Design
CoreGen Implementation
Discuss the tools which will be useful in development / verification of our design
UDP streaming of data (as in Lab 4)
ISIM / Modelsim
Chipscope Introduction

4. Radio Receiver Core 25 Million 14-bit numbers / sec
Audio
/- 3 MHz
25 Msps
25 Million 14-bit numbers / sec
48k samples / second

5. Tuning / Downconversion
Given that we have sampled at 25MHz, the input to the signal processing blocks is depicted below
2.75
9.25
0 (DC)
12.5MHz
Multiple information channels exist in this signal, a typical job of the DSP blockset would be to
“Tune” to the appropriate section of spectrum
Mix it to baseband
Filter out other channels
Reduce data rate (decimate)
Demodulate

6. Frequency Translation
Graphics reprinted from :
We are going to accomplish this tunable translation with a DDS for generation of a complex sinusoid, followed by a complex mixer. Details next week.

7. Filtering
Two goals :
Remove contributions of signals from outside our channel
Reduce bandwidth so that data rate becomes manageable
25 Msps is not necessary to represent our small channel bandwidth (ex : 150 kHz for FM radio)

8. Lab 5 : Filter Demonstration
Implement the channel selection filter which will be used in the SDR
25Msps
48kHz
ADC
L.P. Filter
520
FIFO
uBlaze
Ethernet to PC
For analysis

9. FIR Filtering

10. FIR Implementation
Delay
Convolution in time domain is computationally complex, yet fairly straightforward.

11. Example Filter Design Process
Filter Specs:
Fs = 25 Msps
75kHz passband
100k stopband
Attenuate stopband signals by > 60dB
FIR Filter with <2048 taps will meet this requirement
Matlab : “fdatool”

12. Scaling and Quantizing h[n]
Output from FDAtool is floating point coefficients h[NUMTAPS] (aka “impulse response”). In absense of floating point multipliers, this is not directly implementable on our FPGA. We need to transform this impulse response to integers while preserving the function.
Numint = int32(Num*ScaleFactor+0.5);
Scaling factor,
How to choose?
Num

13. Quantized Coefficients
Overall, making the coefficients integers, (after multiplying by 32700) doesn’t affect our response too badly. With this scaling factor, our coefficient width is really only 9 bits. Some optimization between coefficient width and filter order could be undertaken if we chose.

14. freqz(numint,[1],100000);
numint=round(Num*1024);
numint=round(Num* );

15. Scaling and Quantizing h[n]
Numint = int32(Num* );
fid=fopen('filt2030.coe','w');
fprintf(fid,'radix=10;\ncoefdata= \n');
fprintf(fid,'%d,\n',NumInt);
fclose(fid);
radix=10;
coefdata=
15,
-1,
…etc
Scaling factor,
Choose this for a reasonable
Performance vs. utilization tradeoff
Result is : impulse response of filter in a “coe” file, which we will use later when designing the filter. Note that filter gain has changed though over the unity gain filter we designed in Matlab. Now, signals in the passband will come out x32700 over the input level.

16. FIR Implementation
Delay
How many Multiply-Accumulate operations (MAC) are required per sample to implement the filter we designed?
What is the overall rate of MACs per second?

18. Tool takes as input the “COE” file created previously to get h[n]

19. Implementation details show what we computed previously with a savings
Due to symmetrical structure

20. As an example for high performance FPGA capabilities – consider Virtex 6.
DSP48E slices run up to 600MHz clock rates
Theoretical :172 GMACs / sec – 1.2 TMACs/sec

21. If we let filter run at higher clock rate than input sample rate, structure
Is automatically adapted such that a convolution takes multiple clocks using
Shared multipliers

22. Spartan 6 LX45 DSP 58 * 390M = max 22.6 GMACs / sec
Our FPGA is capable of doing about ½ of what we want
There will be other features of the FPGA that need multipliers…
These figures should help put FPGA capabilities for DSP in perspective

23. Allowing the filter to use the entire time between output samples for the covolution makes the task easily achievable (even with a slower clock to the Filter)

24. Decimating FIR Filter Core (“AXI-Stream Interface”)
COMPONENT channel_selector
PORT (
aclk : IN STD_LOGIC;
s_axis_data_tvalid : IN STD_LOGIC;
s_axis_data_tready : OUT STD_LOGIC;
s_axis_data_tdata : IN STD_LOGIC_VECTOR(15 DOWNTO 0);
m_axis_data_tvalid : OUT STD_LOGIC;
m_axis_data_tdata : OUT STD_LOGIC_VECTOR(31 DOWNTO 0) );
END COMPONENT;
S_axis_data_tvalid
m..tvalid
Changes with implementation and coeffs!
s_axis_data_tdata
m..tdata
tready
valid : enable signal, result is present on output on rising edge of clock when this signal is high
valid : enable signal, new data is latched on rising edge of clock when this is high
Din : data to filter
Ready : ready for new data
ACLK

25. Issues / Decisions
Clock domain for filter vs clock domain for A/D samples
25, 50, higher?
Higher clocks allow fewer multipliers and higher performance, but requires some thought at the clock domains
Coefficient width / scaling
Less bits for coefficients will save RAM, but will decrease filter performance
Scaling factor and its effect on filter output will need to be understood and compensated for.. Full scale input (14 bits) should generally map to full scale output (16 bits)
Evaluate the various output rounding / precision options in the FIR filter block to decide how to achieve this objective. Simulate if confused!
Full precision output is straightforward, output = input * scaling factor
FIFO size
Not super important to change yet; but with reduced data rate, you can now stream UDP data continuously and use a much smaller FIFO

26. Development Matlab Simulation
Use this to solve all the real DSP issues
Mixer frequency for tuning
Filter number of taps / coefficients
Scaling issues
FAST, easy to change

27. Development Modelsim / VHDL Simulation
Is useful to prove functionality of your design in known situations
Sometimes difficult to fully model real world
Simulations of individual pieces (particularly those which you did not write) can be very informative
Even more so than documentation
COREGEN cores easily simulated

28. SOC Debugging Premise : Full simulation often impractical
Visibility of internal signals is helpful to thoroughly debug / verify a design
Even external signals can be difficult to probe on high density boards
To observe functionality of your system as it interacts with an unpredictable real world is crucial

29. SDR Debugging Build proven reliable datapipes first:
i.e. your UDP or serial port
Build in the ability to send pieces of data from various points in the system out to be observed.
Ethernet data pipe developed in lab 4 can be used to grab data from different points in your signal processing chain
Simply provide a means for different things to be written into the FSL input FIFO.

30. Chipscope Pro
Internal FPGA Logic Resources are used to capture internal signals / events
Data is read out via JTAG cable
Essentially a logic analyzer inside the FPGA
FPGA resource limited

31. Example of Logic Analyzer view while system is running
Example of Logic Analyzer view while system is running. Real data from target

32. Chipscope Pro Flows

42. Notes
ICON core uses a “BSCAN” resource much like the Microblaze MDM Debugger
Spartan 3A DSP has only 1!
Effort beyond the scope of this demo is required to get both working concurrently
Online description will follow
System without Microblaze, or without debuggable Microblaze is the easiest to experiment with first