A Software-based Instrument for Testing and
Monitoring Multi-processing Communications
Devices
P. Savvopoulos, A. Kotsopoulos, M. Varsamou, N. Papandreou
†
and Th. Antonakopoulos
Department of Electrical and Computers Engineering
University of Patras, Rio-Patras, 26500, Greece
Email: {psavvop, mtvars, antonako}@upatras.gr, {akotsop, npapandr}@ece.upatras.gr
Abstract—This paper presents a software-based instrument for
testing and monitoring the behavior of complex communications
systems that employ a number of interconnected DSPs. The
instrument is based on a dynamic architecture that incorporates
a set of distributed software probes for signal capturing and a
central data acquisition unit for acquiring and post-processing of
data. A high level application that is executed on a host computing
machine enables command and control of the instrument’s mode
of operation and performs the necessary post-processing for
the analysis and visualization of the measurements data. The
application of this approach in the design and development of a
DVB-S2 receiver using a software-radio platform is presented.
I. INTRODUCTION
Modern communications systems rely on new advances in
various technical fields, such as adaptive modulation, iterative
signal processing and error control coding [1] for providing
new services. As a result, the h ardware implementation of such
systems involves complex and demanding techniques in terms
of processin g power and speed. Due to the embedded multi-
layer and multi-domain functionality, i.e. from physical to
network layer and from complex signal constellations to binary
user data, system-on-chip solutions are realized in the form of
a multi-processing and multi-tasking environment, where the
various processing stages are implemented as concatenated and
parallel software circuits that interact with multiple hardware
accelerator modules. Therefore, system prototyping appears to
be a quite challenging task, since the data flow from d ifferent
hierarchical levels, e.g. physical-layer signaling, multi-space
constellation mappings and N -tuple codewords, need to be
monitored, associated and often visualized, which requires a
more sophisticated testing and validation approach.
When discrete logic is used, verification is performed by
using oscilloscopes and logic analyzers, while for FPGA
implementations, hardware embedded probes are inserted by
using additional discrete logic and memory, such as Chipscope
[2]. In systems that employ multiple DSPs, a similar approach
is needed in order to use software probes in the various
software circuits. In this case, the various measurements and
parameters collected at the various system processing stages,
have to be associated with a common time-base in order to
support signal validation and overall functional verification
†
N. Papandreou is currently with IBM Zurich Research Laboratory
procedures. According to this approach, a flexible methodol-
ogy is necessary for organizing such signal measurements and
for enabling faster detection of out-of-specs conditions through
automated and more effective verification mechanisms.
In this paper, we present a software-based instrument for
testing and monitoring such multi-processing systems. The
instrument is based on a versatile architecture that incorporates
a set of interconnected software circuits acting also as system
probes and is developed on a software-radio platform suitable
for the design and implementation of complex communica-
tions systems. Additionally, a high-speed local bus or a high-
speed network is used to transfer the collected data to a
high-level software tool, for analysis and post-processing. In
this work, we have used the high-level MATLAB/Simulink
environment for providing the user interface and implementing
the data collection and post-processing functionality.
The rest of this paper is organized as follows. Section
II presents the details of the instrument’s architecture and
describes its functionality. Section III demonstrates the ap-
plication of the presented methodology in the design and
implementation of a DVB-S2 receiver using a software-radio
platform, while Section IV provides a measurement and veri-
fication procedure example of the instrument in the above
satellite receiver.
II. T
HE INSTRUMENT’S ARCHITECTURE
The architecture of the presented instrument is shown in
Fig. 1. It consists of various software probes attached to
different processing stages of the device under development,
the memory modules that provide the necessary storage of the
collected data, the data acquisition and packet gene ration u nit
that coordinates the collection of the measurements from the
various probes, the instrument’s basic controller and finally
the interface to the high-level analysis environment.
The software probes are integrated with the various software
circuits (SCs) of the system under development. The SCs
are based on multiple concurrent threads an d may be imple-
mented in different processors. Each SC has several inputs
and outputs that are fed by and drive other subsystems. The
software probes are implemented using dedicated threads that
are embodied in the SCs of interest and are responsible for
driving the measurement data to the memory modules using a
Input
signal
Software Circuit
#1
Software Circuit
#2
Software Circuit
#3
Software Circuit
#N
Software
Probe
#1
Software
Probe
#2
Software
Probe
#3
Software
Probe
#N
Memory Modules
Multi-processing environment
Data Acquisition/Packet Generation Unit
System Interconnection Logic
Instrument
Controller
External Interface Logic
Gigabit
Ethernet
PCI
Interface
User Environment
GbE
MATLAB
Fig. 1. The instrument’s architecture.
flexible structure of software/hardware FIFOs. The scheduling
of the various threads enables the transparent exchange of
data between the SCs and the memory modules in the overall
system data flow.
All data inserted into the FIFOs are further processed by the
Data Acquisition and Packet Generation Unit (DAQ/PGU), the
main task of which is to provide time-stamps, to coordinate
the measurement processes and to transfer the data to the
external interface. In particular, the DAQ/PGU associates
each software probe with a specific data stream from the
instrument to the external interface. For each data stream the
DAQ/PGU converts the retrieved data to a common format and
generates a packet which is associated with a header and an
appropriate time stamp. When packets from multiple streams
are available, they are multiplexed in order to generate the
final measurements packet to be sent to the external interface
unit.
The presented instrument provides two flexible interfaces
to the user. A PCI interface for interconnection with a host
PC and a Gigabit Ethernet (GbE) interface for networking
environments. In the current version, a MATLAB-based high
level application is used for controlling the instrument and
for the visualization of the measurements and debugging
information collected from the various SCs. In particular, the
user application is responsible for demultiplexing the different
data streams and proper correlation of the measurement data
based on their timing informatio n while it enables the user
to send commands to the instrument where they are processed
and acknowledged by the instrument’s controller. Several types
of commands are supported by this measurement environment,
including:
• enable or disable each measurement data stream
• configuration of each stream sampling rate
• configuration of each stream data format
• definition of the measu rement data carrying packet length
The high-level application performs the post-processing
of the received measurements for proper presentation and
visualization. Various statistics can also been extracted from
the received data streams giving a more detailed perspective
of the system’s behavior.
III. T
HE INSTRUMENT IN A DVB -S 2 R ECEIVER
IMPLEMENTATION
In this section, we present an application example of the
presented instrument integrated in a DVB-S2 receiver proto-
type. The receiver consists of an FPGA circuit responsible for
processing the analog IF input signal and for generating the re-
spective baseband signals, and three DSP cores implementing
the baseband signal p rocessing from the I-Q signal compo-
nents up to the processing of user IP p ackets and transmitting
them over a gigabit ethernet (GbE) LAN. All the receiver
circuits have been developed on a software radio platform,
which also incorporates additional reprogrammable logic for
logic demanding functions (line ECC), for the interconnection
of the four hardware modules [3] and for acquiring the data at
various stages of the receiver’s processing flow. The integration
of the instrument in the architecture of the DVB-S2 receiver
prototype is shown in Fig. 2 .
A. The DVB-S2 Receiver Architecture
The input IF signal feeds the receiver’s high resolution
analog to digital converter (ADC). The ADC digitizes the
signal and drives the subsequent digital signal processing
units. The first unit is the digital down-converter (DDC) [4]
that is implemented in a FPGA and converts the IF signal
into the respective b aseband one. The DDC numerical control
oscillator (NCO) frequency is controlled by the decisions of
a coarse carrier offset control loop in the Carrier Frequency
Recovery unit.
IF
DDC
ADC
Frame
Synch
FEC
Decoder
Constellation
Demapper
AGC
Synch
IF
analog
signal
Carrier
Phase
Recovery
FEC
Symbol
Timing
Recovery
Carrier
Frequency
Recovery
BB
Rx
BB-IP
TS
Demux
RX
Power
CTRL
Data Acquisition/Packet Generation Unit
Instrument
Controller
Processing Signal Flow:
Measurement Data Flow:
System Interconnection Logic
Software Circuit #1 Software Circuit #2 Software Circuit #3
Control
Computing Device
External
Interface
HW Circuit
Data
Acquisition
Data
Acquisition
Data
Acquisition
Fig. 2. Instrument’s integration in a DVB-S2 IF receiver.
The baseband processing stages have been implemented as
various software processing circuits (SCs) and allocated to
three DSPs. In particular, the symbol rate error is compensated
by using a mechanism that tracks the symbol rate fluctuations
and generates the synchronized samples of the incoming
symbols. Symbol timing recovery (STR) is implemented as
a second order feedback loop utilizing a Farrow structured
interpolator along with a non-data-aided (NDA) timing error
detector (TED) [5]. As soon as STR converges, the boundaries
of the DVB-S2 physical layer (PL) frames are detected by a
frame synchronizer. This is done by searching the physical
layer header based on the maximization of an appropriate
output correlator [6]. Based on the correct framing alignment,
it is possible to demultiplex (through proper descrambling) the
pilot symbols from the incoming frame in order to drive the
following pilot-aided carrier and phase synchronization units.
Carrier frequency recovery is based on pilot symbols that are
regularly repeated in the transmitted PL frame. The recovery
is performed in two sequential steps. The first step incorpo-
rates a ‘coarse’ frequency recovery (CFR) mechanism which
compensates large frequency offset errors up to several MHz
and is implemented as a second order feedback loop based on
a delay-and-multiply (DM) frequ e ncy error detector [7]. After
the convergence of the CFR loop, where the frequency offset
error is in the order of a few hundreds of kHz, a second stage
of ‘fine’ frequency recovery (FFR) is performed. FFR deploys
a feed-forward estimation algorithm d erived from an alteration
of the L&R technique [8].
After carrier recovery, the resulting residual frequency offset
error is compensated by two phase recovery mechanisms,
i.e. ‘coarse’ (Coarse Phase Recovery-CPR) and ‘fine’ (FPR)
respectively. The first is targeted for low order modulation
transmissions (QPSK or 8-PSK) and is based on a pilot-
assisted maximum-likelihood (ML) feed-forward estimator
which computes the average phase of each pilot field [7]. The
second mechan ism operates additionally to the first one when
the 16 or 32-APSK modulation scheme is used and consists
of a closed loop based on the NDA phase error detector
of Q-th power [9]. Between these two procedures, a digital
automatic gain control ( DAGC) takes place that is based on
a data-aided vector tracker mechanism (DA-VT) [10], which
utilizes the known pilot symbols fo r calculating the amplitud e
normalization multiplication factor.
Finally, the retrieved symbol stream is forwarded to the
signal constellation demapper and the respective bit frames
are further processed by the forward error correction (FEC)
module that incorporates LDPC and BCH decoding with
interleaving. The decoded frames are then processed by the
respective payload processing circuits in order to extract the
IP datagrams and to forward them into the GbE network.
B. The Software Radio Platform
The DVB-S2 receiver prototype along with the presented
software-based instrument are implemented on a powerful
hardware prototyping platform based on multiple DSP and
FPGA devices. The hardware accelerator module shown in
Fig. 2 digitizes and processes the incoming IF signal using a
12-bit ADC (up to 210 MSps) and a Virtex-II Pro (XC2VP30)
FPGA with a PowerPC processor. An SDRAM of 128MB
is also available for temporary storage purposes. The first
and second SCs are executed on two powerful C6416T DSPs
running at 1GHz and two Virtex-II Pro (XC2VP30) FPGA
with an SDRAM of 256MB. The third SC runs on a C6713
DSP, a Virtex-II FPGA, while a NetSilicon ARM-chip with
an integrated MAC controller is used for network p rotocol
processing.
C. Mapping of the Instrument Procedures into SCs
The first SC is dedicated to the multi-domain synchro-
nization of the demodulation process which includes the
symbol rate, frequency and phase recovery mechanisms along
Fig. 3. The recei ver’s synchronization tab of the MATLAB-based graphical user interface.
with frame synchronization and amplitude gain control. These
mechanisms are implemented as p arallel DSP threads. The
threads implementing symbol rate recovery, frame synchro-
nization and coarse/fine carrier recovery operate on the DDC
output sample stream generating data blocks of PL frames.
The threads responsible for the phase recovery and amplitude
gain control are executed periodically on the complete frames
derived by the previous set of threads. The total processing
load of the SC’s threads is properly divided in to small time
slots by the SC task scheduler.
The second SC is responsible for demapping, interleaving
and decoding (LDPC/BCH) the received frames of complex
symbols which operations are performed on several threads
deploying specific hardware accelerator modules. Finally, the
last SC implements the interface of the receiver with the exter-
nal environment that extracts the IP datagrams from successive
frames in order to forward them to the GbE Ethernet network.
The GbE network interface is also used for the connection
of the high-level application with the instrument platform for
control, post-processing and visualization of retrieved mea-
surements. The procedure above exploits several DSP threads
along with dedicated hardware logic. Furthermore, the last SC
circuit is also responsible for receiving and distributing the
control commands of the high-level application that perform
either receiver configuration or management of the performed
measurements. All software circuits incorporate a dedicated
thread that is used to coordinate their operation.
As shown in Fig. 2, an additional concurrent software thread
exists in each software circuit (Data Acquisition) that manip-
ulates the various outputs of the signal processing units along
with specific internal parameters. Its main task is to transfer the
required data from the software circuit into dedicated FIFOs,
implemented into the distributed memory resources of the
platform. In addition, these threads are also responsible for
converting the data of different parameters and signals into a
common format and adding the necessary timing information.
The parameters and signals monitored in each SC can be
either enabled or disabled through a set of control commands
initiated by the high-level ap plication.
Finally, the data that have been selected for acquisition are
stored into FIFOs which are read from the Data Acquisition
and Packet Generation Unit (DA/PGU) in order to generate the
necessary packets. DA/PGU logic exploits hardware resources
on each SC while the transmission of the generated packets is
totally performed by the last SC (BB-IP in Fig. 2).
At the computing device, a MATLAB based application is
used to control the various receiver parameters, while it also
collects information about the receiver’s status, giving a full
overview of the state of each software processing module.
More specifically, the user is able to:
• activate/deactivate different circuits
• monitor their status
• change or acquire their configuration parameters
• collect statistics of the synchronization process (i.e. ratio
of the undetected frame boundaries)
• measure performance metrics (i.e. EVM and BERT) and
• collect statistics at the network protocol processing stages
As an example, the GUI with the receiver synchronization
specific tab is given in Fig. 3. Moreover, the high-level
application is able to receive the measurement data packets and
by exploiting the visualization and da ta processing capab ilities
of the MATLAB environment, to determine the dependence of
various parameters and to demonstrate them. Such characteris-
tics enforce the easy and effective comprehension of acquired
measurement data and related post-processing results.
IV. DVB-S2 R
ECEIVER MEASUREMENT S AND
VAL IDAT ION EXAMPLE
In this section, we demonstrate an example of using the
highlig hted instrument, which is integrated into the DVB-
S2 receiver software-radio implementation, that depicts the
instrument’s contribution to complex communications systems.
Symbol timing recovery (STR) comprises a significant
mechanism that strongly affects the overall receiver perfor-
mance and efficiency while it can be hardly comprehended in
terms of its functionality and influence to the input sample
stream, since it is usually realized as a closed loop. The
presented instrument was utilized for proper evaluation, veri-
fication and also illustration of the STR closed loop operation.
In the rest of this subsection, it is described the STR veri-
fication that was performed using the given instrumentation
environment:
1) Initially, the Data Acquisition thread was enabled.
2) Then the internal parameters of STR that have to be
monitored were determined, including its input and
output. These parameters are the timing error detector
output, the loop filter output and the control word of the
interpolator which compensates the estimated symbol
rate error.
3) Then the size of the generated packets was determined
by a specific command (from the high-level application)
and the receiver was activated.
4) Packets were transmitted to the control computing de-
vice through the GbE interface until an internal STR
lock detector has identified that the STR has converged.
5) Finally, the high-level ap plication creates th e plots of the
different parameters using a common time scale, while
post-processing calculates several performance metrics
such as: du ration of initial acquisition, standard devia-
tion of estimation error and mean normalized estimated
error.
An example of the three STR internal parameters is g iven
in Fig. 4.
0 0.2 0.4 0.6 0.8 1
−0.5
−0.4
−0.3
−0.2
−0.1
0
0.1
0.2
0.3
0.4
0.5
Time (Secs)
Timing Error Detector Output
(a)
0 0.2 0.4 0.6 0.8 1
−2.5
−2
−1.5
−1
−0.5
0
0.5
1
1.5
2
2.5
x 10
−4
Time (Secs)
Loop Filter Output
Convergence
Init. Acquisition
(b)
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
Time (Secs)
Interpolator Control Word μ
(c)
Fig. 4. The three STR loop internal parameters monitored during STR
operation ((a): Timing Error Detector Output, (b) Loop Filter Output, (c):
Interpolator Control Word). The calculated performance metrics related with
this measurement are: Lock Time: 335.37 msec, Estimation Error Standard
Deviation: 2.2425e-5 and Mean Norm. Estimated Error: 2.493725e-4.