Final_Report

Modelling Software Defined Radio
with the ZedBoard and FMComms4
RF Transceiver
Connor Delaosa

Abstract
This document looks to provide an explanation of the design choices and the structure of both an AM
and QPSK transmitter and receiver. These designs are based on those created by authors based in the
University of Strathclyde, Glasgow for the book Software Defined Radio Using MATLAB & Simulink and
the RTL-SDR in which the floating point models are adapted for fixed point implementation on FPGAs.
The FPGA used for the discussions in this book is the Digilent ZedBoard containing the Zynq-7000 All
Programmable SoC as well as the ADI FMComms4 Software Defined Radio RF front end.
From the initial stages of building the transmitters and receivers in Simulink to implemententing them
in Xilinx Vivado this document looks to guide any reader through these steps as well as giving the
flexiblity and satisfaction of learning how the designs work and what parameters to choose.
The QPSK transmitter and receiver are both successful in simulation in the MATLAB & Simulink
environment, recovering the symbols sent by the transmitter through the same AD9364 chip as what
the signal is being received from through a transmitRepeat method. These constellations viewed show
the effects of both timing and carrier synchronisation as well as the pre-processessing of the signal.
HDL implementation of the receiver design showed both how the area and timing constraints can be
tough to balance but prove that these designs can run at great speeds altough giving unexpected
results requiring further investigation in to how these radio designs operate whilst on these FPGA
boards.
An Amplitude Modulation (AM) transmitter and receiver is also discussed later on in which a music
sample is taken from a computer file sampled at 48 kHz and transmitted through the air then received
and processed giving the same sample of music at the same rate within seconds of transmission.
Whilst the QPSK design proves difficult to implement, this AM receiver shows that SDR architectures
can be implemented onto the ZedBoard at over 100 MHz whilst keeping the FPGA resources relatively
low, providing the same quality of signal as was originally seconds before.

Table of Contents
Introduction ....................................................................................................................................1
Hardware Requirements.................................................................................................................1
MathWorks Software Requirements ......................................................................................2
Optional Software...................................................................................................................2
Additional Hardware Requirements .......................................................................................2
QPSK Radio Design..........................................................................................................................3
QPSK Transmitter....................................................................................................................3
QPSK Receiver Design .............................................................................................................5
3.2.1. Pre-processing of QPSK Signals.......................................................................................7
3.2.2. Data Synchronisation....................................................................................................10
HDL Implementation and Resource Utilisation.....................................................................15
QPSK Implementation Results ..............................................................................................18
AM Transmitter and Receiver.......................................................................................................19
AM-DSB-TC Transmitter........................................................................................................19
AM-DSB-TC Receiver Design .................................................................................................20
HDL Results of AM-DSB-TC Receiver.....................................................................................23
4.3.1. Results after HDL Implementation................................................................................24
Conclusion.....................................................................................................................................25
Appendices....................................................................................................................................25
Appendix 1 – Transmit Repeat Code (QPSK).........................................................................25
Appendix 2 – Transmit Repeat Code (AM-DSB-TC)...............................................................26
References ....................................................................................................................................27

1 | P a g e
Introduction
Software Defined Radio (SDR) aims to allow radio designers more flexibility in their designs than
their traditional/hardware orientated counterparts. The ease of this technology can also have an
educational use as an added benefit giving beginners in the field a softer, more interactive approach
as opposed to testing their designs on complex analogue circuitry.
SDR in this instance is implemented on a Field Programmable Gate Array (FPGA) which allows this
flexibility to be achieved these new digital designs could be implemented on general purpose
processors but new tools brought out by companies such as MathWorks™ allow the transition from
software models (Simulink) to FPGAs to be much easier and quicker than it would be to code in a
processor language such as C/C++. These tools coupled with low cost SDR devices (NooElec R820T)
reinforce this educational purpose as well as providing powerful new designs to be implemented.
This report will use the Digilent® ZedBoard with the ADI FMComms4 RF Transceiver as a flexible front
end for the two designs that will be discussed. Recently, MathWorks have published support tools that
allow the ZedBoard with the FMComms2/3/4 to be used as well as various other FPGA devices
(PicoZed, ZC706C) in place of the ZedBoard.
Hardware Requirements
 ZedBoard™ with Xilinx Zynq®-7000 All Programmable SoC (or any other supported FPGA)
 Analogue Devices AD-FMCOMMS4-EBZ [1]
 Notable Features:
i. Tuneable Frequency Range: 70 MHz to 6 GHz
ii. Sample Rate: fs = 520.9 kHz to 61.44 MHz
iii. Max Rx Gain Range ≈ -4 to 71 dB
iv. Max Tx Gain Range ≈ -87.5 to 0 dB
Figure 1. ZedBoard and FMComms4 Setup [11]

2 | P a g e
MathWorks Software Requirements
 Communications System Toolbox Support Package for Xilinx Zynq-Based Radio [2]
 Embedded Coder Support Package for Xilinx Zynq-7000 Platform
 HDL Coder
Optional Software
 PuTTY accessed free of charge from:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Note: MATLAB® version 2015a and above are needed in order to have support for AD-FMCOMMS4-
EBZ.
Additional Hardware Requirements
 2x Micro-USB Cables
 12V Power to barrel jack cable
 Gigabit Network Interface Card (NIC) or a USB 3.0 Gigabit Ethernet adaptor dongle
 SD Card Reader with a 4GB or larger writable SD card (Speed Class 10 for Zynq/ZedBoard
Operating System).
 Ethernet Cable
 2x Antennas (Transmitting and Receiving)
Note: A USRP device can be used as a replacement for a transmitter and the transmitRepeat function
(Section 4). If being used instead, the USRP® Support from Communications System Toolbox support
package will also need to be installed.
The ADI FMCOMMS4 device supports only Single In Single Out (SISO) so there are only one
transmit/receive path for designs to use which limits possibilities with higher, more complex radio
models. As stated earlier, the AD9364 chip on the RF card supports a minimum sampling rate of 520.9
kHz which is different than some other SDR devices such as the R820T which can serve as the
replacement for most receiver designs as well as a troubleshooting possibility if available. Figure 2
shows the high level design of the ADI FMCOMMS4 attached to the ZedBoard demonstrating this SISO
operation.
ARM
Processor
FPGA (ZYNQ 7000)
Tx Design
Rx Design
FMCOMMS4
RF Card
Tx
Rx
Vivado
MATLAB &
Simulink
ZedBoard
Hardware
Drivers (ADI,
MathWorks)
Figure 2. High level architecture of ZedBoard coupled with FMCOMMS4 RF Card

3 | P a g e
Connor Delaosa - University of Strathclyde
QPSK Radio Design
Quaternary Phase Shift Keying (QPSK) is a digital signal modulation technique that takes 2 bits
simultaneously and selects one of four carrier phases to shift by (0°, 90°, 180°, 270°) with a constant
distance between each reference, these characteristics allow the signal to be ‘classified’ into one of
the four bins. Being able to modulate 2 binary bits of data per symbol allows the bandwidth of the
signal to be higher than its simple BPSK counterpart. As shown below in Figure 3, BPSK only needs to
be shifted to either 0° or 180° depending on if a 0 or a 1 is detected, higher constellations can be
achieved with more complex designs such as 8/16/32/64 QAM but for this report QPSK/4-QAM will
be used.
Figure 3. Comparison of BPSK and QPSK [3]
In this application, the SDR device is transmitting random 2 bit combinations over the air in order to
be received on the other side by the receiver and being demapped to its relevant constellation, the
QPSK constellation is what, ideally, should be seen with some errors in value but not in placement i.e.
since a digital signal is represented in these designs by an analogue value then the binary number 11
could be represented from +0.5 to +1 on both I and Q phases so there is expected to be a radius of
values surrounding the constellation but should hopefully not be mistaken for another constellation.
QPSK Transmitter
Figure 4 shows a Simulink model of the QPSK transmitter which undergoes 5 stages – Binary Data
Generation, DAC processing and RRC filtering, resampling, and scaling for transmission.
C:SDR_Receiver_TransmittersQPSK_FilesQPSK_Transmitter.slx
Figure 4. QPSK Transmitter (Simulink Model)
Binary Data Generation is implemented using a ‘Bernoulli Binary Generator’ which generate random
binary numbers with a rate of 2 samples per frame which is what QPSK needs as opposed to BPSK
which would only need to output 1 sample per frame.

4 | P a g e
The second stage involves the Simulink block ‘QPSK Modulator Baseband’ which acts as a DAC as it
outputs an analogue number between -1 and 1 and if we look at the constellation diagram inside then
the relevant placements are shown. In this design, Gray coding is used instead of binary coding as this
can give greater efficiencies due to only one bit changing at a time. A root raised cosine (RRC) filter is
used to implement pulse shaping and prevent leakage in the spectrum when the signal is transmitted.
Note: This raised cosine filter is needed on the receive side also to prevent inter-symbol interference
(ISI).
At this point the data rate is at 2000 Symbols/second and ideally should be sampled at this rate as a
minimum sample rate but the AD9364 can only sample at a minimum 520.9 kHz so resampling is
implemented in the form of polyphase filters (Interpolation/Decimation) which will take the 2 kHz rate
and take it up above the minimum sampling rate – as an “easy to deal with” number, 720 kHz is the
target rate for transmission. The buffer/unbuffer blocks allow the frame rate to change from 2 to 1000
to increase the efficiency and speed of the symbols being processed. Figure 5 demonstrates this
resampling.
Figure 5. Resampling from 2 kHz to 720 kHz
The response of these filters should be designed to not provide any amplification or attenuation to
the values processed as the scaling/amplification is done by the four gain blocks and the single gain
block in the next stage of the processing.
The FMCOMMS4 card has a 12 bit ADC on it which the size of number that we will attempt to aim for,
this is where the gain block is used, depending on the size of the values entering this stage, the amount
of amplification needed may differ but the maximum value for both real and imaginary parts is around
4096 - In this case the amplification is 215
.
After this; the signal is passed into the to workspace block which will record a certain amount of data
points, due to the pulse shaping the signal propagating through the system has a period of small values
which will give the system essentially ‘false’ data i.e. zeros where there the binary data might have
not been providing zeros. This problem is countered by the use of a step function, only allowing the
to workspace block to record values when we are sure that the false period has finished, in this case,
the step time is around 0.75 seconds in simulation time.
With the output verified with a time scope or looking directly at the data array that is stored in the
MATLAB workspace (QPSK_Data), transmission can now take place in the form of using a technique
called ‘transmitRepeat’ which takes a transmitter handle with desired parameters entered and looks
to loop the data into a First In First Out buffer (FIFO) which will output data indefinitely until a release
function is called. Figure 6 looks at a snippet of code (Appendix 1) showing the transmitter handle as
well as the transmitRepeat function in MATLAB code.

5 | P a g e
This transmitRepeat function will store QPSK_Data in hardware memory until the release method is
called with the transmitter handle. This allows the transmitter and receiver to basically run at the
same time without the need to configure two IP addresses.
Note: For both the transmitter and receiver to work off the same chip, both the transmitter baseband
sample rate and the receiver baseband sample rate must be the same.
As an alternative, if there is a USRP device available then this transmitter design could be used in
conjunction with the USRP by replacing the To Workspace block with a SDRu Transmitter block from
the USRP® Support from Communications System Toolbox library.
With the transmitter assembled at providing data at a high rate (720 kHz) it can now start to be
received by a receiver.
QPSK Receiver Design
This design can be found at:
C:SDR_Receiver_TransmittersQPSK_FilesQPSK_FixedPoint.slx' (or QPSK_FixedPointAGC)
To receive QPSK, the complex signals being transmitted must undergo several processes in order for
the symbols coming in to the receiver match the same constellations as what is sent by the
transmitter. The start of this design comes from a ZedBoard and FMCOMMS2/3/4 block spawning
from the Communications System Toolbox Support Package for Xilinx Zynq-Based Radio library which
will act as the receiver front end. This front end specifies the RF frequency that the system is tuned to
as well as the baseband sample rate, frame size, AGC properties and more. Figure 8 shows this block
and its dialog window.
The SDR receiver has a Channel Mapping parameter, if using the FMCOMMS4 board, this parameter
can only be set to 1 due to the board only having one Tx/Rx path. In the Advanced tab, deselect the
Bypass User Logic box if simulating the QPSK design that will be discussed later on.
Figure 6. Snippet of MATLAB Showing Transmitter Handle & Function
Fs = 1 kHz
Binary Data
Fs = 4 kHz
Modulation and RRC
Fs = 720 kHz
kHz
Resampling
Fs = 720 kHz
kHz
Scaling
Fs = 720 kHz
TransmitRepeat
@ 602 MHz
Figure 7. High Level Block Diagram of Transmitter Design

6 | P a g e
The receiver design in Simulink does not have a sense of a discrete sample time so a block must be
entered to allow discretisation of the sample time, this is done via a Signal Specification block with the
sample time being specified as:
𝑇𝑠 =
𝑓𝑟𝑎𝑚𝑒 𝑠𝑖𝑧𝑒
𝑏𝑎𝑠𝑒𝑏𝑎𝑛𝑑 𝑠𝑎𝑚𝑝𝑙𝑒 𝑟𝑎𝑡𝑒⁄
With this specified, it means that 720 kHz is now the specified sample rate entering the main body of
the receiver.
The receiver can optionally use ‘Burst Mode’ which allows the signal passed out to be in constant
frame lengths which is useful for enabled subsystems such as the one seen in Figure 9.
If the frame is complete then a signal, data length, is passed out and through a Data Type Conversion
block which then converts the signal to a Boolean, enabling the subsystem and allowing a more stable
output. The Radio IP address parameter is originally set from the hardware support package
installation where it was specified along with the network interface card IP address - the default value
is ’192.168.3.2’. [2]
Figure 9. Top Level Receiver Diagram
Figure 8. Simulink SDR Receiver Block

7 | P a g e
Figure 9 incorporates all the parameter discussed so far, whilst the QPSK subsystem contains the main
body of the design including; coarse frequency correction, automatic gain control (AGC) and
timing/carrier synchronisation. Figure 10 shows the next level of heirarchy of the receiver
encapsulating each stage of the design whilst Section 3.2.1 shows and discusses the
Correction_and_AGC system.
Figure 10. QPSK Main Body of Receiver
3.2.1. Pre-processing of QPSK Signals
Figure 11. Correction and Automatic Gain Control Subsystem
This system looks to take a complex signal (IQ1) at 720 kHz, scale it to between -1 and 1 then decimate
it to a lower, more managable rate (8 kHz) using FIR Polyphase (decimation) filters. This new signal
(IQ2) is then passed through a coarse frequency correction block (Correction) in which the complex
number is raised to the power of 4 (Figure 12).

8 | P a g e
Figure 12. Incoming IQ Signal Raised to the Power of 4
The pow function in MATLAB or the Math Function block does not fixed point arithmetic and therefore
cannot be used in implementation which now raises a point of alternate implementations of this
arithmetic. This design can use two different solutions, De Moivres Theorem or Linear Algebra
De Moivres Theorem:
(𝐴𝑒 𝑖𝜃
)
𝑛
= 𝐴 𝑛
(𝑒 𝑖𝑛𝜃
) = 𝐴 𝑛
[ cos(𝑛𝜃) + 𝑖𝑠𝑖𝑛(𝑛𝜃) ]
This means if we convert the signal into its magnitude and angle components then operate in either
MATLAB code or even simple blocks.
Linear Algebra:
(𝑎 + 𝑖𝑏)4
(𝑎2
− 𝑏2
+ 2𝑎𝑏𝑖)(𝑎2
− 𝑏2
+ 2𝑎𝑏𝑖)
This simple form is what is implemented in the design where two (a+ib)2
blocks are designed with
regular DSP block and multiplied together, giving a better response and accuracy but perhaps costing
more resources compared to the De Moivres Theorem approach.
This response is then passed through an FFT to find peaks at certain frequency values and apply the
frequency difference from 0 Hz to IQ2 by means of a complex exponential with a negative exponent.
𝐼𝑄2 = 𝑒2𝜋(𝑓𝑐+ 𝑓 𝑜𝑓𝑓𝑠𝑒𝑡)𝑡
𝐼𝑄3 = 𝐼𝑄2 × 𝑒2𝜋 (−𝑓 𝑜𝑓𝑓𝑠𝑒𝑡)𝑡
= 𝑒2𝜋𝑓𝑐 𝑡
This now gives us a corrected signal with no frequency offset – if transmitRepeat is being used i.e. the
signal is being transmitted and received on the same oscillator/chip then both designs will be running
at the same frequency, therefore no frequency offset will occur. If this is the case, then manually
adding a frequency offset will have the desired effect for testing.
This signal, IQ3 is now what is propogated through the remainder of the system, through a raised
cosine filter which has the effect of matching the filter on the transmit side, causing a desired effect
of zero-ISI as well as performing pulse shaping – smoothing the signal out and causing a decimation
effect on the sample rate which is unwanted in the overall operation of the system. To combat this,
an interpolation filter upsamples and filters the signal back to the 8 kHz rate.
𝑓𝑜𝑓𝑓𝑠𝑒𝑡
𝑓𝑜𝑓𝑓𝑠𝑒𝑡 + 𝑓𝑐

9 | P a g e
The next step is an automatic gain control in a HDL synthesisable form (Figure 13) which takes the
signal and applies a gain proportional to the desired amplitude value. In the design, 0.5 is the target
amplitude as it produces consistently positive simulation results. Once the target amplitude is
reached, the gain with oscillate, constantly over/undershooting the value.
Figure 13. Automatic Gain Control (HDL Code Generation Compatible) [4]
This brings the signal out to be approximately ±1 ± 1i and allows the constellation seen after this gain
to dynamically change depending on the size of the input signal, when implementing in fixed point
precision the constant blocks, AGC_Ref & Loop Gain, must be looked at as the output data types of
these blocks could cause the AGC to give unwanted values i.e. the Loop Gain fixed point length must
be large enough to encapsulate a large enough fractional length to avoid this being rounded to either
0 or 1. In this design Loop Gain is set to 0.001 and looks to control the step size of the adjustments
made in the feedback path so to represent this number exactly, the output data type has 15 fractional
bits which in this system would not cause a huge difference in resource cost but allows the AGC to
have a suitable sensitivity.
This signal is then passed through an interpolation filter and a repeater block to bring the sample rate
back up to 720 kHz for the system to be targeted and implemented on to the FPGA. The repeater block
is being able to be used as this is just repeating the sample symbol 30 times in a row, later this is
downsampled meaning that 29 of these 30 identical symbols are thrown away.
Figure 14. Constellation before and after Automatic Gain Control

10 | P a g e
3.2.2. Data Synchronisation
Once the data is of a desired amplitude, a problem still arises that there may be a timing and
phase offset apparent on these signals which may cause additional problems when it comes to
recovering the original transmitted signal. Figure 15 shows the full synchronisation system
(Synchronisation) based from the RTL-SDR book [5].
Figure 15. QPSK Receiver Synchronisation System
In theory there may be a lack of common timing reference, similar to the fact that there may be a lack
of common frequency reference if using separate/different devices. This is where the timing
synchronisation circuit is of use, the circuit will attempt to sample the signal at its ‘maximum effect
points’ as well as outputting a ‘strobe’ at the symbol rate (1 kHz).
To do this, the signal is oversampled by 24 and then passed through an Early Late Detector to
determine the error in where the maximum effect point is. Once this is found, it is passed through a
loop filter (essentially a PLL) and then sent to a Numerically Controlled Clock (NCC).
Knowing that the values entering the timing synchroniser (Figure 16) should be in the range of [-1, 1]
the fixed point types of each block can be chosen, allowing a significant fractional length to be included
for an accurate representation of the signal. Special care must be taken for multiplier blocks as these
are the most likely candidates for saturation and therefore inaccurate readings. A ‘simulate and alter’
approach can be taken to these blocks, allowing an appropriate fractional length as well as keeping
resource cost down is a balancing act that can be troublesome. Blocks such as the adders can usually
be kept somewhat unchanged in reference to the incoming signal – a sensible approach is assuming
the maximum and minimum expected values and adjusting for those values themselves whilst still
watching the fractional length of the data.

11 | P a g e
Figure 16. Timing Synchroniser
The NCC looks to apply an adjustable step size to an accumulator (Figure 17) which will output a strobe
at 1/24th
the rate that the symbols are arriving at. This rate is highly unlikely to be constant but on
average the system will attempt to change the accumulation to compensate for the synchronisation.
Figure 17. Accumulator/Numerically Controlled Clock (NCC)
This fixed point version of an NCC works by constantly increasing the value of X until the value sampled
is greater than 23.5 (Oversampling ratio - 0.5), if this value is achieved then the relational operator
will output a 1 (a strobe) which then causes the accumulator to wrap around by use of the NAND gate
and a switch. Due to the fact that this is a fixed point model, the Add3 block must be able to include
values up to the oversampling ratio, in this case it is 24 so there are 5 integer bits available to count
up to 25
-1. This limitation on the value is why there is a switch and logical operators, these force the
signal X to wrap around instead of climbing to its maximum value. As discussed previously, the

12 | P a g e
precision of the signal has the most effect in these synchroniser systems where the difference
between 0.9 and 1 are amplified when trying to do arithmetic such as those systems with multipliers
and gain blocks.
With these symbols enabled approximately every 1 millisecond, the I and Q channels can then be
combined and Figure 18 looks to demonstrate the constellations recovered from what was seen after
the AGC (Figure 14).
Figure 18. Constellation after Timing Synchronisation
As can be seen, there is a phase offset in this constellation and this is where the carrier synchronisation
has a positive effect on the signal.
Due to the design of this receiver, the carrier synchronisation should not activate/enable until we
receive data from the timing synchroniser i.e. if no data is processed then both I and Q channels from
timing synchronisation should be 0. To allow this to happen, a Step block could be used if this system
is not being targeted for FPGA implementation and/or is being used with floating point values but as
an alternate option a latch is created for fixed point implementation. This is done simply by XORing
either the I or Q channel with a single clock cycle delayed version of itself, the theory being that a clock
cycle should allow one input to the XOR gate to have a 0 (no signal) and the other to have something
other than 0 i.e. the timing synchroniser has processed a signal. Doing this and simulating the design
shows that Simulink recognises that if an input to a logical operator is not 0 then it is taken as a 1.

13 | P a g e
Figure 19. Time plot of latch operation as I channel begins
Figure 20 shows the carrier synchronisation circuit which should take the signal and de-rotate the
constellation by detecting a phase offset and compensating for it, essentially making the constellations
line up with either 45°, 135°, 225° or 315°. This circuit in particular is altered slightly in comparison to
the circuit seen in [5] due to the incompatibility of some trigonometric blocks and HDL code generation
and/or fixed point types. To fix the fixed point problem we can use the CORDIC approximation to
create a magnitude close to the real value at the expense of computation and FPGA resources (if being
targeted), a suitable number of iterations is found to be around 5 – this can be confirmed by comparing
the floating point equivalent method using Display blocks.

14 | P a g e
Figure 20. Carrier Synchronisation
Figure 21 demonstrates the custom MATLAB block containing HDL compatible functions which will
replace the incompatible trigonometric blocks but still maintaining the accuracy of the arithmetic. The
data types being output from these functions have to be defined within the code using fi and
numerictype but the word lengths being output should not be any different to those entering i.e. if
the signal entering is fixdt(1, 19,16) then the output will have a similar type.
Figure 21. MATLAB code for CORDIC Sine, Cosine and atan2 operations
function [sinOut, cosOut] = fcn(PhaseIn)
%#codegen
sin_error = cordicsin((PhaseIn),4);
cos_error = cordiccos((PhaseIn),4);
sinOut = fi(sin_error, 1,19,15);
cosOut = fi(cos_error, 1,19,15);
T = numerictype(1, 19, 15);
function angleOut16 = fcn(I, Q)
x = fi(I, 1,19,0); % Specify both I and Q channels as a fixed point
% signed with 19 integer bits
y = fi(Q, 1,19,0);
angleOut = cordicatan2(y,x,11); % Calculate the approximation
% of atan2 to 11 iterations
ang = fi(angleOut, 1,19,16); % Convert the approximation to a
% signed fixed point value
T = numerictype(1, 19, 16);
angleOut16 = reinterpretcast(ang, T); % Change the output data type
% to the fixed point value

15 | P a g e
At the end of this synchronisation system, the constellation should be fully recovered with no phase
offset, Figure 22 validates the usefulness of the synchronisation.
Figure 22. Rotated Constellation after Synchronisation
After this, the sample rate is decimated by the oversampling ratio making the sample rate the same
as the original symbol rate (1 kSample/s) and the Sign block can now classify these constellations into
the relevant binary number equivalent depending on the polarity of the signal entering. These symbols
are then printed to the MATLAB command window for viewing/validation.
Figure 23. Decision constellation at symbol rate
HDL Implementation and Resource Utilisation
Now that the QPSK receiver works in complete fixed point precision, specific areas of the design
can be targeted for hardware acceleration on the ZedBoard. Having a specific part on an FPGA greatly
increases the speed that that particular design can run at, in particular the pre-processing of the signal
in this case. The size on an FPGA is somewhat limited depending on what FPGA is available – larger
designs may be more difficult to fit onto smaller FPGAs so care must be taken when designing these
radios. In many FPGA targeting applications there is a balancing act between area and speed of a
design but either way both must be met in order for a design to be fully synthesisable and
implementable.

16 | P a g e
MathWorks’ HDL Coder is a powerful tool that works alongside Xilinx Vivado and ISE software
packages to allow an easy and somewhat quick way of taking a system and turning it into HDL code
that the FPGA can understand. Part of HDL coder’s toolset is the Software Defined Radio (SDR)
workflow which targets Simulink subsystems in a way which can allow the design to communicate
with the RF card as well as the fabric of the FPGA. In order for this SDR workflow to work the design
that is targeted must adhere to some requirements such as:
 The sample rates entering the subsystem must be equal to the sample rate exiting the system
 Input and output ports must be 16-bits wide in size
 The input and outputs ports can either be:
o 1 complex signal (I and Q combined)
o 2 real signals (I and Q)
These requirements can limit the system itself from either having to add more components to the
design to interpolate/decimate the sample rate to not being able to include a valid line into the design.
If the design meets these requirements then a good way of testing the resource requirements of the
radio is to, instead of going through the SDR workflow is to go through the Generic ASIC/FPGA
workflow as this takes significantly less time to synthesize and implement than the SDR workflow.
These are the steps in going through the Generic ASIC/FPGA workflow:
1) Type into MATLAB command window:
hdlsetuptoolpath('ToolName', 'Xilinx Vivado', 'ToolPath','C:XilinxVivado2015.2binvivado.bat');
This allows the workflow advisor to recognise the Xilinx Vivado Software (must have version 2015.2.1)
2) Right click on the desired subsystem
3) Highlight HDL Code → HDL Workflow Advisor
4) Select 1. Set Target → 1.1 Set Target Device and Synthesis Tool
5) Select Target workflow: Generic ASIC/FPGA, Target platform: ZedBoard and FMCOMMS2/3/4,
Synthesis tool: Xilinx Vivado then enter a project folder name (hdl_prj is the default)
6) Right click ^2.4 Check Sample Times and select Run to Selected Task…
The defaults of the HDL coder should suffice but if there are any errors then correct them according
to the workflow advisors instructions. If the timing of the design is also being tested then a constraints
file (.xdc) will have to be added to the design, this can be done in 4.1 Create Project under Additional
source files
After this is successful, Left click 4.2 Run Implementation and uncheck Skip this Task then run
everything up to this point. If there are no errors then the project build will run in the background
then once this is done the Vivado project is available to open in the project directory that was
specified.
The SDR workflow in HDL coder requires a specific amount of space on the FPGA device being targeted
and are needed in order for the workflow to build the platform, configure specific connections and
generally make the design compatible with the fabric of the FPGA. Below (Table 1) are the specific
requirements for the ZedBoard and FMCOMMS2/3/4, other compatible FPGA requirements are
available at [6].

17 | P a g e
Table 1. FPGA Targeting Requirements for ZedBoard and FMCOMMS2/3/4
Resource Utilization Available Utilization %
FF 21906 106400 21
LUT 13263 53200 25
Memory LUT 728 17400 4
I/O 56 200 28
BRAM 45 140 32
DSP48 60 220 27
BUFG 7 32 22
The resources that this workflow takes are quite significant in respect to the amount of space that is
actually available – this now stresses the point of how radio designs need to take as small an area on
the FPGA as possible either through alternate designs of polyphase filters or through finding HDL
optimised blocks as a replacement to standard blocks.
To go through the SDR workflow in HDL Coder:
1) Go to the HDL Workflow Advisor
2) Select Target Workflow: Software Defined, Target Platform: ZedBoard and FMCOMMS2/3/4,
Synthesis Tool: Xilinx Vivado and then enter a project name/directory
3) Select Step 1.2 and make sure the channel mapping is 1 (FMComms4) and the User Logic Data
Path is set to Receive Path then set the synthesis frequency to around 1-2MHz
4) Right click 4. Build SDR and select Run to Selected Task…
This process will take a while depending on how large the design is, the QPSK receiver design took
around 45-50 minutes to complete fully. Once this is complete, the SDR SD card image should be
available to download. To download the image to the SD card follow these steps:
1) Release the transmitter handle if not done already by entering the release method e.g. release(tx)
2) In the MATLAB command window, enter:
dev = sdrdev(‘ZedBoard and FMCOMMS2/3/4’);
downloadImage(dev, ‘SDCardImage’, ‘C:/…/hdl_prj/sdr_prj/sdcard_image’);
This will reboot the FPGA board, when the command window states that the reboot is complete then
the board should be able to transmit and receive again.
3) Call the transmitRepeat function to start transmitting the signal again
4) Enter the receiver design and remove the targeted subsystem as well as any Buffer, Unbuffer, Data
conversion blocks that may precede it as these are implemented on the FPGA
If still unsure, MathWorks have put together an example for targeting HDL QPSK Receivers and
Transmitters [7].

18 | P a g e
QPSK Implementation Results
Table 2 shows the resources that the main body of the QPSK receiver takes on the ZedBoard with
the SDR workflow area. This design meets the timing requirements of 720 kHz at a minimum and
around 4 MHz as a maximum – both the timing and carrier synchronisation systems reach around a 7-
8MHz rate but were only targeted for a 24 kHz rate. These results can be viewed in the HDLx_sdrrx
Vivado project:
C:SDR_Receiver_TransmitterQPSK_FilesQ_SDRsdr_prjHDLx_sdrrxHDL_sdrrx.xpr
Table 2. Area Consumption by QPSK Receiver
FF 34117 106400 32.06
LUT 25083 53200 47.15
Memory LUT 1163 17400 6.68
I/O 56 200 28.00
BRAM 43 140 30.71
DSP48 178 220 80.91
BUFG 6 32 18.75
In the QPSK example discussed earlier, targeting the synchronisation systems caused the system to
respond in an unexpected way, as seen in Figure 24 the constellations are unable to be recovered as
opposed to the simulated version seen earlier and show that the timing circuit is not able to distinguish
between the different symbols but still show this rotated constellation which could come down to an
oversampling issue. Another possibility could be a timing error when the image is on the FPGA and
the rest of the design in Simulink is not running at the same rate as the image is or it could be that the
symbols entering the system are being altered on the way out of the targeted image. The carrier
synchronisation is only enabled by the timing circuitry so could be a good starting place for
troubleshooting.
This error is similar as if just the Correction_and_AGC system is targeted instead of the whole system,
the synchronisation systems are being run through Simulink but still show unexpected results – further
investigation is needed to recover these constellations in a way that matches simulation results. This
can be looked at as a classic case of theory and simulation against practicalities of real live signals but
at this moment in time, the QPSK receiver is successful in simulation only but has proven that the
whole system can fit onto an FPGA and run at a rate that exceeds the rate at which the symbols are
being sent – allowing the possibility of sending the symbols at a much higher rate and pushing the
receiver to respond quicker whilst still keeping numerical accuracy in the constellations.
Figure 24. Timing (Left) and Carrier (Right) Synchronisation after Correction_and_AGC Subsystem is targeted

19 | P a g e
Figure 25 shows the time scope of both the accumulator and timing strobes that enable the carrier
synchronisation circuit, it can be seen that the distance between each strobe is 1 ms but there is an
offset where the first strobe is enabling before the first set of symbols is finished i.e. before 1 ms –
this could be another problem that may cause the timing synchronisation to be incorrect.
Figure 25. Accumulator and Strobe Time Scopes
AM Transmitter and Receiver
AM-DSB-TC Transmitter
With the QPSK transmitter and receiver completed, a simpler task of an AM radio was undertaken.
Using the already existing design in [5], much of what has been discussed earlier on in this document
may apply to this design such as resampling and HDL code generation. The scheme used in this
example is a ‘double sideband with a transmitted carrier wave’ as the receiver design can be modelled
in a less resource intensive way.
The first place to start is the transmitter design, the original design was sampled at 240 kHz and used
a USRP to transmit the signal over the air. The SDRu Transmitter block acts in a similar way as what
the transmitter handle does in the earlier transmitRepeat example but this block can specify Local
Oscillator (LO) offsets as an add-on. Figure 24 shows the adapted version of this circuit, adding extra
blocks to allow for the RF card to be used.
The first stage in this design is taking a mono music signal sampled at 48 kHz and using the From
Multimedia File block to pass this data in to Simulink. The next stage is the resampling stage, blocks in
green originate from the original, USRP model whilst the added interpolator takes the sample rate up
from 240 to 720 kHz. The signal transmitted should be of a complex form so adding as null imaginary
component ‘fakes’ the complex component suitable for transmission. The final stages are similar to
Section 3.1 where we amplify the signal to the AGC bit length and then store the data in the MATLAB
workspace for transmission later.
This transmitter design can be viewed at:
C:SDR_Receiver_TransmittersAM_FilesAM_Transmitter_transmitRepeat.slx
Figure 26. AM-DSB-TC Transmitter Design

20 | P a g e
Using the transmitRepeat method, the transmitter handle has to be altered slightly – transmitting the
signal at 433.9 MHz instead of 602 MHz, all other settings should be as they were earlier. Appendix 2
shows the MATLAB script enabling the model and transmitRepeat to be run.
AM-DSB-TC Receiver Design
This receiver model can be viewed at:
C:SDR_Receiver_TransmittersAM_FilesAM_FixedPoint.slx
Now that the signal is transmitted at 433.9 MHz a simple envelope detector can be implemented in
Simulink that will allow the signal to be detected and extracted for the receiver side to listen to.
Figure 27 shows the top level of the receiver, the signal entering In1 comes from the FMComms4 SDR
receiver block seen in Figure 8. The signal is scaled down to values between -1 and 1 before the sample
time is specified – the transmitter outputs the signal in frames of 3000 so it seems sensible to
propagate frames of 3000 through the receiver at this point before being unbuffered to a scalar size
so that the envelope detector (Env) can be targeted by the FPGA.
The envelope detector itself is designed to work at 48 kHz so an interpolation of 15 is needed to keep
the sample rate coming in (720 kHz) the same as what is leaving the system – Hence, a FIR decimation
filter is needed after the detector to record data to a multimedia file (.wav) at the rate of the original
music file. Figure 28 below demonstrates the envelope detector in a fixed point format for HDL code
generation.
Figure 27. Top Level of AM-DSB-TC Receiver

21 | P a g e
Figure 28. Fixed Point Envelope Detector
As can be seen from the envelope detector, the values entering and exiting are of 16-bit width and
the repeater (15x) allows the sample rates to match.
In floating point versions of this circuit, the Simulink modulus block is suitable for an envelope detector
but is not HDL code generation compatible so an alternative is used – available from various
MathWorks examples [8]. The complex modulus design looks to implement an approximation on a
square root as the actual square root design is computationally expensive when implemented onto an
FPGA. It could also be noted that the HDL Optimised Complex to Magnitude-Angle [9] could work in
place of this system also.
Figure 30 shows the signal before the complex modulus operation (top) and also after (bottom).
Figure 29. HDL Code Generation Compatible Modulus [8]

22 | P a g e
Figure 30. Before (Top) and After (Bottom) Complex Modulus
This operation allows the information to be extracted from the signal incoming, the images shown
validates this as it can be seen that the spectrum of the before modulus having no discernible features
to it whereas the after modulus shows what a double-sideband AM signal should look like, a carrier
wave at baseband and a peak at fc ± fm where fm is the frequency that is mixed with the information
signal.
This detection is the heart of this circuit whereas the other components as only for sample rate
handling, filtering (bandpass) and pipelining (delays). As a resource saver, the filters in this design can
be operated in a serial architecture form which allows the sharing of different arithmetic operations
to a 10 weight filter may only need to share 3 multipliers but the downside is that the design may
demand the system run at 3 times the base clock speed. So again, this is a balancing act between
Speed and Area on an FPGA. More information about Serial FIR Architectures can be found on the
MathWorks documentation [10]
Figure 31 shows the output of this receiver circuit after the decimation back down to 48 kHz and data
type conversion has be processed (multimedia playback can only happen in floating point).

23 | P a g e
Figure 31. Processed AM Signal
This signal looks as it would be expected, sidebands at around 2.5 kHz either side of the baseband
carrier wave as well as images of these sidebands at regular intervals. With the output of this receiver
confirmed in fixed point format, the envelope detector can start to be implemented in HDL using the
MathWorks tools.
HDL Results of AM-DSB-TC Receiver
Similar to the QPSK implementation, the steps that take the design from simulation to HDL are the
exact same – the design is tested using the Generic ASIC/FPGA workflow in order to view resource
utilisation and timing then the design is put through the Software Defined Radio workflow to create
an image on the FPGA’s SD card.
Table 3 shows the resource utilisation of the AM Receiver whilst using parallel architectures for the
FIR and bandpass filters.
Table 3. FPGA Resource Utilisation of AM-DSB-TC Receiver (with SDR workflow)
FF 34527 106400 32.45!Syntax Error, (
LUT 20407 53200 38.36
Memory LUT 855 17400 4.91
I/O 56 200 28.00
BRAM 43 140 30.71
DSP48 91 220 41.36
BUFG 6 32 18.75
Targeting the envelope detector at 100 MHz allows the receiver to run at very high speeds, much
higher than any sampling rate in the design. Using the constraint below tells Vivado the speed at which
it should run and returns a Worst Case Slack value which lets a developer know how much faster or
slower the implemented design is from what is specified:
create_clock -name clk -period 10.000 [get_ports clk];

24 | P a g e
After implementation, Vivado reports that the design is running approximately 0.8 ns faster than
targeted the new clock speed can be calculated:
𝑓𝑜𝑢𝑡 =
1
(𝑆𝑝𝑒𝑐𝑖𝑓𝑖𝑒𝑑 𝐶𝑙𝑜𝑐𝑘 𝑆𝑝𝑒𝑒𝑑 − 𝑊𝑜𝑟𝑠𝑡 𝐶𝑎𝑠𝑒 𝑆𝑙𝑎𝑐𝑘) 𝑛𝑠
𝑓𝑜𝑢𝑡 =
1
(10 − 0.8)𝑛𝑠
=
1
(9.2)𝑛𝑠
= 108 𝑀𝐻𝑧
So this can confirm that the design runs at a much higher rate at what is needed but with the resource
utilisation being primarily taken by the SDR workflow the parameters of the design used here seem to
be reasonable but could be optimised for either Area or Speed depending on the application.
4.3.1. Results after HDL Implementation
When the SDR workflow is completed, the image is downloaded onto the FPGA SD card and
the model is retargeted by removing the env subsystem and unbuffer/buffer block – the retargeted
model can be seen in Figure 30 below. When simulated again, the audio signal is recorded into the To
Multimedia File block and can be listened to. The result of this is a clean audio signal somewhat
matching the original sample of music but on a constant loop every 10 seconds. The spectrum of this
signal is identical to that seen in Figure 31.
Figure 32. Retargeted AM-DSB-TC Receiver Model

25 | P a g e
Conclusion
In conclusion, the use of Software Defined Radio on the ZedBoard coupled with the FMComms4
RF card can be a powerful combination when used in the right way. Having a receiver running at over
100 MHz can prove that beginners to both the fields of FPGAs and SDR are able to pick up and process
different live radio signals. Even though a QPSK receiver proves a challenge to implement on an FPGA,
the process involved in preparing systems for hardware acceleration is the same for any SDR system
in Simulink whether it is AM, FM or even n-QAM. The AM example proved a success with receiving a
live 10 second sample of music AM-DSB-TC modulated then going on to implementing an envelope
detector on to the ZedBoard resulting in a reasonable resource usage and a clock speed that exceeded
the target speed.
This document looked at providing a guide into how two transmitter/receiver combinations can be
modelled in Simulink using one ZedBoard and FMComms4 RF card and the different consideration that
need to be taken when attempting to use this hardware.
Appendices
Appendix 1 – Transmit Repeat Code (QPSK)
tic
tx = sdrtx('ZedBoard and FMCOMMS2/3/4', ...
'BasebandSampleRate', 720e3, ...
'CenterFrequency', 602e6, ...
'ChannelMapping', 1, ...
'Gain', 0, ...
'ShowAdvancedProperties', true, ...
'BypassUserLogic', true);
%% Run Simulation Model
QPSK_Sim=sim('ENTER_TRANSMITTER_MODEL_PATH','SimulationMode','Normal',
'StopTime', '25');
QPSK_Data = QPSK_Sim.get('QPSK_trans');
%% Call transmitRepeat method to transmit QPSK Data
transmitRepeat(tx, QPSK_Data);
display(['Signal transmitted in a loop using ', tx.DeviceName, ...
' centered on ', num2str((tx.CenterFrequency)/1e6), ...
' MHz with Baseband Sample Rate of ',
num2str((tx.BasebandSampleRate)/1e3), 'kHz']);
toc
%%

26 | P a g e
Appendix 2 – Transmit Repeat Code (AM-DSB-TC)
%% Create a transmitter handle for the ZedBoard and FMCOMMS4 card
% Tuned to 433.9 MHz and sampled at 720 kHz
tx = sdrtx('ZedBoard and FMCOMMS2/3/4', ...
'BasebandSampleRate', 720e3, ...
'CenterFrequency', 433.9e6, ...
'ChannelMapping', 1, ...
'ShowAdvancedProperties', true, ...
'BypassUserLogic', true);
%% Run the AM transmitter to send logged data to the workspace
AM = sim('ENTER_TRANSMITTER_MODEL_PATH', 'SimulationMode', 'Normal');
AM_Data = AM.get('AM_TransmitRepeat');
%% Transmit the data on a loop using the 'transmitRepeat' function
transmitRepeat(tx, AM_Data);
display(['Signal transmitted in a loop using ', tx.DeviceName, ...
' centered on ', num2str((tx.CenterFrequency)/1e6), ...
' MHz with Baseband Sample Rate of ',
num2str((tx.BasebandSampleRate)/1e3), 'kHz']);

27 | P a g e
References
[1] Analog Devices, “AD-FMCOMMS4-EBZ Functional Overview,” 29 Apr 2014. [Online]. Available:
https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms4-
ebz/hardware/functional_overview.
[2] MathWorks, “Zynq SDR Support from Communications System Toolbox,” [Online]. Available:
http://uk.mathworks.com/hardware-support/zynq-sdr.html. [Accessed 2016].
[3] National Instruments, “802.11a Subcarrier Modulation Mapper: I80211A_MAP,” [Online].
Available:
https://awrcorp.com/download/faq/english/docs/VSS_System_Blocks/I80211A_MAP.htm.
[Accessed 1 8 2016].
[4] MathWorks, “HDL Optimized QAM Transmitter and Receiver,” MathWorks, [Online]. Available:
http://uk.mathworks.com/help/comm/examples/hdl-optimized-qam-transmitter-and-
receiver.html. [Accessed 03 08 2016].
[5] L. Crockett, K. Barlee, D. Atkinson and B. Stewart, Software Defined Radio Using MATLAB &
Simulink and the RTL-SDR, 2015.
[6] MathWorks, “FPGA Targeting Overview,” MathWorks, [Online]. Available:
http://uk.mathworks.com/help/supportpkg/xilinxzynqbasedradio/ug/fpga-targeting-
overview.html. [Accessed 07 08 2016].
[7] MathWorks, “Targeting HDL Optimized QPSK Receiver Using Analog Devices AD9361/AD9364,”
[Online]. Available:
http://uk.mathworks.com/help/supportpkg/xilinxzynqbasedradio/examples/targeting-hdl-
optimized-qpsk-receiver-using-analog-devices-ad9361-ad9364.html. [Accessed 07 08 2016].
[8] MathWorks, “Software Defined Radio using Xilinx Zynq SoC with MATLAB & Simulink,” 2016.
[Online]. Available: http://uk.mathworks.com/hardware-support/zynq-sdr.html. [Accessed 29 06
2016].
[9] Analog Devices, “RF Agile Transceiver - AD9364,” 2014. [Online]. Available:
http://www.analog.com/media/en/technical-documentation/data-sheets/AD9364.pdf.
[Accessed 20 06 2016].

Final_Report

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Final_Report

Similar to Final_Report (20)

Final_Report