A TECHNICAL PAPER PRESENTATION

ON
MULTIPROCESSOR REAL-TIME ANALYSIS FOR
SCAN-BASED EMULATION: A METHODOLOGY
OF DSP APPLICATION
FOR

CSFEST-‘08

AT

VASAVI COLLEGE OF ENGINEERING

HYDERABAD
BY

GUDLAVALLERU ENGINEERING COLLEGE

GUDLAVALLERU

AUTHORS:

K.N.MALLIKHARJUN RAO ABDUL HAFEEZ

1II/IV B.TECH 1II/IV B.TECH
05481A0454 05481A0401

E MAIL: mallik454@gmail.com E MAIL:lathief_hafeez @yahoo.co.in

Abstract
Scan-based emulation is
a pervasive method that is deployed to
debug and develop DSP applications.
Scan-based emulation relies on
scanning data out from the target to
the host computer using proprietary
emulation hardware that is designed
into the DSP core. Emulation support
in our single processor and
multiprocessor environments
comprises software and hardware on
both the target and the host, and
therefore provides a transport
mechanism upon which to base real-
time analysis.
In this paper we present an end-to-end
methodology in developing a emulation is a pervasive method that is
multiprocessor real- time analysis
capability formulated on JTAG scan-
based mechanisms. Specifically we
discuss the issues related to extending
the capability from single to
multiprocessor domains. We examine
the issues related to supporting real-time
analysis in all of the software and
hardware components. Finally, we
enumerate the challenges in developing
a methodology for deploying both
homogeneous and heterogeneous
multiprocessor combinations.
Introduction
The ability to analyze the proper
execution of real-time applications
in an embedded system is critical to
their development and deployment.
This applies to real-time
applications ranging from mission
critical to multimedia.
In embedded systems the ability to
perform Real-Time Analysis (RTA) can
involve a dedicated hardware and
software capability with an end-to-end
methodology that supports the
transferring of data between the host and
the target in a lossless and reliable
manner. Specifically, the Real-Time
Analysis encompassed by this
methodology consists of capturing data
from a target application using dedicated
hardware, transferring it through various
layers of software dedicated to creating
a real-time path and making it available
to a host application for the purpose of
analysis. Analysis includes the
determining of whether applications
meet both timing and logical correctness
requirements.
In this paper we present an end-to-end
methodology in developing a
multiprocessor real- time analysis
capability formulated on JTAG scan-
based mechanisms. Scan-based
deployed to debug, develop and analyze
real-time applications running on DSPs.
The JTAG boundary scan specification
permits the connecting of multiple
devices in a serial daisy-chained
arrangement. This covers scan-based
emulation in detail and sets the stage
for RTA. .The RTA hardware and
software architecture that our
methodology relies upon is presented
.It also includes an application that
illustrates the necessity of RTA in a
multiprocessor environment.
Scan-Based Emulation
With a traditional emulator, the CPU
to be emulated is usually removed
from its socket and replaced with an
emulator pod. The emulator pod
typically has a replacement CPU, plus
various amounts of random logic and
memory to monitor what is happening
on the CPU pins. With modern CPUs
such as DSPs, the traditional approach
has several problems. The first
problem is the speed of newer DSP
chips. Bus cycle times can be 25
nanoseconds or shorter, and all
instructions typically
execute in a single cycle. This makes
it difficult for a traditional emulator to
allow emulation at full speed. The
number of pins to monitor can be
staggering, with chips having multiple
32-bit address and data buses, making
a traditional emulator expensive. The
second, and more serious, problem is
that DSPs often have on-chip caches,
pipelines, memory and peripherals.
Sometimes a whole algorithm can
execute without any activity on the
CPU pins.
The solution to these problems is
scan-based emulation. With scan-based
emulation, the CPU is never removed
from the socket; in fact it can be
soldered directly onto the board.
Instead, the CPU has a serial scan
interface, allowing the emulator to scan
the internals of the device through a
standard connector.
The scan-based approach to emulation
has many advantages:
• Emulation at full device
speed - Since there is no
logic needed to monitor
what happens on the CPU
bus, the emulator can allow
the device to execute
programs at full speed.
• Non-intrusive emulation -
Since no logic is attached to
any CPU pin, the CPU bus is
not affected at all by the
emulation process. The
emulator will not affect the
operation of the bus, as is so
often the case with traditional
emulators.
• In-circuit emulation - The
CPU can be soldered to the
board while emulating.
This makes denser
packaging possible, and
also makes the emulator a
manufacturing test tool.
• Full access to internal
memory, caches, pipelines
and registers - The complete
state of the processor is
visible to the outside through
a scan interface.
• Complete access to the
system from the CPU - Any
peripheral or memory that
the CPU can access in the
system can also be accessed
through the scan interface.
The emulator can look at the
system "through the eyes of
the CPU". This makes it
possible to debug and
diagnose a system where
nothing is working except the
CPU itself.
The JTAG Interface
The Joint Test Action Group (JTAG)
defines an interface called the JTAG
interface for testing individual devices
on printed circuit boards, without the
need to remove the devices from the
board. This is accomplished by a method
called boundary scan, whereby the state
of each pin of each device (with some
special logic on the device) is serially
scannedoutfromthedevice.
Multiple devices can be daisy chained,
and an entire PC board can therefore be
scanned in a single scan chain. It is
possible to use the same method to scan
out not only the state of a devices pins,
but to scan out any internal information
from the device, such as register values,
memory location; as a consequence
scan-based emulation was born. The
JTAG specification does not include the
pin out for the JTAG connector. The
extension to JTAG defines a 14 pin, 2
row, 0.1" spacing JTAG connector
header, with pin out and physical
dimensions common to all DSPs that
support JTAG involved in this
2 from the core logic to be loaded into the
methodology .During JTAG emulation,
the emulator supplies the clock that
scans the device. This means that the
target clock speed is completely
independent of the emulation clock, and
the emulator can support targets running
at any clock speed.
The boundary scan mechanism
Device architecture
The JTAG device architecture is
based on the IEEE 1149.1
architecture. In this specification,
there are four dedicated pins
collectively known as the Test
Access Port (TAP). They are:
• Test Data In (TDI)
• Test Data Out (TDO)
• Test Mode Select (TMS)
• Test Clock (TCK)
• Test Rest (optional)
A boundary scan cell is connected to
each boundary scan register on each
device that is being scanned. The
architecture further specifies a finite
machine TAP controller with inputs
TMS and TCK. There is an Instruction
Register (IR) holding the current
instruction, a bypass register, and an
optional 32-bit identification register for
permanent identification.
Principles of Boundary Scan
Boundary scan cells are configured into
a parallel-in, parallel-out shift register.
Parallel load operations cause signals
output cells. Parallel unload operations
cause the signals to be loaded from the
input cells to the core logic. Data is
shifted in serial mode by daisy chaining
devices.
The figure below shows the TDI of
each device connected to the TDO of the
next device in the scan chain. It is
possible to avoid scanning any device
by placing it in bypass mode.
Typically, the system architect is
responsible for determining the type
(homogeneous or heterogeneous) type
of arrangement of devices, their order
in the scan chain and if they will be
placed in bypass.

Real-Time Analysis (RTA)
The following application in the domain
of high energy physics illustrates the
necessity for RTA in a heterogeneous
multiprocessor environment. The Fermi
lab Tevatron Collider generates 15
million particle collisions per second.
These particle collisions result in the
creation of subatomic particles that
travel through a spectrometer. The data
output from the spectrometer is in the
order of terabytes per second and must
be analyzed in real time. The analysis
engine comprises a massively parallel
arrangement of heterogeneous DSPs and
GPPs (general purpose processors).
Analysis consists of applying algorithms
that reconstruct and filter the collision
data. The result is a select set of
interesting collisions from which
physicists can study some of the
remaining mysteries of matter and
3
antimatter in the universe .
Analysis of real-time embedded
applications is necessary at
severalpoints during the software life
cycle: during development, as means
to debug; towards the end of
development, for tuning
performance; and after the
application is deployed, for failure
analysis. Logic analyzers have been
used for many years to clamp onto
the data busses of the target and
monitor the data flow of the
application in order to analyze
application behavior. Aside from the
fact that logic analyzers are
expensive ($15K to $60K for a
DSP), the increase in system-level
integration over the years has
resulted in fewer exposed data paths
for the logic analyzer to monitor.
Most modern microprocessors are
architected with specialized
hardware counters that can be
programmed for the purpose of
tracing applications.
Traditionally these registers have
been used to determine the design of
the micro architecture such as caches
and TLBs, etc. Whereas these
registers can be used to trace the
behavior of applications at a very
fine level of granularity, they cannot
easily be used as a RTA mechanism.
An ancillary yet significant issue is
that analysis requires that the user
have an advanced knowledge of the
target micro architecture in order to
interpret the data.
Fig 2: Debugger with real-time data
exchange

RTA host software library funnels the

data between the emulation software
Finally, tracing supports data driver and the host application. Again,
transfer only from target to host and an API exists for the RTA host software
not from host to target. library. It should be noted that multiple
host applications may be run
concurrently.
An alternative real-time analysis
solution based upon JTAG emulation is
presented here. This hardware and
software architecture for a single
processor is shown in. The JTAG
interface that connects the on-chip
emulation logic to the host-based
emulator provides the physical
mechanism on which to transport data
from the target to the host and vice
versa. The target application is the
subject matter to be analyzed; it is the
source of data to be sent to the host and Fig 3:Single processor RTA based
the sink for data received from the host. upon JTAG
Therefore, a RTA target software library
exists to bridge the gap from the target . An emulation software driver controls
application to the on- chip emulation the scanning of data to/from the target
hardware. Good software engineering via the emulator. It is the first piece of
practices dictate that an API exists for host software to receive data from the
this software library. On the host, the target and the last piece of host software
data is to be analyzed by a host to handle data heading to the target. A
application. This host application may RTA host software library funnels the
also input data to the target application. data between the emulation software
We must therefore bridge the gap from driver and the host application. Again,
the emulator to the host application. . an API exists for the RTA host software
library. It should be noted that multiple
host applications may be run
An emulation software driver controls concurrently.
the scanning of data to/from the target
via the emulator. It is the first piece of
host software to receive data from the
target and the last piece of host software
to handle data heading to the target. A
Data flow in this architecture is bi-
directional: data flows from the target
application to the host application for
analysis, and data may flow from the
host application to the target application
for supplying input parameters. Such
input parameters may be used for fine
tuning performance, for supplying test
data, etc.

For target-to-host data transfer, there are

two distinct parts of the data flow path.
The first part extends from the target
application to the RTA host software
library. This is the real-time
transportation leg. Since our target
application has real-time constraints, data
must be off-loaded from the target to
the host at a certain rate. The RTA host
software library is the first piece of
software on the host that realizes it has
received real-time data for analysis.
(The emulation software is agnostic to
what type of data it is scanning.) The
RTA host software can record the data
to disk and be done with it, or buffer it
internally. The second part of the
target-to-host data flow path extends
from the RTA host software library to
the host application. The data is
analyzed by the host application. If the
data has been recorded in persistent
storage, then the data can be played
back at any time. If the data is not in
persistent storage, then it must be
analyzed by the host application as it is
produced; that is, the data must be
drained from the RTA host software
buffers as they fill.
Fig 4: single processor RTA based
uponJTAG emulation
The above RTA architecture for a single
embedded processor is easily extended
to a multiprocessor environment. This
is shown in A RTA target software
library must exist on each embedded
target to connect the target application to
the emulation logic on that target. For
multi-core architectures, a RTA target
software library will exist for each core.
The data from each processor is scanned
up to the host via the JTAG interface
ring as described in (Scan-Based
Emulation). On the host, there exists an
emulation software driver corresponding
to each target in the system. Each
emulation software driver receives the
data from its corresponding target and
delivers the data to the one RTA host
software library.

Fig 5: Multiprocessor RTA via Scan-Based
Emulation
This architecture for multiprocessor
real-time analysis via scan-based
emulation provides the basis for the
methodology.
Methodology
In this section we present an end-to-
end methodology that is predicated on
support in hardware and software
across several families of DSPs. There
is special emulation hardware
architected into the DSP core and
emulation drivers as well as RTA target
and host side software that permit the
user to perform RTA.Fundamentally,
this methodology involves using a
development environment to develop
and download a target application to a
DSP. The application running on the
DSP interfaces with the RTA software
to send and receive data. The data is
scanned out using JTAG boundary
scan. The data is received on the host
by the emulation driver that interfaces
to the host-side RTA software. The data
is then presented to the host client
application for analysis. The figures of
merit used to determine the success of
this methodology are performance,
scalability, ease of use and reliability.
We discuss these criteria within the
scope of both hardware capabilities and
the RTA software architecture in a
multiprocessor environment.
Performance
An important consideration in
providing a methodology for
multiprocessor RTA is
Performance
Dedicated Emulation Hardware
The performance problem has
been partially addressed in
hardware by dedicating hardware
for scan-based emulation. Data is
transferred between target and
host using dedicated emulation
hardware to improve
performance. In a heterogeneous
multiprocessor arrangement of
DSPs one complication that arises
is that of varying scan lengths.
Each design of DSP has its own
emulation hardware. This results
in scan lengths that vary within a
family of DSPs and between
Instruction Set Architectures
(ISAs). The result of this variance
is that longer scan chains require
greater disassembly time for the
scanned data resulting in lower
throughput. This results in lower
performance. Data can be
streamed between target and host
by using peripherals such as
DMA and by performing real-
time memory write operations. In
a multiprocessor JTAG scan, a
special JTAG boundary scan
bypass instruction obviates the
need to scan any device set to
bypass mode. This results in less
time to disassemble data being
transferred between host and
target Fig 6: Virtual Data better to mark
Paths the data on the
host-side as to
A RTA solution the target-side.
for a If a unique
multiprocessor processor
environment identifier were
must be able to sent down to the
identify the target and the
processor from data were
which data tagged there,
originates. This then more data
introduces the would be sent
need to mark the
from the target
data with a
to the host and
processor
would consume
identifier. The
decision then precious
becomes where bandwidth. At
in the system to the processor
do this. If we level, it is
examine the possible to
host, we see that allow finer-
there is a one-to- grain
one identification of
correspondence data. Virtual
between the data paths that
emulation extend from the
software drivers target
and the application to
processors in the the host
system. Since application are
there is an used to
emulation segregate data.
software driver scalability
for each target in
the system, these A key aspect
drivers can of this
stamp the data
methodology
with a processor
is scalability.
identifier. Note
This issue is
that from a
addressed in
performance
both hardware
perspective, it is
and software.
 number or application
Hardware processors and that performs Ease of use is
Scalability does not need a series of an important
to be altered if transformatio but often
The JTAG processors are ns on a given difficult figure
specification either added vector, and of metric to
permits the or removed then transfers sustain. A
daisy chaining from the the resulting software
of hardware. system vector to the debugging
The limits configuration. host for environment is
placed on the There is no analysis. provided that
number of requirement Let’s further permits the user
devices that that the target assume that to easily
can be daisy application there are configure the
chained is have any many vectors hardware in the
based on signal knowledge of that must be system.
strength the type or transformed
limitations as number of and that we
opposed to the processors in choose to
JTAG a scan chain at deploy the
specification. the time of same target
development. application on
as many
Software Data Selection processors as
Scalability there are
The host vectors to
In software, application achieve
data is tagged should be maximum
from each able to computing
target with a select from parallelization Fig 7:
unique which . We can Processor
identifier so processor to design a host Selection
that data being send or application
transferred receive data. that sends a Hardware
between host This is different Support
and target can accomplishe vector to each
be identified d by processor and A trend in DSP
as to which incorporatin then collects emulation
processor it g this the resulting hardware is to
belongs. functionality vectors from support device
Further, the into the host each registers that are
RTA API. This processor, mapped at fixed
architecture is Proves to be respectively, addresses. This
software very favorable for analysis permits the
scalable; with respect source code
writing the to scalability. porting of
target For example, applications.
application is let’s assume Further, a trend
not dependent that we have a in more
upon the target Ease of Use contemporary
DSP emulation is a defacto to-host and sides.
logic is to industry host-to- Another
replicate the standard. This target data feature of
logic on all permits the host transfers the RTA
application assists in
DSPs. This architecture
developer to ensuring that
further is
write client there is no
simplifies the programs that congestion
deployment of data control.
are not tightly corruption.
RTA tools. coupled to a With this
Further, host capability
specific DSP.
applications
Software buffers are
synchronize
Support Hardware guaranteed
on data
Reliability not to
buffers
At setup, the connected to overflow.
user selects the The JTAG virtual paths During host-
type of target specification and so there to-target
and loads the has been long is no data data
system with an established as a loss. Buffer transfer, the
emulation reliable managemen RTA
driver for that standard. It has t is precise architecture
target. The user been adopted and is signals the
also specifies and extended. architected end of data
the number of An extensive to ensure no transfer
targets of each set of target data loss on through a
type and their libraries have both target virtual path
position in the been developed and host using
scan chain. for various callbacks.
Without this flavors of
capability users DSPs based on
would have to boundary scan.
add code in Reliability is
their host achieved
applications through reuse
that performed of the same
the same register set in
function, different
resulting in versions of
messy and emulation
unnecessarily hardware
complex code. across ISAs
Host side and within
support is
ISAs.
provided in the
way of object-
Software
oriented Reliability
interfaces based
on the The use of
Component unidirectiona
Object Model l virtual
4
(COM) , which paths for
both target-

Challenges
There are several challenges in
supporting a uniform multiprocessor
RTA capability on various families of
DSPs.Each family of DSP has its
particular variant of emulation
hardware. This has an impact on the
RTA protocol that is used to transfer
data between host and target. For
instance, some of the emulation
capabilities on some DSPs use interrupt
to signal the flow of data between host
and target. In the absence of emulation
interrupt support, the application must
poll the emulation hardware for the
presence of data.
Conclusion
specification and the adherence to this
standard in the emulation hardware that
has been designed into the DSP core.
The software that has been developed is
able to differentiate between the various
DSPs. The virtual paths in the RTA
architecture guarantee data integrity.
References:
[1] JTAG IEEE 1149.1 Specification
http://www.ieee.org
[2]Gottschalk, E.E., et al., "The BTeV
DAQ and Trigger System – Some
Throughput, Usability, and Fault
Tolerance Aspects," Proceedings of the
Computing in High Energy and Nuclear
Physics Conference (CHEP 2001), p. 628,
Beijing,

The RTA methodology presented in this

paper is extensively used and widely
accepted. The problem that is illustrated
in the high energy physics application
presented is not limiting. Our experiences
to date have shown that other domains
such as wireless and mobile computing
require the processing of RTA data
where both DSPs and microcontrollers
are on the same scan chain. The
development of this RTA capability has
been predicated on the JTAG