Data Sheet
July 2000
DSP16210 Digital Signal Processor
54
DRAFT COPY
Lucent Technologies Inc.
Hardware Architecture
(continued)
Hardware Development System (HDS)
The HDS is an on-chip hardware module available for
debugging assembly-language programs that execute
on the DSP16000 core at the core’s rated speed. The
main capability of the HDS is in allowing controlled visi-
bility into the core’s state during program execution.
The fundamental steps in a debugging process, involv-
ing the HDS, include the following:
1. Setup: Download program code and data into the
correct memory regions and set breakpointing con-
ditions.
2. Run: Start execution or single step from a desired
starting point (i.e., allow device to run under simu-
lated or real-time conditions).
3. Break: Break program execution on satisfying break-
pointing conditions; upload and allow user accessi-
bility to internal state of the device and its pins.
4. Resume: Resume execution (normally or single
step) after hitting a breakpoint and finally upload
internal state at the end of execution.
The powerful debugging capability of the HDS is made
possible by breaking program execution on complex
condition, for example, may be an instruction that exe-
cutes from a particular instruction-address location (or
from a particular instruction-address range such as a
subroutine) and accesses a coefficient/data element
that matches a particular pattern from a memory loca-
tion (or from a memory region such as inside an array
or outside an array). The complex conditions can also
be chained to form more complex breakpointing condi-
tions. For example, a complex breakpointing condition
can be defined as the back-to-back execution of two
different subroutines.
The HDS also provides a debugging feature that allows
a finite number of initial complex breakpointing condi-
tions to optionally be ignored. The number of condi-
tions ignored is programmable by the user.
An intelligent trace mechanism for recording disconti-
nuity points during program execution is also available
in the HDS. This mechanism allows unambiguous
reconstruction of program flow involving discontinuity
points such as gotos, calls, returns, and interrupts. The
trace mechanism compresses single-level loops and
records them as a single discontinuity. This feature pre-
vents single-level loops from filling up the trace buffers.
Also, cache loops do not get registered as discontinui-
ties in the trace buffers. Therefore, two-level loops with
inner cache loops are registered as a single discontinu-
ity.
The HDS supports single stepping through instructions
without requiring the use of a watchpoint register.
A 32-bit cycle counter is provided for accurate code
profiling during program development. This cycle
counter can optionally be used to break program exe-
cution after a user-specified number of clock cycles.
JTAG Test Port
JTAG is an on-chip hardware module that controls the
HDS. All communication between the HDS software,
running on the host computer, and the on-chip HDS is
in a bit-serial manner through the TAP (test access
port) of the device. The TAP pins, which are the means
of communicating test information into and out of the
device, consist of TDI (test data input), TDO (test data
output), TMS (test mode select), TCK (test clock), and
TRST (TAP controller reset). The registers in the HDS
are connected in different scan paths between the TDI
(input port) and TDO (output port) pins of the TAP
JTAG instructions have been reserved to allow read
and write operations to be performed between JTAG
and the register chains of the HDS.
The set of test registers include the JTAG identification
register (ID), the boundary-scan register, and the scan-
nable peripheral registers. All of the device’s inputs and
outputs are incorporated in a JTAG scan path as shown
in
Table 27 on page 55
.