Implementation of Digital Up Convertor for Software Defined

Family Radio Service

MAJOR PROJECT REPORT

Submitted in partial fulfillment of the requirements for the award of the degree

of

BACHELOR OF TECHNOLOGY

in

ELECTRONICS AND COMMUNICATION ENGINEERING

by

Vedant Mahajan Rohan Saxena Vaishnavi Mendiratta Aditya Dewan

Enrollment No: Enrollment No: Enrollment No: Enrollment No:
60411502814 31211502814 60111502814 60511502814

Guided by

Prakhar Priyadarshi
Asst. Professor

DEPARTMENT OF ELECTRONICS & COMMUNICATION ENGINEERING

BHARATI VIDYAPEETH COLLEGE OF ENGINEERING
(AFFILIATED TO GURU GOBIND SINGH INDRAPRASTHA UNIVERSITY, DELHI)
NEW DELHI – 110063
APRIL 2018

1
 CANDIDATE’S DECLARATION

It is hereby certified that the work which is being presented in the B. Tech Major Project Report
entitled "Implementation of Digital Up Convertor for Software defined family radio
service"in partial fulfilment of the requirements for the award of the degree of Bachelor of
Technology and submitted in the Department of Electronics and Communication Engineering of
Bharati VidyaPeeth College of Engineering, New Delhi (Affiliated to Guru Gobind Singh
Indraprastha University, Delhi) is an authentic record of our own work carried out during a
period from January 2017 to May 2017 under the guidance of Prakhar Priyadarshi, Asst.
Professor, Dept. of Electronics and Communication Engineering, Bharati VidyaPeeth
College of Engineering, New Delhi.

Vedant Mahajan Rohan Saxena Vaishnavi Mendiratta Aditya Dewan

Enrollment No. Enrollment No. Enrollment No. Enrollment No.
60411502814 31211502814 60111502814 60511502814

This is to certify that the above statement made by the candidate is correct to the best of my
knowledge. They are permitted to appear in the External Major Project Examination.

(Prakhar Priyadarshi)
Asst. Professor,
Dept. of ECE,
BVCOE, New Delhi

2
 ABSTRACT

As information tools have move off the desktop and into people pockets, the rate of wireless communication is
accelerating. We need wireless components that can be reconfigured to support a range of standards. High-
speed instruction set processors are increasing in speed and decreasing in feature size and improving low
power operations. As new radio standards are deployed with substantially supplanting existing ones the need
for multimode multiband handsets and infrastructure increases. Our project describes how emerging FPGA
technology’s unique combination of size and power efficiency plus field programmability offers a transition of
FPGA’s from ASIC prototyping to embedded products. Software defined transmitter suggests an enlarged role
for FPGA’s in pragmatic path towards the productization of software radio technology. Previously, we created
a Software-Defined Radio (SDR) implementation of FRS transmitter. The SDR approach requires the usage of
Digital Up Converter (DUC). The function of the DUC is to translate one or more channels of data from
baseband to a passband signal comprising modulated carriers at a set of one or more specified radio or
intermediate frequencies (RF or IF). It is an essential component of SDR applications. Hence, we implemented
a DUC with specifications that suited FRS systems. We logically segregated the DUC implementation into
clearly defined stages. We completed the design and modeling based on Simulink with appropriate
specifications and signals. The overall approach that we adopted was the MBD (Model Based Design).
Accordingly, we created blocks that serve the advantage that the blocks can be easily interchanged, interfaced
and upgraded. The functional simulation output of DUC showed a successful sample rate conversion by a
factor of 40 as expected by the specification. Using this DUC block of the MBD design, we successfully
obtained the power spectrum of FRS. After the Simulink DUC implementation, we have now designed the
same using system generator Xilinx block set and generated a HDL code for its application on FPGA.

ACKNOWLEDGEMENT
We express our deep gratitude to Prakhar Priyadarshi, Asst. Professor, Dept. of Electronics
and Communication Engineering, Bharati VidyaPeeth College of Engineering, New Delhi for
his valuable guidance and suggestion throughout my project work.

We would like to extend our most sincere thanks to Dr. Anuradha Basu, Head of Department,
Dept. of Electronics and Communication Engineering for her time to time and invaluable
suggestions to complete our project work.

We are also thankful to Dr. Dharmender Saini, Principal, Bharati Vidyapeeth College of
Engineering, New Delhi for providing us with the facilities to carry out our project work.

Vedant Mahajan Rohan Saxena Vaishnavi Mendiratta Aditya Dewan

Enrollment No: Enrollment No: Enrollment No: Enrollment No:
60411502814 31211502814 60111502814 60511502814
 TABLE OF CONTENTS

CANDIDATE’S 1
DECLARATION

ABSTRACT 2

ACKNOWLEDGEMENT 3

TABLE OF CONTENTS 4

LIST OF FIGURES 7

LIST OF TABLES 8

LIST OF 9
ABBREVIATIONS

CHAPTER 1: INTRODUCTION 10

1.0 Introduction 10
1.0.0 Introduction to FRS 10
1.0.1 Introduction to SDR 11
1.0.2 Introduction to DUC 11
1.0.3 Introduction to Block- 11
based Design
1.1 Motivation 12
1.2 Objective 13
1.3 Summary 14

CHAPTER 2: DESCRIPTION 15

2.0 Description of SDR 15

Systems
2.0.0 Overview 15
2.0.1 Applications 15
2.1 Description of DUC 16
2.1.0 Overview 16
2.1.1 Building Blocks for DUC 16
Systems
2.1.1.0 Mixers 17
2.1.1.1 Direct Digital synthesizer 17
2.1.1.2 FIR Filters 17
2.1.1.2.0 Half-band Filters 18
2.1.1.2.1 Hilbert Filters 19
 2.1.1.2.2 Root-raised cosine filters 18
2.1.1.3 CIC Filters 20
2.2 Critical Design Parameters 22
for DUC Systems
2.2.0 Total Rate Change 22
2.2.1 Clock Rate 22
2.2.2 Number of carriers and 22
subcarriers
2.2.3 Number of channels 23
2.2.4 Passband Width 23
2.2.5 Modulation Scheme 23
2.2.6 Supported Standards 24
2.3 Description of FRS 24
2.3.0 Technical Specifications 24
of FRS Systems
2.3.1 List of FSR channels 25
2.4 Application of DUC in 27
FRS systems
2.4.0 Introduction 27
2.4.1 Introduction to Simulink 27
2.4.2 Design of DUC 27
2.4.3 Design of FRS 28

CHAPTER 3 IMPLEMENTATION 29
AND OUTPUT

3.0 Implementation of DUC 29

on Simulink
3.0.0 Specifications of DUC 29
3.0.1 Blocks used for Simulink 29
Implementation of DUC
3.0.1.0 Sine Wave Block 29
3.0.1.1 Up sample block 30
3.0.1.2 FIR Half-band Interpolator 30
3.0.1.3 CIC Compensation 30
Interpolator
3.0.1.4 CIC Interpolator 31
3.0.1.5 Normalisation Block 32
3.0.1.6 Complex to real image 32
block
3.02 Implementation 34
3.0.2.0 Simulink Model of DUC 34
3.0.2.1 Simulation of each stage 35
of the model
3.0.2.1.0 Input 35
3.0.2.1.1 Half-band Filter 37
3.0.2.1.2 CIC Interpolation 38
3.0.2.1.3 Output of DUC 39
3.1 Implementation of DUC in 40
FRS
3.1.0 Principle 40
 3.1.1 Implementation 40
3.1.1.0 Specifications 40
3.1.1.1 Implementation model 41
3.1.1.2 Input Spectrum 42
3.1.1.3 Output Spectrum 43
CHAPTER 4: HDL CODE GENERATION 44

4.1 45
 LIST OF FIGURES

Figure 1.1 SDR Concept

Figure 1.2 Development Flow of Model-Based Design

Figure 2.1 Generic DUC Architecture

Figure 2.2 Two Stage Mixing of Multicarrier Signal
Figure 2.3 Structure of Half Band Filter
Figure 2.4 Usage of Hilbert Transform in CBPS
Figure 2.5 CIC Component Stage
Figure 2.7 CIC Passband Aliasing
Figure 2.8 Block Diagram of DUC
Figure 2.9 Block Diagram of FRS Transmitter

Figure 3.1 Simulink Model of DUC

Figure 3.2 Specifications of Input to DUC
Figure 3.3 Input Waveform
Figure 3.4 HBF Waveform
Figure 3.5 CIC Interpolation Waveform
Figure 3.6 Output Waveform of DUC
Figure 3.7 Specifications of DUC for FRS Systems
Figure 3.8 Simulink Model of FRS
Figure 3.9 Spectrum of Baseband Signal
Figure 3.10 Spectrum of Passband Signal

Figure 4.0: HDL Code Generator

Figure 4.1: HDL Compatible Simulink Library
Figure 4.2 Simulink design for DUC using HDL code generator
 LIST OF TABLES

Table 2.1 List of FRS Channels Compared to GMRS

Table 3.1 Specifications of DUC
 LIST OF ABBREVIATIONS

FRS Family Radio Service

SDR Software Defined Radio
DUC Digital Up Converter
TDM Time Domain Multiplexing
FIR Finite Impulse Response
HBF Half Band Filter
CBPS Complex Band Pass Sampling Scheme
RBPS Real Band Pass Sampling Scheme
RRC Root Raised Cosine
FFT Fast Fourier Transform
GMRS General Mobile Radio Service
IF Intermediate Frequency
 CHAPTER 1: INTRODUCTION

1.0 INTRODUCTION

1.0.0 Introduction to FRS

The Family Radio Service (FRS) is an improved walkie-talkie radio system authorized in the
United States since 1996. This personal radio service uses channelized frequencies around 462 and
467 MHz in the ultra high frequency (UHF) band. It does not suffer the interference effects found on
citizens' band (CB) at 27 MHz, or the 49 MHz band also used by cordless telephones, toys, and baby
monitors. FRS uses frequency modulation (FM) instead of amplitude modulation (AM). Since the
UHF band has different radio propagation characteristics, short-range use of FRS may be more
predictable than the more powerful license-free radios operating in the HF CB band.

Worldwide, a number of similar personal radio services exist; these share the characteristics
of low power, operation in the UHF (or upper VHF) band using FM, and simplified or no end-user
licenses. Exact frequency allocations differ, so equipment legal to operate in one country may cause
unacceptable interference in another.

1.0.1 Introduction to SDR

SDR technology is defined as radios that provide software control of a variety of modulation
techniques, wide-band or narrow-band operation, communications security functions (such as
hopping), and waveform requirements of current & evolving standards over a broad frequency range.
In short, software modules running on a generic hardware platform of DSPs ( Digital Signal
processor ) and general purpose microprocessors can implement radio functions such as
modulation/demodulation, signal generation, coding and link-layer protocols. This helps in building
reconfigurable software radio systems where dynamic selection of parameters is possible. The
communication flow of today is very high. The evolution and growth of telecommunication systems
and services run in parallel to Integrated Circuit (IC) design techniques evolution. New fabrication
process allows a new functionalities and higher performance. Many applications are operating at high
speed and a fixed connection is often preferred.
 Figure 1.1: SDR Concept

1.0.2 Introduction to DUC

The design of the transmission side of a digital communication modem based on the use of
specialized Digital Up Converters (DUC). A DUC is a key component of digital front-end (DFE)
circuits for RF systems in communications, sensing, and imaging. The function of the DUC is to
translate one or more channels of data from baseband to a passband signal comprising modulated
carriers at a set of one or more specified radio or intermediate frequencies (RF or IF). It achieves this
by performing: interpolation to increase the sample rate, filtering to provide spectral shaping and
rejection of interpolation images, and mixing to shift the signal spectrum to the desired carrier
frequencies. The sample rate at the input to the DUC is relatively low; for example, the symbol rate of
a digital communications system, while the output is a much higher rate, generally the input sample
rate to a Digital-to-Analog Converter (DAC), which converts the digital samples to an analog
waveform for further analog processing and frequency conversion.
 1.0.3 Introduction to Block-Based Design

In the MBD, a system model is at the center of the development process, from requirements
development, through design, implementation, and testing. The development flow by MBD is shown
in Figure 1.2. Through the establishment of floating point model, the fixed-point model and the
system-level model for presenting a complete system design requirements, all aspects of the design
can be tested and verified according to the model of the system level and the demand.

Figure 1.2: Development Flow of Model-Based Design

1.2 MOTIVATION

Wayne H. Wolf (1994), who is a senior Member of IEEE, surveyed the embedded computer systems
that use software running on programmable computers to implement system functions. He asserted that with
the rapid and continuous development of embedded systems, there is an increasing demand for real-time or
comparable to real-time electronic products. However, these kinds of systems are complicated and drastically
increase the complexity and difficulty of embedded systems development and design process.

In his paper titled, Hardware-Software Co-Design of Embedded Systems [1], Wolf infers that the traditional
development flow is not conducive to the development of efficient, high-quality products for the rapidly
proliferating technological systems. Different departments are responsible for different processes and the
intercommunication between departments can easily lead to ambiguity - leading to catastrophic errors. Errors
that are transferred can influence the progress of the development of the entire project/system. Also, in the
absence of abstraction, If an error occurs at the beginning of the design, the whole design cycle and cost bring
great negative effects that could lead to a cascaded rollback of the entire process. Such a condition is only
aggravated if the error goes undetected up till the later stages.

Because of the existing problems and shortcomings, an approach known as Modular Development is
becoming increasingly popular amongst system designs and developers. Modular development is a design
technique that emphasizes separating the functionality of a system into independent, interchangeable modules
or blocks, such that each contains everything necessary to execute only one aspect of the desired functionality.
This approach has been advocated by a number of scholars including Oliver Schoett (1986) of the University
of Edinburgh in his paper titled “Data Abstraction and the Correctness of Modular Programming“[2].

With modular development, the functionality is separated such that modules perform logically discrete
functions, interacting through well-defined interfaces. Instead of creating a monolithic system (where the
smallest component is the whole), several smaller modules are written separately so that, when composed
together, they construct the system. This makes modular designed systems, if built correctly, far more reusable
than a traditional monolithic design, since these modules may then be reused without change in other projects.
This also facilitates the "breaking down" of projects into several smaller projects. Dr. A. Govardhan and Nabil
Mohammed Ali Munassar (2011) add that theoretically, a modularized project is more easily assembled by
large teams, since no team members are creating the whole system, or even need to know about the system as a
whole[3]. They can focus just on the assigned smaller task.

Hence, through the project, we have understood and applied the concepts of Modular Development.
We have used a block-based system to implement the Digital-Up Converter (DUC) in a process that can be
broken down into separate stages to corroborate the modularity of the development process. This is in
accordance of the study conducted by Nie Yang et al (2011) in which they worked on Simulink to implement a
model-based design of a Software-Defined Radio[4]. Following this, a DUC block is obtained that can be used
as an interface for a number of Software-Defined Radio applications in accordance with the principles of
Modular Development. The entire design and implementation is based on a block-based design so that the
individual blocks can be interchangeable for multiple purposes and can be easily upgraded and interfaced with
other blocks/systems.

1.3 OBJECTIVE

The objectives of the project are as follows: -

 To study Software-Defined Radio systems

 To study the characteristics and parameters of Digital-Up Converter
 To study The Family Radio Service frequencies and their technical specifications and applications
 To implement DUC for SDR applications on Simulink
 To segregate the implementation of DUC into separate stages
 To vary the parameters and study the output of DUC
 To obtain DUC block to be used modularly in other SDR applications
  To use the obtained DUC block in FSR system

1.4 SUMMARY

The first chapter of the report provides a brief introduction to FSR systems, SDR, DUC and MBD. It
also enlists the literature survey, motivation and bulleted objectives of the project. The second chapter goes on
to provide a detailed description of SDR and DUC. It provides a detailed explanation of the components/blocks
of DUC and its critical design parameters with a description of the various filters used in the conversion
process. Following this, it gives a detailed description of the technical specifications of FRS. Finally, chapter
two ends with an explanation of the application of DUC in a FRS system. Chapter three provides the
description of the implementation of the project on Simulink. It provides the Simulink models for DUC and
FSR and a description of the blocks used to implement it. It also enlists the input specifications used for each
model and the waveform of each stage of implementation. Following this, the output waveform and the result
is explained. Chapter four contains the conclusion of the project. Lastly, the references are mentioned.
 CHAPTER 2: DESCRIPTION

2.0 Description of SDR Systems

2.0.0 Overview

A basic SDR system may consist of a personal computer equipped with a sound card, other
analog-to-digital-convertors, preceded by some form of RF front end. Significant amounts of signal
processing are handed over to the general-purpose processor, rather than being done in special-
purpose hardware (electronic devices). Such a design produces a radio which can receive and transmit
widely different radio protocols (sometimes referred to as waveforms) based solely on the software
used.

Software radios have significant utility for the military and cell phone services, both of which must
serve a wide variety of changing radio protocols in real time.
In the long term, software-defined radios are expected by proponents like the SDRForum (now The
Wireless Innovative) to become the dominant technology in radio communications. SDRs, along with
software defined antennas are the enablers of the cognitive radios.

2.0.1 Applications

A software-defined radio can be flexible enough to avoid the "limited spectrum"[5] assumptions
of designers of previous kinds of radios, in one or more ways including:
 Spread spectrum and several transmitters to transmit in the same place on the same frequency
with very little interference, typically combined with one or more error detection and corrections
techniques to fix all the errors caused by that interference.
 Software defined antennas adaptively "lock onto" a directional signal, so that receivers can better
reject interference from other directions, allowing it to detect fainter transmissions.
 Cognitive techniques: each radio measures the spectrum in use and communicates that
information to other cooperating radios, so that transmitters can avoid mutual interference by
selecting unused frequencies. Alternatively, each radio connects to a geological database to obtain
information about the spectrum occupancy in its location and, flexibly, adjusts its operating
frequency and/or transmit power not to cause interference to other wireless services.
 Dynamic transmitter power adjustment, based on information communicated from the receivers,
lowering transmit power to the minimum necessary, reducing the near far problem and reducing
interference to others, and extending battery life in portable equipment.
 Wireless mesh networks that every added radio increases total capacity and reduces the power
required at any one node. Each node only transmits loudly enough for the message to hop to the
nearest node in that direction, reducing near far problem and reducing interference to others.
2.1 Description of DUC

2.1.0 Overview

The DUC receives two baseband signals like in-phase and Quadrature phase signals and
modulates these signals into a single real band-pass signal. The Quadrature demodulation is performed
by the multiplication of the in-phase and Quadrature signal with the digital local oscillator. The
addition of these two resulting signals gives a real band pass signal centered on the digital local
oscillator’s frequency with an amplitude and phase offset associated with the complex weight assigned
to that specific channel.

A generic architecture for a DUC is shown in Figure 2.1. A modulator (or other digital
channel signal source) feeds into a set of filters for pulse-shaping and interpolation, and the filter
output is then mixed with a vector of one or more carrier frequencies. Optionally, in advanced
systems, further filtering (interpolation), RF processing (for example, Crest Factor Reduction (CFR),
Digital Pre-Distortion (DPD), Modulation Correction, etc), and frequency[6] translation (to shift to a
passband center frequency) may be performed. Finally, the up-converted signal is converted to an
analog signal for further processing and up-conversion to the RF band.

Figure 2.1: Generic DUC Architecture

2.1.1 Building Blocks for DUC Systems

A number of common building blocks are used to implement narrowband DUC/DDC

systems. These include modules to implement functions such as filtering, carrier generation, and
complex multiplication. These component blocks are described in the following sections, along with a
description of the IP cores or block set library elements provided in System Generator to implement
them.
2.1.1.0 Mixers
One of the basic functions of digital up- or down-conversion systems is
multiplication of a vector of baseband signals with a vector of sinusoidal carriers. This
function is essentially a vector dot product (shown in Equation 1 (the multi-channel mixer as
a vector dot product) for four channels, d0 to d3, modulated onto four carriers, c0 to c3),
with simplification down to a multiplier (real or complex) for single carriers.

0 1 2∗
1 Equation 1.1

Equation 1 Up-mixing uses a dot-product directly (two vectors producing a scalar),

although the implementation of the dot-product normally involves serial operations. Down-
mixing is, in effect, an inverse dot-product, with a scalar (the received signal) multiplying a
vector (the carriers) to produce another vector (the down-shifted channels). Because down-
mixing requires a negative frequency shift, the imaginary component of the complex sinusoid
is negated such that the cosine portion lags the sine portion, rather than leading it, as in the
up-mixing case. To further illustrate the simplest case of a complex multiplier (which may
then be extrapolated to the general case by adding accumulation over the vector of carriers),
let's denote a single sinusoidal carrier as,
= ∅

= ∅
Equation 1.2
Equation 1.3

Where, Br and Bi are the in-phase and quadrature components of the baseband signal
(normally a filtered and up-sampled version of the modulator output for a DUC, or the ADC
sample inputs for a DDC).

Where there is sufficient over-sampling (that is, the clock frequency is an integer
multiple of the sample frequency), these operations can be folded onto the same hardware
resources. In the multi-carrier case, the sinusoidal vector and the baseband data vector can be
multiplied sequentially in element pairs in a TDM fashion, with each result being
accumulated until all carriers have been summed to produce the final combined carrier signal.
This multi-cycle operation can be generalized as a complex multiply-accumulate, or in vector
terminology, a complex vector dot product.

Mixer operations in multi-carrier versions of traditional heterodyne communications

systems are generally two-stage operations, as illustrated in Figure 4. The multiple carrier
baseband signals are initially mixed at a lower sample rate, fmix, to create a baseband
representation of the final transmission band; this is desirable as the resource cost of mixing
increases as the sample rate at the point of mixing increases. As a minimum, the sample rate
must be sufficient to cover the width of the final desired transmission spectral window.
Typical values are 10 MHZ or 20 MHz. At an appropriate point in the signal processing
chain, the entire multi-carrier spectrum is then shifted to an intermediate frequency before
being converted to the analog domain for further band-pass filtering and frequency
conversion to the higher RF frequency for transmission. An alternative zero-IF architecture
with direct conversion from baseband to RF (and vice versa) is also possible.

2.1.1.1 Direct Digital Synthesizer

The clarity of the sinusoid generated by the DDS is crucial to the spectral purity of
the overall DUC output, as the noise floor of the DDS limits the output signal. This noise is
caused by both the phase and amplitude quantization of the frequency synthesis process. A
phase dithering method is often used to improve the spurious-free dynamic range (SFDR) of
the generated sinusoidal waveform by 12 dB without increasing the depth of the look-up
table, by removing the spectral line structure associated with conventional phase truncation
waveform synthesis architecture. Although the dithered DDS has a multiplier-free
architecture, it can consume too many block RAMs for the storage of the sampled sinusoidal
waveform in the high SFDR setting, which results in the deterioration of the design speed. A
Taylor series corrected method can provide even higher SFDR (up to 120 dB) using the same
depth of sinusoidal lookup table. For this example, the Taylor series corrected method was
selected, as the multi-carrier combination requires very high dynamic range and this option
offers an excellent tradeoff of performance versus resource utilization.

2.1.1.2 FIR Filters

Finite Impulse Response (FIR) filters perform a number of filtering operations in
DUC/DDC systems, either separately or by way of a combined filter response implemented
by a single filter. The main functions performed by FIR filters in DUC/DDC circuits are
image rejection (for interpolation), anti-aliasing (for decimation), spectral shaping (for
transmitted data), and channel selection (for received data). Other functions can be performed
by either additional filters or by filter response combining, as required.

2.1.1.2.0 Half-Band Filters

Half-band filter is a FIR filter with its transition region centered at one
fourth of the sampling rate. Fig. 2.3 shows the structure of a Half Band filter (HBF).
In the frequency response of the filter, the end of the pass- band and the beginning of
the stop-band are equally spaced on either side of fs/4.
Figure 2.3: Structure of a Half Band filter

Half-band filter is often used in decimation and interpolation filtering as half

of its time domain coefficients are zero. This helps in achieving the performance of
an M-tap FIR filter, while consuming the computational complexity of (M+1)/2+1
multiplications per filter output sample. Two HBF’s are needed one as a filter and
another as a decimator. The first HB filter acts as a filter to improve the attenuation
of the low frequency signal as well as reduce the sampling frequency. A practical
implementation of the Half Band Filters for decimation and interpolation can be seen
in USRP-N210 and USRP-B100 platforms.

2.1.1.2.1 Hilbert Filters

Hilbert Transform or precisely Hilbert filter finds its application while
realizing the complex bandpass sampling scheme (CBPS). Hilbert transform
introduces a 90-degree phase shift to all the sinusoidal components of the input
signal. In the discrete-time periodic-frequency domain, the Eq specifies the transfer
function of Hilbert transform.

The CBPS can be used to overcome the difficulty of spectral signal

placement in the frequency domain. In the realization of CBPS, the Hilbert filter is
inserted priorto ADC to eliminate the negative frequency components of band-pass
RF signals. By eliminating these, a reduction in the number of signal sets to be
placed can be achieved and a lower sampling rate is sufficient without violating the
Nyquist criterion when compared to Real Band Pass Sampling scheme (RBPS).
 Fig 2.4: Usage of Hilbert transform in the CBPS

2.1.1.2.2 Root-raised-cosine filter

Root-raised-cosine filter (RRC) is prominently used as a matching filter in
the transmitting and receiving sections in a digital communication system to reduce
the ISI. The combined response of two such filters is that of the raised-cosine filter.
The RRC filter is characterized by the roll-off factor and the reciprocal of symbol
rate TS[7]. In order to shape the signal pulse in DDC and DUC applications, RRC
filters are most suitable. In USRP-N210 platform, the RRC filter is used to shape the
output signal. These RRC filters can also be used to down sample or up sample the
incoming signal by a factor of 2.

2.1.1.3 CIC Filters

Probably the most significant building block component for narrowband DUC/DDC
implementation is the Cascaded Integrator Comb (CIC) filter. CIC filters (or Hogenauer
filters [6]) are a unique class of digital filters that present a computationally efficient way of
implementing narrowband low-pass filters for anti-aliasing or image rejection in high rate
change systems.

CIC filters use only delays and summation units and do not require multiplication
operations as in an FIR filter. The filters are constructed from Integrator and Comb filter
stages. A rate change is always involved in CIC filtering [8], and the filter response exhibits
linear phase.

CIC filters can efficiently perform either decimation or interpolation, with two
complementary structures being employed to implement these functions. Decimation requires
a cascade of a number of integrator units, followed by a down-sampling stage and finally a
cascade of the comb filter units. Conversely, interpolation cascades several comb filters with
an up-sampler and several integrators.
 The frequency response of a CIC filter exhibits a sinc -like function. Nulls appear at
fixed intervals, with lobes of decreasing magnitude as the frequency increases. It is a general
rule-of-thumb that the passband should never be more than 25% of the span of the main lobe
of the CIC response; the main reason for this is the fact that the nulls in the frequency
response only have a finite width, and if a wide passband is used, then a detrimental level of
aliasing or imaging can occur. The frequency response of CIC filters is affected by several
parameters: the rate change, R, the number of stages, N, which is the same for both
integrators and combs, and the differential delay of the comb unit, M. Differential delay, M,
affects the location of nulls at any given rate change value and increases attenuation levels
generally at all lobes in the response. Varying the rate change value, R, adjusts the null
positions up or down accordingly without having much effect on the attenuation of each lobe.
Increasing the number of stages increases attenuation of the lobes without shifting null
positions; this is usually the main method used to increase attenuation to the desired level by
any design algorithm.

One important consideration in the use of CIC filters is the problem of “passband
droop.” In almost all systems, a flat passband in the magnitude frequency response is
desirable to prevent signal distortion. However, as described earlier, CIC filters exhibit a sinc-
like frequency response[9], which can decay appreciably even within the passband when
there are many stages or a high rate change. Therefore, it is necessary to cascade the CIC
filter with an FIR filter which compensates for this droop with an inverse-sinc frequency
response.

Figure 2.7: Example of CIC Magnitude Response Plot

 Figure 2.8: CIC Passband Aliasing

2.2 Critical Design Parameters for DUC systems

2.2.0 Total Rate Change

The total rate change through the DUC/DDC system is almost certainly the most important
parameter to be considered. Where the total rate change is low (e.g., less than 32), the interpolation or
decimation stages may be achieved effectively with a cascade of FIR filters; where the total rate
change is high, FIR filters would not be the most efficient choice and CIC filters should be considered
(in combination with FIR filters) as a more efficient alternative. This scenario is described in the
examples in this application note.

2.2.1 Clock Rate

The clock rate of the circuit determines how many operations can be performed in a single
sample period, which in turn affects how much hardware folding can be achieved by each function.
This ratio alters as the signals proceed down the processing chain; at the highest sample rates, multiple
modules may be required to process the data samples.

2.2.2 Number of Carriers or Subcarriers

The number of carriers to be supported has a significant bearing on architecture choices on

several levels. At the system level, single carrier systems or those with small numbers of carriers (or
subcarriers) are best suited to the architecture described in this Application Note; larger numbers of
carriers or subcarriers may be better suited to channelizer architectures based on FFT techniques. At a
module level, the number of carriers is related to the number of data channels implemented in each
functional block, and a higher carrier count reduces the level of hardware folding achievable.

2.2.3 Number of Channels

Although it is often the case, the number of channels required is not necessarily directly
related to the same as the number of carriers. For instance, in MRI systems, the center frequencies are
the same for each channel; therefore, a single sinusoid can be used to mix with multiple channels of
sample data.

2.2.4 Passband Width

The passband width refers to the spread of possible frequencies to which the user may wish to
up-convert the modulated data signals. For instance, this might refer to the entire GSM transmission
band, or the spectral range of an MRI machine. In multi-carrier systems, this parameter determines the
minimum sample rate that can be used for mixing channel data, as the sample rate must be sufficient
to cover the frequency spread. The passband width also has a bearing on digital pre-distortion
algorithm implementations, which usually operate at a sample rate which is at least an integer multiple
(4x or 5x) above the passband width.

One important implication of this parameter for this application note relates to the bulk rate
change of the CIC filters which are used in the narrowband system examples. As stated above, mixing
must occur at a sample rate which is greater than the passband width; however, with CIC filters, the
input sample frequency may be too low while, due to the large rate change, the output sample rate
may be higher than required and, therefore, utilizes more resources than are strictly necessary for the
mixer implementation, due to a low number of clocks per sample period.

2.2.5 Modulation Scheme

The modulation scheme can have an effect upon the input rate of the DUC and the output rate
of the DDC. Some modulators are over-sampled by nature of their implementation (see the GMSK
example, later) and this reduces the overall rate change of the DUC. Some demodulation schemes
require an over-sampled version of the data to provide[10] effective demodulation of the symbol or to
allow the possibility of timing recovery, which again reduces overall rate change.

Another issue with modulation schemes is the supported symbol rates. Where multiple
symbol rates are to be supported, a greater degree of flexibility is required in the processing chain (to
match up sample rates), and therefore the bulk rate changes of a CIC filter can be a disadvantage. FIR
filters are more suitable for such complex DUC applications.
 2.2.6 Supported Standards

For wireless communications systems where multiple air standards are to be supported in the
same DUC system, the system needs greater flexibility to match up sample rates to a common rate for
combination. Fractional re-sampling may provide a suitable solution for rate matching in such
complex systems. This application note addresses only single air standard solutions.

2.3 Description of FRS

2.3.0 Technical specifications of FRS systems

FRS radios use narrow-band frequency modulation (NBFM) with a maximum

deviation of 2.5 kilohertz. The channels are spaced at 12.5 kilohertz intervals.

 After May 18, 2017, FRS radios are limited to 2 Watts on channel 1-7 and channels
15-22. Previously, FRS radios were limited to 500 milliwatts. Channels 1 to 7 are
shared with low-power interstitial channels of General Mobile Radio Services
(GMRS).

 FRS radios frequently have provisions for using sub-audible tone squelch ( CTSS and
DTS) codes, filtering out unwanted chatter from other users on the same frequency.
Although these codes are sometimes called "privacy codes" or "private line codes"
(PL codes), they offer no protection from eavesdropping and are only intended to
help share busy channels

 FRS stations on channels 1 through 7 may communicate with GMRS stations.

 All equipment used on FRS must be type accepted according to FCC regulations.
Radios are not type-accepted for use in this service if they exceed limits on power
output, have a detachable antenna or for other reasons.

 FRS radios must use only permanently attached antennas, such as walkie-talkies;
there are also table-top FRS "base station" radios that have whip antennas. This
limitation intentionally restricts the range of communications, allowing greatest use
of the available channels. The use of duplex radio repeaters and interconnects to the
telephone networks are prohibited under FRS rules, unlike other radio services.

 FRS manufacturers generally claim exaggerated range. The presence of large

buildings, trees, etc., will reduce range. Under exceptional conditions, (such as
hilltop to hilltop) communication is possible over 60 km (37 mi) or more, but that is
rare. Under normal conditions, with line of sight blocked by a few buildings or trees,
FRS has an actual range of about 0.5 to 1.5 km (0.3 to 1 mile).
2.3.1 List of FSR channels

Table 2.1: List of FRS Channels compared to GMRS

Channel
Frequency (MHz) FRS EIRP Restriction GMRS EIRP Restriction

1 462.5625 Up to 2 watt Up to 5 watts

2 462.5875 Up to 2 watt Up to 5 watts

3 462.6125 Up to 2 watt Up to 5 watts

4 462.6375 Up to 2 watt Up to 5 watts

5 462.6625 Up to 2 watt Up to 5 watts

6 462.6875 Up to 2 watt Up to 5 watts

7 462.7125 Up to 2 watt Up to 5 watts

8 467.5625 Up to 0.5 watt Up to 0.5 watt

9 467.5875 Up to 0.5 watt Up to 0.5 watt

10 467.6125 Up to 0.5 watt Up to 0.5 watt

11 467.6375 Up to 0.5 watt Up to 0.5 watt

12 467.6625 Up to 0.5 watt Up to 0.5 watt

 13 467.6875 Up to 0.5 watt Up to 0.5 watt

14 467.7125 Up to 0.5 watt Up to 0.5 watt

15 462.5500 Up to 2 watt Up to 50 watts

16 462.5750 Up to 2 watt Up to 50 watts

17 462.6000 Up to 2 watt Up to 50 watts

18 462.6250 Up to 2 watt Up to 50 watts

19 462.6500 Up to 2 watt Up to 50 watts

20 462.6750 Up to 2 watt Up to 50 watts

21 462.7000 Up to 2 watt Up to 50 watts

22 462.7250 Up to 2 watt Up to 50 watts

 EIRP = Effective Isotropic Radiated Power

 GMRS has other exclusive channels
 FRS channels 8-14 are exclusively FRS with no detachable antenna such as found on GMRS
equipment. No FRS unit shall exceed .5 watt (EIRP) Effective Isotropic Radiated Power on
channels 8-14. FRS Channels 15-22 are shared with GMRS also under 2 watt EIRP limit.
However, if the device includes any of the following channels (467.5500, 467.5750, 467.6000,
467.6250, 467.6500, 467.6750, 467.7000, and 467.7250 MHz) a GMRS license is required. The
only benefit of a GMRS license is the ability to use a repeater and communicate longer distances.

`
2.4 Application of DUC in FRS systems (Transmitter)

2.4.0 Introduction

DUC forms an integral component of the FRS implementation. For the purpose of the project,
DUC has been first implemented using Simulink blocks. Following this, the DUC functionality is used
to implement a FRS transmitter.

2.4.1 Introduction to SIMULINK

Simulink, developed by MathsWorks, is a graphical programming environment for modeling,

simulating and analyzing multidomain dynamical systems. Its primary interface is a graphic block and
diagramming tool and a customizable set of block libraries. It offers tight integration with the rest of
the MATLAB environment and can either drive MATLAB or be scripted from it. Simulink is widely
used in automatic control and digital signal processing for multidomain simulation and Model based
design.

2.4.2 Design of DUC

The DUC SIMULINK implementation consists of a FIR interpolator, a CIC compensator, and
a CIC interpolator. FIR interpolator can be bypassed depending on how DUC block parameters are
set.

Figure 2.8: Block Diagram of DUC

2.4.3 Design of FRS

The setup for Family Radio Service shown above can be modeled in Simulink as follows.

Figure 2.9: Block Diagram of FRS Transmitter

 CHAPTER 3: IMPLEMENTATION AND OUTPUT

3.0 Implementation of DUC on SIMULINK

3.0.0 Specifications of DUC

Table 3.1: Specifications of DUC

3.0.1 Blocks used for SIMULINK Implementation of DUC

3.0.1.0 Sine wave Block

Library: Sources
Symbol:

Description: The Sine Wave block generates a multichannel real or complex sinusoidal
signal, with independent amplitude, frequency, and phase in each output channel. A real
sinusoidal signal is generated when the Output complexity parameter is set to Real, and is
defined by an expression of the type

y=Asin(2πft+ϕ) Equation 3.1

3.0.1.1 Up Sample Block

Library: Signal Operations

Symbol:

Description: The Upsample block resamples each channel of the Mi-by-N input at a rate L
times higher than the input sample rate by inserting L-1 zeros between consecutive samples.
You specify the integer L in the Upsample factor parameter. The Sample offset parameter, D,
allows you to delay the output samples by an integer number of sample periods. Doing so
enables you to select any of the L possible output phases. The value you specify for the
Sample offset parameter must be in the range 0≤D<(L−1).

3.0.1.2 FIR Half-Band Interpolator

Library: Filtering / Filter Designs

Symbol:

Description: The FIR Halfband Interpolator block performs interpolation of the input signal
by a factor of two. The block uses an FIR equiripple design to construct the halfband filters.
To filter the input, the block uses an efficient polyphase implementation. The implementation
takes advantage of the zero-valued coefficients of the FIR halfband filter, making one of the
polyphase branches a delay. You can also use the block to implement the synthesis portion of
a two-band filter bank to synthesize a signal from lowpass and highpasssubbands.

3.0.1.2 CIC Compensation Interpolator

Library: Filtering / Filter Designs

Symbol:

Description: The CIC Compensation Interpolator block uses an FIR polyphase interpolator as
the compensation filter. CIC compensation interpolators are multirate FIR filters that can be
cascaded with CIC interpolators to mitigate the drawbacks of the CIC filters.
 CIC interpolation filters are used in areas that require high interpolation. These filters are
popular in ASICs and FPGAs, since they do not have any multipliers. CIC filters have two
drawbacks:

 CIC filters have a magnitude response that causes a droop in the passband region. This
magnitude response is:
 abssin(Mω2)sin(ω2)n
o M — Differential delay
o n — Number of stages
o ω — Normalized angular frequency
 CIC filters have a wide transition region.

3.0.1.3 CIC Interpolation

Library: Filtering / Multirate Filters

Symbol:

Description: The CIC Interpolation block performs a sample rate increase (interpolation) on
an input signal by an integer factor. Cascaded Integrator-Comb (CIC) filters are a class of
linear phase FIR filters that consist of a comb part and an integrator part.

The transfer function of a CIC interpolator filter is

H(z)=HIN(z)HCN(z)=(1−z−RM)N(1−z−1)N=[RM−1k=0z−k]NEquation 3.2

Where,

 HI is the transfer function of the integrator part of the filter.

 HC is the transfer function of the comb part of the filter.
 N is the number of sections. The number of sections in a CIC filter is defined as the
number of sections in either the comb part or the integrator part of the filter. This value
does not represent the total number of sections throughout the entire filter.
 R is the interpolation factor.
 M is the differential delay.
3.0.1.4 Normalization Block

Library: Math Functions / Math Operations

Symbol:

Description: The Normalization block independently normalizes each row, column, or vector
of the specified dimension of the input. The block accepts both fixed- and floating-point
signals in the squared 2-norm mode, but only floating-point signals in the 2-norm mode. The
output always has the same dimensions as the input.

This block treats an arbitrarily dimensioned input U as a collection of vectors oriented along
the specified dimension. The block normalizes these vectors by either their norm or the
square of their norm.

For example, consider a 3-dimensional input U(i,j,k) and assume that you want to normalize
along the second dimension. First, define the 2-dimensional intermediate quantity V(i,k) such
that each element of V is the norm of one of the vectors in U:

V(i,k)=(Jj=1U2(i,j,k))1/2 Equation 3.3

Given V, the output of the block Y(i, j,k) in 2-norm mode is

Y(i,j,k)=U(i,j,k)V(i,k)+b

In squared 2-norm mode, the block output is

Y(i,j,k)=U(i,j,k)V(i,k)2+b

The normalization bias, b, is typically chosen to be a small positive constant (for example, 1e-
10) that prevents potential division by zero.

3.0.1.5 Complex to Real-Imag Block

Library: Math Operations

Symbol:

Description: The Real-Imag to Complex block converts real and/or imaginary inputs to a
complex-valued output signal.
The inputs can both be arrays (vectors or matrices) of equal dimensions, or one input can be
an array and the other a scalar. If the block has an array input, the output is a complex array of
the same dimensions. The elements of the real input map to the real parts of the
corresponding complex output elements. The imaginary input similarly maps to the imaginary
parts of the complex output signals. If one input is a scalar, it maps to the corresponding
component (real or imaginary) of all the complex output signals.

3.0.1.6 Scope Block

Library: Simulink / Sinks

Symbol:

Description: The Simulink Scope block and DSP System Toolbox Time Scope block display
time domain signals.
3.0.2 Implementation

3.0.2.0 Simulink Model of DUC

Figure 3: Simulink Model of DUC

3.0.2.1 Simulation of each stage of model

3.0.2.1.0 Input

SPECIFICATIONS: -

Figure 3.2: Specifications of Input to DUC

OUTPUT:-

Figure 3.3: Input Waveform

3.0.2.1.1 Half-Band Filter

OUTPUT: -

Figure 3.4: Half-Band Filter Waveform

3.0.2.1.2 CIC Interpolation

OUTPUT:-

Figure 3.5: CIC Interpolation Waveform

3.0.2.1.3 Output of DUC

Figure 3.6: Output Waveform of DUC

3.1 Implementation of DUC in FRS

3.1.0 Principle

The transmitter section of FRS can be implemented in Simulink using DUC. For the
complete FRS system, it is necessary to couple the transmitter with a receiver that employs a Digital
Down Convertor. The design of the implementation has been previously listed.

3.1.1 Implementation

3.1.1.0 Specifications

Figure 3.7: Specifications of DUC for FRS System

3.1.1.1 Implementation model

Figure 3.8: Simulink Model of FRS

3.1.1.2 Input Spectrum

Figure 3.9: Spectrum of Baseband signal

42
3.1.1.3 Output Spectrum

Figure 3.10: Spectrum of Passband Signal

 CHAPTER 4: HDL CODE GENERATION

4.0 Introduction to HDL

HDL or Hardware Description Languages are specialized programming languages used to describe the
structure and behavior of electronic circuits. They are an integral part of the Electronic Design
Automation (EDA) and are used for complex systems such as ASIC’s, PLD’s, FPGA’s etc.
A hardware description language looks much like a programming language such as C; it is a textual
description consisting of expressions, statements and control structures. One important difference
between most programming languages and HDLs is that HDLs explicitly include the notion of time.
Due to the exploding complexity of digital electronic circuits since the 1970s, circuit designers
needed digital logic descriptions to be performed at a high level without being tied to a specific
electronic technology, such as CMOS or BJT. HDLs were created to implement register-transfer
level abstraction, a model of the data flow and timing of a circuit.
There are two major hardware description languages: VHDL and Verilog. There are different types of
description in them "dataflow, behavioral and structural".

4.1 Generation of an HDL compatible Simulink design

4.1.0 HDL Code Generator

In order to generate a Hardware Description Language code from a Simulink design
it is important to first make the design compatible with HDL. This can be done
through specialized Simulink blocks which are compatible with HDL code
generation. There’s a provision of generating HDL compatible designs in Simulink
through a supplement of Simulink called HDL code generator.

Figure 4.0: HDL Code Generator

4.1.1 Simulink Compatible library
The HDL code generator comprises of a HDL compatible Simulink library. Only the
components provided in the HDL Simulink Library can be used to generate the HDL
code from a Simulink design. A part of the HDL compatible Simulink library is
shown below.

Figure 4.1: HDL Compatible Simulink Library

Using the library shown above an HDL compatible design for DUC was constructed.
The following is the HDL compatible Simulink design for the Digital-up Convertor.
 Figure 4.2 Simulink design for DUC using HDL code generator

4.2 Generation of the HDL code

4.2.0 Simulink design to HDL code

After constructing the HDL compatible design using HDL code generator, the HDL code can
be easily generated. The code is generated in the form of three VHDL files
 A VHDL module- It comprises of the general functioning and input-output
definitions of the system.
 A VHDL package- This contains all the I/O definitions, subprograms and
constraints.
 A VHDL terminal-count file- This file comprises of all the timing constraints
pertaining to the system.

4.2.1 VHDL files generated for DUC

These are the VHDL files which were generated for the DUC designed using Simulink.

4.2.1.0 VHDL module

1. LIBRARY IEEE;
2. USE IEEE.std_logic_1164.ALL;
3. USE IEEE.numeric_std.ALL;
4. USE work.final_pkg.ALL;
5.
6. ENTITY final IS
7. PORT( clk : IN std_logic;
8. reset : IN std_logic;
9. clk_enable : IN std_logic
10. );
11. END final;
12.
13. ARCHITECTURE rtl OF final IS
14.
15. -- Component Declarations
16. COMPONENT final_tc
17. PORT( clk : IN std_logic;
18. reset : IN std_logic;
19. clk_enable : IN std_logic;
20. enb_1_120_0 : OUT std_logic;
21. enb_1_120000_0 : OUT std_logic
22. );
23. END COMPONENT;
24. FOR ALL : final_tc
25. USE ENTITY work.final_tc(rtl);
26.
27. -- Constants
28. CONSTANT C_NCO_PHASE_INCREMENT : signed(15 DOWNTO 0) :=
29. "0000000001100100"; -- sfix16
30. CONSTANT C_NCO_ADDR_MAX : unsigned(10 DOWNTO 0) :=
31. "10000000000"; -- ufix11_E4
32. CONSTANT C_NCO_EXTRA_QTR_WAVE_VAL : signed(15 DOWNTO 0) :=
33. "0100000000000000"; -- sfix16_En14
34. CONSTANT C_NCO_90DEG : unsigned(1 DOWNTO 0) :=
35. "01"; -- ufix2_E14
36. SIGNAL enb_1_120000_0 : std_logic;
37. SIGNAL enb_1_120_0 : std_logic;
38. SIGNAL NCO2_out1 : signed(15 DOWNTO 0); -- sfix16_En14
39. SIGNAL NCO2_out2 : signed(15 DOWNTO 0); -- sfix16_En14
40. SIGNAL Sine_Wave1_out1 : signed(15 DOWNTO 0); -- sfix16_En14
41. SIGNAL accumulator_reg : signed(15 DOWNTO 0); -- sfix16
42. SIGNAL accumulator_input : signed(15 DOWNTO 0); -- sfix16
43. SIGNAL add_temp : signed(16 DOWNTO 0); -- sfix17
44. SIGNAL dithered_phase : signed(15 DOWNTO 0); -- sfix16
45. SIGNAL pn_reg : unsigned(18 DOWNTO 0); -- ufix19
46. SIGNAL pn_out : unsigned(3 DOWNTO 0); -- ufix4
47. SIGNAL pn_xorout : std_logic_vector(0 TO 3); -- boolean [4]
48. SIGNAL pn_newvalue : vector_of_unsigned19(0 TO 4); -- ufix19 [5
]
49. SIGNAL pn_value_shifted : vector_of_unsigned18(0 TO 3); -- ufix18_E1
[4]
50. SIGNAL add_temp_1 : signed(16 DOWNTO 0); -- sfix17
51. SIGNAL quantized_phase : unsigned(11 DOWNTO 0); -- ufix12_E4
52. SIGNAL lutaddr_quadrant1 : unsigned(9 DOWNTO 0); -- ufix10_E4
53. SIGNAL lutaddr_quadrant2 : unsigned(9 DOWNTO 0); -- ufix10_E4
54. SIGNAL sub_temp : unsigned(11 DOWNTO 0); -- ufix12_E4
55. SIGNAL sin_extra_value_cmp_in : unsigned(10 DOWNTO 0); -- ufix11_E4
56. SIGNAL sin_inv_hwoutput : std_logic;
57. SIGNAL sin_addr_mux_sel : std_logic;
58. SIGNAL sinlutaddr : unsigned(9 DOWNTO 0); -- ufix10_E4
59. SIGNAL sinlut_output : signed(15 DOWNTO 0); -- sfix16_En14
60. SIGNAL sin_hw : signed(15 DOWNTO 0); -- sfix16_En14
61. SIGNAL sinlut_output_unsigned : unsigned(14 DOWNTO 0); -- ufix15_En14
62. SIGNAL sin_hw_inv : signed(15 DOWNTO 0); -- sfix16_En14
63. SIGNAL unaryminus_temp : signed(16 DOWNTO 0); -- sfix17_En14
64. SIGNAL cos_extra_value_cmp_in : unsigned(10 DOWNTO 0); -- ufix11_E4
65. SIGNAL cos_inv_hwoutput : std_logic;
66. SIGNAL cos_addr_mux_sel : std_logic;
67. SIGNAL quantized_phase_2msbs : unsigned(1 DOWNTO 0); -- ufix2_E14
68. SIGNAL cos_control_bits : unsigned(1 DOWNTO 0); -- ufix2_E14
69. SIGNAL add_temp_2 : unsigned(2 DOWNTO 0); -- ufix3_E14
70. SIGNAL coslutaddr : unsigned(9 DOWNTO 0); -- ufix10_E4
71. SIGNAL coslut_output : signed(15 DOWNTO 0); -- sfix16_En14
72. SIGNAL cos_hw : signed(15 DOWNTO 0); -- sfix16_En14
73. SIGNAL coslut_output_unsigned : unsigned(14 DOWNTO 0); -- ufix15_En14
74. SIGNAL cos_hw_inv : signed(15 DOWNTO 0); -- sfix16_En14
75. SIGNAL unaryminus_temp_1 : signed(16 DOWNTO 0); -- sfix17_En14
76. SIGNAL address_cnt : unsigned(3 DOWNTO 0); -- ufix4
77. BEGIN
78. u_final_tc : final_tc
79. PORT MAP( clk => clk,
80. reset => reset,
81. clk_enable => clk_enable,
82. enb_1_120_0 => enb_1_120_0,
83. enb_1_120000_0 => enb_1_120000_0
84. );
85. add_temp <= resize(accumulator_reg, 17) + resize(C_NCO_PHASE_INCREMENT, 17);
86. accumulator_input <= add_temp(15 DOWNTO 0);
87. NCO2_phase_accumulator_temp_process3 : PROCESS (clk, reset)
88. BEGIN
89. IF reset = '1' THEN
90. accumulator_reg <= (OTHERS => '0');
91. ELSIF clk'event AND clk = '1' THEN
92. IF enb_1_120000_0 = '1' THEN
93. accumulator_reg <= accumulator_input;
94. END IF;
95. END IF;
96. END PROCESS NCO2_phase_accumulator_temp_process3;
97. pn_newvalue(0) <= pn_reg;
98. pn_xorout(0) <= pn_newvalue(0)(0) XOR pn_newvalue(0)(14) XOR pn_newvalue(0)(17) XOR p
n_newvalue(0)(18);
99.
100. pn_value_shifted(0) <= pn_newvalue(0)(18 DOWNTO 1);
101.
102. pn_newvalue(1) <= pn_xorout(0) & pn_value_shifted(0);
103.
104. pn_out(3) <= pn_newvalue(0)(0);
105.
106. pn_xorout(1) <= pn_newvalue(1)(0) XOR pn_newvalue(1)(14) XOR pn_newvalue(1)
(17) XOR pn_newvalue(1)(18);
107.
108. pn_value_shifted(1) <= pn_newvalue(1)(18 DOWNTO 1);
109.
110. pn_newvalue(2) <= pn_xorout(1) & pn_value_shifted(1);
111.
112. pn_out(2) <= pn_newvalue(1)(0);
113.
114. pn_xorout(2) <= pn_newvalue(2)(0) XOR pn_newvalue(2)(14) XOR pn_newvalue(2)
(17) XOR pn_newvalue(2)(18);
115.
116. pn_value_shifted(2) <= pn_newvalue(2)(18 DOWNTO 1);
117.
118. pn_newvalue(3) <= pn_xorout(2) & pn_value_shifted(2);
119.
120. pn_out(1) <= pn_newvalue(2)(0);
121.
122. --**stage 4
123. pn_xorout(3) <= pn_newvalue(3)(0) XOR pn_newvalue(3)(14) XOR pn_newvalue(3)
(17) XOR pn_newvalue(3)(18);
124.
125. pn_value_shifted(3) <= pn_newvalue(3)(18 DOWNTO 1);
126.
127. pn_newvalue(4) <= pn_xorout(3) & pn_value_shifted(3);
128.
129. pn_out(0) <= pn_newvalue(3)(0);
130.
131. PN_generation_temp_process4 : PROCESS (clk, reset)
132. BEGIN
133. IF reset = '1' THEN
134. pn_reg <= to_unsigned(1, 19);
135. ELSIF clk'event AND clk = '1' THEN
136. IF enb_1_120000_0 = '1' THEN
137. pn_reg <= pn_newvalue(4);
138. END IF;
139. END IF;
140. END PROCESS PN_generation_temp_process4;
141.
142. add_temp_1 <= resize(signed( '0' & pn_out), 17) + resize(accumulator_reg, 17);

143. dithered_phase <= add_temp_1(15 DOWNTO 0);

144. quantized_phase <= unsigned(dithered_phase(15 DOWNTO 4));
145.
146. lutaddr_quadrant1 <= quantized_phase(9 DOWNTO 0);
147.
148. sub_temp <= resize(C_NCO_ADDR_MAX, 12) - resize(lutaddr_quadrant1, 12);
149. lutaddr_quadrant2 <= sub_temp(9 DOWNTO 0);
150.
151. sin_inv_hwoutput <= quantized_phase(11);
152.
153. sin_addr_mux_sel <= quantized_phase(10);
154.
155. sin_extra_value_cmp_in <= quantized_phase(10 DOWNTO 0);
156.
157. sinlutaddr <= lutaddr_quadrant1 WHEN ( sin_addr_mux_sel = '0' ) ELSE
158. lutaddr_quadrant2;
159.
160. PROCESS(sinlutaddr)
161. BEGIN
162. CASE sinlutaddr IS
163. WHEN "0000000000" => sinlut_output_unsigned <= "000000000000000";
164. WHEN "0000000001" => sinlut_output_unsigned <= "000000000011001";
165. WHEN "0000000010" => sinlut_output_unsigned <= "000000000110010";
166. ~
167. ~
168. ~
169. ~
170. WHEN "1111111110" => sinlut_output_unsigned <= "100000000000000";
171. WHEN "1111111111" => sinlut_output_unsigned <= "100000000000000";
172. WHEN OTHERS => sinlut_output_unsigned <= "100000000000000";
173. END CASE;
174. END PROCESS;
175.
176. sinlut_output <= signed(resize(sinlut_output_unsigned, 16));
177.
178.
179. -- mux in sin(pi/2) for efficient ROM usage
180.
181. sin_hw <= sinlut_output WHEN ( sin_extra_value_cmp_in /= to_unsigned(1024, 11)
) ELSE
182. C_NCO_EXTRA_QTR_WAVE_VAL;
183.
184.
185. -- invert halfwave sin to create a fullwave sin
186.
187. unaryminus_temp <= ('0' & sin_hw) WHEN sin_hw = "1000000000000000"
188. ELSE -resize(sin_hw,17);
189. sin_hw_inv <= unaryminus_temp(15 DOWNTO 0);
190.
191. NCO2_out1 <= sin_hw WHEN ( sin_inv_hwoutput = '0' ) ELSE
192. sin_hw_inv;
193.
194.
195. -- generation of Cosine part
196.
197. quantized_phase_2msbs <= quantized_phase(11 DOWNTO 10);
198.
199. add_temp_2 <= resize(quantized_phase_2msbs, 3) + resize(C_NCO_90DEG, 3);
200. cos_control_bits <= add_temp_2(1 DOWNTO 0);
201.
202. cos_inv_hwoutput <= cos_control_bits(1);
203.
204. cos_addr_mux_sel <= cos_control_bits(0);
205.
206. cos_extra_value_cmp_in <= cos_control_bits(0) & lutaddr_quadrant1;
207.
208. coslutaddr <= lutaddr_quadrant1 WHEN ( cos_addr_mux_sel = '0' ) ELSE
209. lutaddr_quadrant2;
210.
211. PROCESS(coslutaddr)
212. BEGIN
213. CASE coslutaddr IS
214. WHEN "0000000000" => coslut_output_unsigned <= "000000000000000";
215. WHEN "0000000001" => coslut_output_unsigned <= "000000000011001";
216. WHEN "0000000010" => coslut_output_unsigned <= "000000000110010";
217. ~
218. ~
219. ~
220. ~
221. WHEN "1111111110" => coslut_output_unsigned <= "100000000000000";
222. WHEN "1111111111" => coslut_output_unsigned <= "100000000000000";
223. WHEN OTHERS => coslut_output_unsigned <= "100000000000000";
224. END CASE;
225. END PROCESS;
226.
227. coslut_output <= signed(resize(coslut_output_unsigned, 16));
228.
229.
230. -- mux in sin(pi/2) for efficient ROM usage
231.
232. cos_hw <= coslut_output WHEN ( cos_extra_value_cmp_in /= to_unsigned(1024, 11)
) ELSE
233. C_NCO_EXTRA_QTR_WAVE_VAL;
234.
235.
236. -- invert halfwave cos to create a fullwave cos
237.
238. unaryminus_temp_1 <= ('0' & cos_hw) WHEN cos_hw = "1000000000000000"
239. ELSE -resize(cos_hw,17);
240. cos_hw_inv <= unaryminus_temp_1(15 DOWNTO 0);
241.
242. NCO2_out2 <= cos_hw WHEN ( cos_inv_hwoutput = '0' ) ELSE
243. cos_hw_inv;
244.
245.
246. -- ADDRESS COUNTER
247. Sine_Wave1_addrcnt_temp_process5 : PROCESS (clk, reset)
248. BEGIN
249. IF reset = '1' THEN
250. address_cnt <= to_unsigned(0, 4);
251. ELSIF clk'event AND clk = '1' THEN
252. IF enb_1_120_0 = '1' THEN
253. IF address_cnt = to_unsigned(9, 4) THEN
254. address_cnt <= to_unsigned(0, 4);
255. ELSE
256. address_cnt <= address_cnt + 1;
257. END IF;
258. END IF;
259. END IF;
260. END PROCESS Sine_Wave1_addrcnt_temp_process5;
261.
262. -- FULL WAVE LOOKUP TABLE
263. PROCESS(address_cnt)
264. BEGIN
265. CASE address_cnt IS
266. WHEN "0000" => Sine_Wave1_out1 <= "0000000000000000";
267. WHEN "0001" => Sine_Wave1_out1 <= "0010010110011110";
268. WHEN "0010" => Sine_Wave1_out1 <= "0011110011011110";
269. WHEN "0011" => Sine_Wave1_out1 <= "0011110011011110";
270. WHEN "0100" => Sine_Wave1_out1 <= "0010010110011110";
271. WHEN "0101" => Sine_Wave1_out1 <= "0000000000000000";
272. WHEN "0110" => Sine_Wave1_out1 <= "1101101001100010";
273. WHEN "0111" => Sine_Wave1_out1 <= "1100001100100010";
274. WHEN "1000" => Sine_Wave1_out1 <= "1100001100100010";
275. WHEN "1001" => Sine_Wave1_out1 <= "1101101001100010";
276. WHEN OTHERS => Sine_Wave1_out1 <= "1101101001100010";
277. END CASE;
278. END PROCESS;
279. END rtl;

4.2.1.1 VHDL package

1. LIBRARY IEEE;
2. USE IEEE.std_logic_1164.ALL;
3. USE IEEE.numeric_std.ALL;
4. PACKAGE final_pkg IS
5. TYPE vector_of_unsigned19 IS ARRAY (NATURAL RANGE <>) OF unsigned(18 DOWNTO 0);
6. TYPE vector_of_unsigned18 IS ARRAY (NATURAL RANGE <>) OF unsigned(17 DOWNTO 0);
7. END final_pkg;

4.2.1.2 VHDL terminal-count file

1. LIBRARY IEEE;
2. USE IEEE.std_logic_1164.ALL;
3. USE IEEE.numeric_std.ALL;
4.
5. ENTITY final_tc IS
6. PORT( clk : IN std_logic;
7. reset : IN std_logic;
8. clk_enable : IN std_logic;
9. enb_1_120_0 : OUT std_logic;
10. enb_1_120000_0 : OUT std_logic
11. );
12. END final_tc;
13.
14.
15. ARCHITECTURE rtl OF final_tc IS
16.
17. -- Signals
18. SIGNAL count1000 : unsigned(9 DOWNTO 0); -- ufix10
19. SIGNAL phase_all : std_logic;
20. SIGNAL phase_0 : std_logic;
21. SIGNAL phase_0_tmp : std_logic;
22.
23. BEGIN
24. Counter1000 : PROCESS (clk, reset)
25. BEGIN
26. IF reset = '1' THEN
27. count1000 <= to_unsigned(1, 10);
28. ELSIF clk'event AND clk = '1' THEN
29. IF clk_enable = '1' THEN
30. IF count1000 = to_unsigned(999, 10) THEN
31. count1000 <= to_unsigned(0, 10);
32. ELSE
33. count1000 <= count1000 + 1;
34. END IF;
35. END IF;
36. END IF;
37. END PROCESS Counter1000;
38.
39. phase_all <= '1' WHEN clk_enable = '1' ELSE '0';
40.
41. temp_process1 : PROCESS (clk, reset)
42. BEGIN
43. IF reset = '1' THEN
 44. phase_0 <= '0';
45. ELSIF clk'event AND clk = '1' THEN
46. IF clk_enable = '1' THEN
47. phase_0 <= phase_0_tmp;
48. END IF;
49. END IF;
50. END PROCESS temp_process1;
51.
52. phase_0_tmp <= '1' WHEN count1000 = to_unsigned(999, 10) AND clk_enable = '1' ELSE '0
';
53.
54. enb_1_120_0 <= phase_all AND clk_enable;
55.
56. enb_1_120000_0 <= phase_0 AND clk_enable;
57.
58. END rtl;

CHAPTER 5: TRANSLATION OF THE HDL CODE TO XILINX

SYSTEM GENERATOR
5.0 Introduction to Xilinx System Generator
Xilinx System Generator is an FPGA programming tool provided by Xilinx. It is specifically focussed on
Xilinx FPGAs, enabling the developers to work in Simulink environment and to generate parametrized cores
particularly optimized for Xilinx FPGAs. The tool comes built in with Xilinx ISE Design Suite (System
Edition) and Xilinx Vivado HL (System Edition). By default, the Xilinx Blockset contains over 90 DSP
blocks, ranging from simple adders, multipliers etc. to complex blocks such as Forward Error Correction
blocks, FFTs, filters and memories, etc. Some of these blocks also support floating-point DSP. The Floating-
Point library provided by Xilinx lists such blocks. Moreover, the System Generator also includes the mcode
and Black Box blocks, which can be used to integrate mcode and HDL codes, respectively, directly into the
Simulink design environment.

Additionally, it provides automatic generation of a HDL testbench, which enables design verification upon
implementation.
 Develop highly parallel systems with the industry’s most advanced FPGAs
 Provide system modeling and automatic code generation from Simulink® and MATLAB® (The
Mathworks, Inc.)
 Integrates RTL, embedded, IP, MATLAB and hardware components of a DSP system
 A key component of the Xilinx DSP Targeted Design Platform

The system generator blocks do not automatically convert the Simulink floating-point numbers to fixed-point.
Unlike the HDL Coder, where the floating-point numbers are automatically converted to fixed-point, the
System Generator utilizes the Gateway In and Gateway Out Blocks to convert from floating-point to fixed-
point and vice-versa, respectively, as shown in Fig. 3. The downside to having to use Gateway In and Gateway
Out blocks is the potential to make mistakes during this conversion. For example, the designer has to be
careful when selecting the number of fixed-point bits, whether the fixed-point number is signed or unsigned as
well as the placement of binary point. Additionally, it is also time consuming, for example, when connecting
Simulink scopes for design verification, as shown in Fig. 3, each input to the scope has to be passed through
the Gateway Out block in order to convert from fixed-point back to the floating point
Figure 5.1:

5.1 Introduction to MATLAB HDL Coder

The HDL Coder, provided by Mathworks, is a MATLAB toolbox which generates target-independent, portable
and synthesizable Verilog and VHDL codes, which can then be used for FPGA programming and ASIC
designing. The toolbox works with different MATLAB functions, Simulink Models and Stateflow charts,
converting the MATLAB design into equivalent Verilog and HDL codes. In context of SDRs, especially Nutaq
SDRs, the Simulink design environment is recommended for rapid prototyping. While designing with HDL
Coder in Simulink, the first step is to filter the Simulink Library Browser, such that it only shows the model
blocks that are compatible with the HDL Coder. To this end, by typing “hdllib” in MATLAB command
prompt, one gets the Simulink Library Browser showing only the supported blocks. At present, HDL Coder
supports over 200 Simulink blocks, including Stateflow charts. Using these blocks, one can design the required
communication and signal processing logic as a Simulink model file, by dragging and dropping various blocks
into the design. HDL coder automatically converts floating point numbers into fixed-point. Furthermore,
functions written in MATLAB mcode can also be integrated into the design. To check design results via
simulations, different MATLAB tools could be used, including scopes, displays, etc. Blocks from Simulink
Sources library can be used to generate test signals for the design.

Once the design results have been verified through simulations, the next step is to generate the HDL codes,
which is done through Workflow Advisor, which comes with HDL coder. Through the Workflow Advisor, one
can select different parameters for the design, including the Target workflow, the targeted platform, the
targeted FPGA, declaring the external ports for the design, etc. In context of SDRs, the targeted workflow
gives the option to select a customizable SDR platform, as shown in the Fig. 1 below, while the target platform
gives the option to select the specific SDR platform, provided that the platform is supported by HDL coder.
Lastly, HDL Coder can also generate VHDL and Verilog test benches for verifying the HDL design.

Figure 5.2: Design flow with HDL Coder

If the goal is to simply generate the HDL codes, HDL Coder can do that as a standalone tool within MATLAB.
However, if one needs to synthesize the HDL code and generate a bitstream for the FPGA, third party
synthesis tools, such as Xilinx ISE and Vivado, or Altera Quartus are required. To this end, Fig. 2 summarizes
the design flow in a three step process. The first step refers to the model design using MATLAB functions and
Simulink blocks. At the end of this step, HDL codes are generated which can then be synthesized using third
party tools, like those mentioned above, and the bitstream is generated. Finally, the bitstream is downloaded
onto the FPGA. HDL Coder has the ability to integrate the third party tools within Workflow Advisor, using
the Synthesis tool option as shown in Fig. 1 above, thus providing a uniform and integrated environment
(Simulink Environment) for all the processes, starting from model design all the way down to bitstream
generation.

Fig 5.3 : Final implementation of HDL Compatible Simulink Design on Xilinx System Generator.
Fig 5.4 Analysis of DUC implementation on Xilinx System Generator

Fig 5.5 : Waveforms of Input and Output Ports

CHAPTER 6: CONCLUSION
After completing the project, we have drawn the following conclusions. DUC has a successful sample rate
conversion by a factor of 40 as expected by the specification. DUC has to be used in SDR application of
FRS system transmitters to for the up-conversion of speech signal at a bandwidth of 12.5e3 Hz. For FRS,
DUC Stopband frequency is 18.75e3 Hz and Stopband Attenuation of Cascade Response is 60 dB. The
DUC objects designed in project operate with double-precision filter coefficients.

Passband Ripple of Cascade Response of DUC is 0.05 dB. CIC filters are the best suited filters for DUC
related applications - compared to FIR Filters. They consume less computational power due to their
addition/subtraction complexity instead of multiplication/division. They also employ lesser area. Model-
based modular design approach has a significant number of advantages compared to traditional
approaches. Individual blocks can be interchangeable for multiple purposes and can be easily upgraded
and interfaced with other blocks/systems.

MATLAB HDL Coder and Xilinx System Generator both enable rapid prototyping of the FPGA design by
utilizing MATLAB and Simulink environment. Both of these packages come with their associated pros and
cons. The HDL Coder provides a complete integrated environment for the design flow. It supports a larger
number of MATLAB Functions and Simulink Blocks. It also automatically converts the floating point
numbers to fixed-point. Furthermore, HDL coder provides the means to generating target-independent
Verilog and VHDL codes, which can then be synthesized for various FPGA platforms. On the downside,
the HDL Coder alone is insufficient for synthesizing, simulating and verifying the HDL codes. Additional
MATLAB toolboxes and third-party software are required to achieve these goals. The Xilinx System
Generator comes as part of Xilinx design suits and is specifically tailored for Xilinx products. It also
supports a sufficiently large number of DSP blocks, including those that support mcode, HDL codes, and
floating-point DSP. Other than MATLAB itself, no third party software is needed, neither for generating
HDL codes from Simulink blocks, nor for synthesizing and verifying the generated codes. On the
downside, it is only limited to Xilinx products and requires manual conversion of Simulink floating-point
numbers to fixed-point, which can be a time consuming and error-prone process.
 REFERENCES

[1]W. Wolf, "Hardware-software co-design of embedded systems", Proceedings of the IEEE, vol. 82, no.
7, pp. 967-989, 1994.

[2]O. Schoett, Data Abstraction and the Correctness of Modular Programming. Edinburgh:
Department of Computer Science, University of Edinburgh, 1987.

[3]N. Ali Munassar and A. A. Govardhan, "Comparison between Traditional Approach and Object-
Oriented Approach in Software Engineering Development", International Journal of Advanced
Computer Science and Applications, vol. 2, 2011.

[4]N. Yang, G. Hua, J. Li and Z. Peng-yu, "Model-Based Design Methodology for Digital Up and
Down Conversion of Software Defined Radio", International Journal of Multimedia and Ubiquitous
Engineering, vol. 11, no. 4, 2016.

[5]G. Staple and K. Werbach, "The End of Spectrum Scarcity", IEEE Spectrum, vol. 41, no. 3, pp. 48-52,
2004.

[6]P. Chandrashekara Reddy &Sreerama Reddy G.M, “Design and FPGA Implementation of High
Speed, Low Power Digital Up Converter for Power Line Communication Systems”. European Journal of
Scientific Research, ISSN 1450-216X Vol.25 No.2 (2009), pp.234-249.

[7]Ronald E Crochiere, “Interpolation and Decimation of Digital Signal” – tutorial review proceedings
of IEEE, vol. 69, no. 3, march-1981.

[8]R. Lyons, “Understanding cascaded integratorcomb filters,” Embed Syst Program, vol. 18, no. 4, pp.
14– 27, 2005.

[9]A. Singh, P. Singhal, and R. Ratan, “Multistage implementation of multiratecic filters,” Indian
Journal of Science and Technology, vol. 4, no. 8, 2011.

[10]H. Tarn, K. Neilson, R. Uribe, and D. Hawke, “Designing efficient wireless digital up and
down converters leveraging core generator and system generator,” Xilinx, XAPP1018 (v1. 0), 2007.