Advanced Debug

Interface
Author: Nathan Yawn
[Link]@[Link]

Revised: Antonio Pullini

pullinia@[Link]

Rev. 2.2

December 12, 2014

 Advanced Debug Interface 1/22/2015

Copyright (C) 2008-2010 Nathan Yawn

Permission is granted to copy, distribute and/or modify this document under the terms of
the GNU Free Documentation License, Version 1.2 or any later version published by the
Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no
Back-Cover Texts. A copy of the license should be included with this document. If not,
the license may be obtained from [Link], or by writing to the Free Software
Foundation.

Rev 2.2 Page 2 of 42

 Advanced Debug Interface 1/22/2015

This document is distributed in the hope that it will be useful, but

WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Rev 2.2 Page 3 of 42

 Advanced Debug Interface 1/22/2015

History
Rev. Date Author Description
1.0 27/06/08 Nathan Yawn First Draft
2.0 17/01/10 NAY Added hi-speed mode documentation
2.1 30/3/10 NAY Added JTAG Serial Port documentation
2.2 10/12/14 Antonio Pullini Updated documentation to PULP platform

Rev 2.2 Page 4 of 42

 Advanced Debug Interface 1/22/2015

Table of Contents

INTRODUCTION..............................................................................................................6

ARCHITECTURE.............................................................................................................8
2.1 TOP MODULE 10
2.2 AXI4 MODULE 11
2.3 OR1ON CPU MODULE 13
API.....................................................................................................................................15
3.1 TOP-LEVEL COMMANDS 15
3.1.1 Module Select command................................................................................................................15
3.2 AXI4 COMMANDS 16
3.2.1 Burst Setup.....................................................................................................................................17
3.2.2 Burst Write.....................................................................................................................................18
3.2.3 Burst Read......................................................................................................................................20
3.2.4 Register Select................................................................................................................................21
3.2.5 Register Read.................................................................................................................................22
3.2.6 Register Write................................................................................................................................23
3.2.7 NOP................................................................................................................................................24
3.3 CPU COMMANDS 24
3.3.1 Burst Setup.....................................................................................................................................25
3.3.2 Burst Write.....................................................................................................................................26
3.3.3 Burst Read......................................................................................................................................28
3.3.4 Register Select................................................................................................................................29
3.3.5 Register Read.................................................................................................................................30
3.3.6 Register Write................................................................................................................................31
3.3.7 NOP................................................................................................................................................32
3.4 AXI4 MODULE REGISTERS 33
3.4.1 Error Register.................................................................................................................................33
3.5 CPU MODULE REGISTERS 35
3.5.1 Status Register................................................................................................................................35

IO PORTS.........................................................................................................................37
4.1 TAP PORTS 37
4.2 CPU PORTS 38
4.3 AXI4 PORTS 38
MODULE CONFIGURATION......................................................................................40

CRC MODULE................................................................................................................41

Rev 2.2 Page 5 of 42

 Advanced Debug Interface 1/22/2015

1
Introduction

The Advanced Debug Interface (ADI) is a hardware module which creates an

interface between a JTAG Test Access Port (TAP) and the system bus and CPU debug
interface(s) of a System on Chip (SoC). It is part of the system which allows software
running on an SoC to be controlled and debugged by a software debugger such as GDB,
running on a separate host PC. This debugging system allows the SoC to be debugged
via direct hardware connection, and does not require the “GDB stub” software running on
the SoC. A block diagram of this system is shown in Figure 1.
The external interface to the Advanced Debug Interface is based on IEEE Std.
1149.1, Standard Test Access Port and Boundary Scan Architecture. A JTAG TAP is
required to link the ADI to an external JTAG cable. This TAP may be a stand-alone
TAP1, or it may be a specialized unit such as an Altera Virtual JTAG or a Xilinx Internal
BSCAN unit. The ADI appears as a data register within the TAP.
Internally, the ADI has connections to both a AXI4 bus and to one or more CPU
debug interfaces. The AXI4 interface does not use any of the burst features of the bus; it
should therefore be compatible with any version of the bus (Full AXI4 or AXI4-Lite).
The CPU interface is designed to connect to an OR1ON processor, or any other CPU
which uses the same debug ports. Note that there are two versions of the OR1ON debug
interface; the ADI is designed to use the newer version, which includes the strobe and
acknowledge (dbg_stb and dbg_ack) signals.

1 Note that the ADI is incompatible with the stand-alone TAP written by Igor Mohor. Please use the
version modified by Nathan Yawn instead.

Rev 2.2 Page 6 of 42

 Advanced Debug Interface 1/22/2015

OR1200 CPU

CPU
CPU
Development
Interface

Advanced Debug Interface

JTAG TAP CPU sub-module

Controller

MUX
FSM BIU

MUX
FSM BIU

TDI FSM CRC Reg.

FSM CRC Reg.
TDO
Debug Scan Chain
TCK ID

Module Select
ID

Module Select
AXI4 sub-module
TMS
TRSTn FSM Reg.
MUX FSM Reg.
MUX
CRC BIU
CRC BIU
Boundary Scan Chain

MBIST Scan Chain

System AXI4 Bus

Figure 1: Block diagram of the complete debug system hardware

Rev 2.2 Page 7 of 42

 Advanced Debug Interface 1/22/2015

2
Architecture

The Advanced Debug Interface is built with a modular architecture, for flexibility
and expandability. It consists of a top-level module, and several sub-modules designed to
interface with individual SoC subsystems. The sub-modules currently include the AXI4
module and the OR1ON module.
The top-level module contains the sub-modules, and a register to set the active
sub-module. In order to send a command to a sub-module, it must first be made active by
setting this top level register; only one sub-module may be active at a time. Zero or more
instances of any type of sub-module are valid (the default is one AXI4 sub-module and
one OR1ON CPU sub-module). The top-level module also contains the input shift
register, which holds incoming serial data from the TAP. The value in the input shift
register is available to all sub-modules. Note that as per the JTAG specification, all serial
transfers are LSB-first.
Sub-modules generally consist of two parts: internal registers, and a bus interface.
Internal module registers may contain information about the status of the module (such as
the error register in the AXI4 module), or they may control external I/O lines (such as the
reset and stall lines from the OR1ON module). Each sub-module using one or more
registers contains an index register, which enables one internal register at a time for
reading or writing. Internal registers are selected, read, and written by sending
commands to a sub-module through the TAP.
The bus interface of most sub-modules is designed to allow the TAP to read or
write data from or to a bus as quickly as possible. Note that 'bus' in this case does not
necessarily mean a AXI4 bus; the bus interface of the OR1ON module connects to the
processor's SPR bus. All bus transactions are 'burst' transactions from the external / TAP
side: a setup command is first sent to a sub-module, then the entire block of data is
streamed into or out of the sub-module without further control action. Different
sub-modules may provide burst transactions using various word lengths. Burst data is
CRC-protected. A block diagram of the general module structure is shown in Figure 2.

Rev 2.2 Page 8 of 42

 Advanced Debug Interface 1/22/2015

Input Shift Reg. Data

General Module Structure

Data out

Address Counter
Address Bus
Bus
Interface I/F
Unit
Word Counter Data in

Bit Counter

Internal Registers

Output Shift Register Module

TDO

CRC Unit

Figure 2: General module structure

In order to support JTAG scan chains with more than one device, commands are
usually executed by the sub-modules when the TAP moves through the UPDATE_DR
state. This allows a software driver to add the necessary bits to the end of a serial
bitstream to position the command at the correct place in the scan chain.
The exception to this is burst data, due to its unknown (and potentially very large)
size. To do a burst transaction, a burst command is first sent to a module, and executed
by moving the TAP through the UPDATE_DR state. The next time the TAP goes into the
SHIFT_DR state, 'burst mode' is active. In burst mode, bus data is immediately clocked
into or out of the module, and the next bus transaction (or the end of the transaction) is
determined by internal counters. In order to support multi-device chains, a “start bit”
feature was added to burst mode. During burst writes, the module will not start its
counters or collect write data until after the first '1' (a “start bit”) is encountered in the
bitstream. Since TAP devices in BYPASS mode will initially shift out a '0', this means
that these extra bits from other devices will be ignored by the ADI module. Once the

Rev 2.2 Page 9 of 42

 Advanced Debug Interface 1/22/2015

module sees the start bit, it begins to capture write data (the start bit is discarded). Burst
reads require no such added feature, as a software cable driver may simply discard the
appropriate number of bits before beginning to capture read data. However, the first
status bit of a burst read may be used as a start bit during burst reads, see the API sections
on burst reads for details.
There are two more things to consider when using the ADI in a scan chain with
multiple devices. First, all other devices should be in BYPASS mode when using the
ADI – otherwise, a false start bit could get sent to the ADI during a burst write,
corrupting the data. Second, the ADI data register is not a through shift register – that is,
the serial TDI input of the ADI is not directly connected to the TDO output. This means
that data shifted into the ADI will never appear at the output. As such, the ADI should
never be active when other devices on the chain are in use.
Four modules are currently implemented. The following sections give details for
each type.

2.1 Top Module

The top-level module is the simplest of the modules. It does not have a bus
interface, and has only a single register. This register is called the “module select
register”, and is used to select the active sub-module. The top module does not use
command opcodes the way the sub-modules do. Instead, a single bit in the input shift
register (the MSB) indicates whether the command is a write to the select register, or a
command to a sub-module (in which case the command is ignored by the top-level). The
value in the select register cannot be read back.
The top-level module provides enable signals to all sub-modules, based on the
value in the module select register. The value of the input shift register is also provided
to all modules. Finally, the serial TDO output of the ADI is selected from the sub-module
TDO outputs, based on the module select register. A block diagram of the top-level
module is shown in Figure 3.

Rev 2.2 Page 10 of 42

 Advanced Debug Interface 1/22/2015

Top-level module
TD
I Input Shift Register

Data

Module select
register WB Module
TDO

Enable
CPU0 Module

Other Modules

Figure 3: Block diagram of top-level module

2.2 AXI4 Module

The purpose of the AXI4 module is to provide a software debugger access to the
SoC's memory system, allowing it to load code, examine and change program data, and
set software breakpoints. The AXI4 module has a bus interface which follows the AXI4
standard. Because the JTAG interface is relatively slow, burst accesses on the AXI4 bus
interface are not used, therefore the interface should be compatible with all versions of
the AXI4 standard (through B.3 as of this writing). The AXI4 module allows 8-, 16-,
32-bit and 64-bit reads and writes over the AXI4 bus interface. The AXI4 Module uses a
32-bit address and a 64-bit data bus, and allows burst transfers of up to 65535 words
(524280 bytes).
Since the JTAG clock is asynchronous to the AXI4 bus clock, transactions are
synchronized between clock domains. This clock differential may cause other problems,
however, if the JTAG clock is much faster than the AXI4 clock. For efficient operation, it
must be possible to complete a AXI4 write (plus 4 JTAG-domain clock cycles for control
and synchronization) in less time than it takes to shift the next word in via the TAP. The
problem is magnified when using 8-bit words. If the bus is not ready by the time the next
word has arrived, then the attempt to write the next word will fail.
The ADI may be synthesized in one of two modes: Legacy (or “careful”) mode,
and Hi-Speed mode. Which mode is used affects how overflow conditions are detected.
In legacy mode, an overflow condition during a burst write can be detected by reading
back a status bit after writing each word. If the status bit is true, then the transaction has

Rev 2.2 Page 11 of 42

 Advanced Debug Interface 1/22/2015

succeeded (the AXI4 bus was ready to accept the word) and the burst should continue. If
the status bit is false, then an overflow has occurred, and the software driver should retry
part of the burst, starting with last word written.
In hi-speed mode, there is no status bit between data bytes, and overflows cannot
be detected until after the burst transaction is finished. In hi-speed mode, an overflow is
detected and treated in the same way as a AXI4 bus error, and is captured by the module's
“error register,” described below.
In legacy mode, underflow conditions during burst reads are avoided by use of a
“ready” bit, which is read by the software driver before each word is shifted out of the
ADI. When data is not yet available, the AXI4 module shifts out zeros. As soon as a data
word is read from the AXI4 bus, the module shifts out a one, indicating that data is ready
(the driver should discard this '1' and all preceding ready bits). Bus data follows
immediately after a true ready bit is sent.
Hi-speed mode eliminates all ready bits in a burst read except the first one –
driver software must only wait for a single valid ready bit at the start of a read transaction
before transferring all of the data. An underflow condition in a hi-speed mode burst read
is treated as a AXI4 bus error, and captured by the “error register,” described below.
Which mode you select (legacy or hi-speed) depends on the relative clock speeds
of your system's AXI4 bus and JTAG interface. Systems with AXI4 clock slower than
the JTAG clock may require legacy mode. Most systems should select hi-speed mode,
especially if a USB-based JTAG cable is used. A system in hi-speed mode using a USB
JTAG cable is generally able to transfer AXI4 data an order of magnitude faster than a
system with a legacy-mode ADI.
The AXI4 module contains a single 33-bit internal register, called the “error
register,” which is used to detect errors on the bus interface. During a burst read or write,
the AXI4 error (wb_err) bit is sampled at the end of each bus transaction. If the error bit
is ever true, then the error bit (bit 0) in the error register is set, and the address of the
failed transaction is captured into the other 32 bits of the error register. Once the error bit
has been set, it can only be cleared by performing an internal register write to the AXI4
module - the addresses of subsequent errors will not be captured. Thus, when the error
bit is set, the error register contains the address of the first bus error encountered since the
bit was last reset. Note that when the ADI is synthesized in hi-speed mode, the error bit
will also be set on an underflow or overflow condition.
The error register should be reset before each bus transaction (or after each time
the error bit is found set), then checked after each burst transaction. Because the error bit
is the least-significant bit, a software driver may read only 1 bit in order to determine
whether or not an error condition exists. If true, then the driver may read out the 32-bit
error address, and retry the part of the burst starting from that address.
The AXI4 sub-module includes a CRC calculation, which is used to protect burst
data. During burst transactions, an internal word counter determines when all of the data

Rev 2.2 Page 12 of 42

 Advanced Debug Interface 1/22/2015

for a burst has been transferred. If a burst read has just completed, the module then
begins to shift out a 32-bit CRC, which the host may compare to a locally-generated
CRC. If the completed transaction is a burst write, the module accepts a 32-bit CRC
from the host, then shifts out a single bit indicating whether or not the CRC received
matched its internal CRC computation. Note that the CRC is done only on the burst data;
the preceding burst command, and all start and ready bits, are ignored.
The CRC polynomial is 0xEDB88320. This is bitwise-reversed from many
implementations; this is because we compute the CRC LSB-first (also reversed from
other implementations). The LSB-first calculation was used to reduce hardware and
routing requirements in the CRC module.

2.3 OR1ON CPU Module

The OR1ON CPU sub-module is designed to allow a software debugger to access
the internal registers of a CPU, to stall the processor, and to take control when a
breakpoint occurs in software. The OR1ON module may also allow access to the CPU's
hardware breakpoint see the OR1ON architecture specification and the OR1ON
implementation document for details.
The OR1ON sub-module is based on the AXI4 module, and is therefore similar.
The bus interface connects to the debug interface of the OR1ON, which allows access to
the processor's SPR bus. Accesses to this bus are performed by ADI burst transactions.
Reads, writes, clock synchronization, ready bits, status bits, overflow, underflow, and
CRC computations are all handled exactly as they are in the AXI4 module. The OR1ON
debug interface bus does not have an error indicator bit. Thus, the OR1ON module does
not have an internal “bus error” register.
The OR1ON module also has “legacy” and “hi-speed” modes, which work in the
same way as these modes in the AXI4 module. The only difference is the lack of an error
register in the OR1ON module. This means that in hi-speed mode, overflows and
underflows during burst transactions cannot be detected. It may be possible to guess
whether under- or overflows are occurring: if these errors are being reported during
AXI4 transactions, then it's likely they are also occurring during OR1ON transactions,
and a legacy-mode ADI should be used instead. Similarly, if you notice strange behavior
or unexplained data while debugging, it may be worthwhile to try legacy mode.
The OR1ON module allows the user to set and clear the CPU reset bit, to stall the
CPU, and to capture breakpoints in the CPU. This is done through a module internal
register, called the “CPU status register.” Bit 1 of this register is the reset bit. When this
bit is true, the cpu_rst_o output bit is set true, and vice-versa. This bit is set and cleared

Rev 2.2 Page 13 of 42

 Advanced Debug Interface 1/22/2015

only by internal register writes via the ADI. Note that this bit is synchronized between
clock domains.
Bit 0 of the CPU status register is the stall bit. When set, the cpu_stall_o output
of the ADI is also set, and vice versa. This bit may be set and cleared via internal register
access to the ADI. This bit may also be set by the CPU: when the cpu_bp_i input from
the CPU goes high (indicating a breakpoint), the stall bit in the register is set, and the stall
output set high. This effectively transfers control of the CPU to the ADI, which may
perform various debugging operation before clearing the stall bit via internal register
access, allowing the CPU to continue normal execution.

Rev 2.2 Page 14 of 42

 Advanced Debug Interface 1/22/2015

3
API

This section gives information on the commands, opcodes, and data formats of the
Advanced Debug Interface. There are four major sections: the top-level ADI, the AXI4
module, and the CPU modules. All commands and registers are shown with the
least-significant bit to the right, and all commands are shifted out LSB-first. Data is also
shifted in to and out of the ADI LSB-first. All commands are interpreted when the TAP
passes through state UPDATE_DR. All commands are interpreted as MSB-aligned. This
means that the minimum number of bits for a command may be shifted into the ADI,
without consideration for the length of the data register.
Note that the ADI must be reset before any commands will be accepted or
executed. If the system TAP has an output indicating the “Test Logic / Reset” state, it is
recommended that this be used as the ADI reset input. If this signal is not available, it is
recommended that the ADI reset input be connected to the OR1ON or AXI4 bus reset
signal.

3.1 Top-level Commands

3.1.1 Module Select command

This command is used to select which one of the sub-modules is active. Only the
active sub-module will process commands sent to the ADI. This command should be sent
before any other command is sent to any sub-module.

Rev 2.2 Page 15 of 42

 Advanced Debug Interface 1/22/2015

Figure 4: Module Select Command format

1 Module
2 0
Access

Bit # Description

5 W Top-Level Select
Set to '1' to select the top level module
4:0 W Module
Number of the module to select. The following modules are valid:
0x0 = AXI4 module
0x1 = CPU module
Table 1: Module Select command format

3.2 AXI4 Commands

The AXI4 sub-module uses a standardized command format. Each command
must have a zero as the MSBit, to differentiate it from a module select command. In the
next four most-significant bit positions is a 4-bit opcode, which indicates the operation to
be performed. Following the opcode are zero or more data values, whose length and
meaning are command-specific. Table 2 summarizes the opcodes supported in the AXI4
module.

Rev 2.2 Page 16 of 42

 Advanced Debug Interface 1/22/2015

OPCODE Operation

0x0 NOP

0x1 Burst Setup Write, 8-bit words

0x2 Burst Setup Write, 16-bit words

0x3 Burst Setup Write, 32-bit words

0x4 Burst Setup Write, 64-bit words

0x5 Burst Setup Read, 8-bit words

0x6 Burst Setup Read, 16-bit words

0x7 Burst Setup Read, 32-bit words

0x8 Burst Setup Read, 64-bit words

0x9 Internal register write

0xD Internal register select

Table 2: AXI module command opcode summary

3.2.1 Burst Setup

A burst setup command prepares the AXI4 module to do either a read or write
burst, in order to move data to or from a consecutive sequence of addresses on the AXI4
bus. The word size of the burst is decoded from the opcode. The AXI4 module can use
an 8-, 16-, 32- or 64-bit word size. After each individual word transfer during a burst, the
address counter in the ADI is incremented according to the word size: it will be
incremented by 1, 2, 4 or 8, for 8-, 16-, 32- and 64-bit words respectively.
After a burst setup command has been executed (in the UPDATE_DR state), the
AXI4 module will enter 'burst read' or 'burst write' mode, the next time the TAP enters
SHIFT_DR mode. Whether read or write mode is used depends on the opcode sent with
the burst setup command. Details on burst read and burst write modes are in the
following sections.

Figure 5: Burst Setup command

0 Opcode Address Count

52 48 16 0

Rev 2.2 Page 17 of 42

 Advanced Debug Interface 1/22/2015

Access
Bit # Description

52 W Top-Level Select
Set to '0' for all sub-module commands
48:51 W Opcode
Operation to perform. The following are valid burst setup
operations:
0x1 = Burst Write, 8-bit words
0x2 = Burst Write, 16-bit words
0x3 = Burst Write, 32-bit words
0x4 = Burst Write, 64-bit words
0x5 = Burst Read, 8-bit words
0x6 = Burst Read, 16-bit words
0x7 = Burst Read, 32-bit words
0x8 = Burst Read, 64-bit words
47:16 W Address
The first AXI4 address which will be read from or written to
0:15 W Count
Total number of words to be transferred. Note that this means that
the total number of bits transferred depends both on this field, and
on the opcode. Must be greater than 0.
Table 3: AXI4 module Burst Setup command format

3.2.2 Burst Write

The next time the ADI is accessed after sending a valid burst write command, the
AXI4 module will be in burst write mode. In this mode, commands and data are not
interpreted or executed on transition through UPDATE_DR. Instead, counters are used to
determine position in the bitstream, and a word is written to the AXI4 as soon as it has
been transferred in via JTAG. The total length of a burst write transfer depends on the
word size (set by the opcode) and the count fields in the burst setup command; for a word
size of n and a transfer of m words in hi-speed mode, the total length will be (n * m) + 34.
The first bit transferred in a burst write is a '1' start bit. This tells the AXI4
module to begin counting bits, and is required due to the possibility of multiple devices
on the JTAG chain. After the start bit, one word of data is transferred into the ADI. In
legacy mode, this word is followed by a status bit, which is transferred out of the ADI, to

Rev 2.2 Page 18 of 42

 Advanced Debug Interface 1/22/2015

be read by the software driver. The status bit tells the user whether the AXI4 was ready
to accept the word just transferred; when true, the bus was ready. When false, the word
was not written to the AXI4, and the software driver should retry the transfer, starting
from the failed word. Note that timing of the actual reception of the status bit may vary,
depending on the number of other devices on the JTAG chain.
Eeach data word is immediately followed by another data word, until all words
have been transferred. Immediately following the last data word, a 32-bit CRC code is
transferred into the AXI4 module. This CRC is compared with a CRC computed
internally to the AXI4 module. After the CRC is transferred in, a single bit is transferred
out of the ADI, indicating whether or not the CRC written matched the CRC calculated.
A burst write transaction may be aborted at any time by moving the TAP through the
UPDATE_DR state.
The CRC protects only the data bits in a burst transaction; commands and status
bits are not included in the CRC computation. The CRC resets before each burst
transaction. For more information on the CRC calculation, see chapter 6.
AXI4 bus errors are captured during a burst, but the information is not transferred
during the burst transaction. After a burst, the user should check the AXI4 module error
register to see if a bus error occurred during the burst, and if so, at what address. See the
section on AXI4 sub-module internal registers for details on the error register.
Note that extra bits sent at the end of a burst write are ignored; thus, the user need
not worry about sending a valid or safe operation/opcode at the end of the burst
transaction.

Figure 6: Burst Write format

Sent m times

Match CRC Data 1

(word length n)
(m*n)+ 33 (m *n)+ 1 0

Rev 2.2 Page 19 of 42

 Advanced Debug Interface 1/22/2015

Bits Access Description

1 bit R Match
'1' if CRC sent matches internal CRC computation, '0' if not
32 bits W CRC
32-bit CRC computed on all of the data bits of the burst
n bits W Data
Data word. Length specified by the opcode in the burst setup
command. Sent m times.
1 bit W Start Bit
Set to '1' to indicate the start of a burst write.
Table 4: AXI4 module burst write format

3.2.3 Burst Read

The next time the ADI is accessed after sending a valid burst read command, the
AXI4 module will be in burst read mode. In this mode, commands and data are not
interpreted or executed on transition through UPDATE_DR. Instead, counters are used to
determine position in the bitstream, and a word is read from the AXI4 while the previous
data word is transferred out via JTAG. The total length of a burst read transfer depends
on the word size (set by the opcode) and the count fields in the burst setup command; for
a word size of n and a transfer of m words, the total length will be (n * m) + 33.
The first bit (or bits) transferred during a burst read, whether legacy or hi-speed
mode, is a status bit. This bit indicates whether or not data from the AXI4 is ready to be
transferred out via JTAG. The AXI4 module will send '0' bits until a word is ready, then
send a single '1' bit. One data word will follow a '1' status bit. This bit is required even in
hi-speed mode, because the clock domain synchronization to the AXI4 bus interface
requires several JTAG clocks, which means that data will not be ready for reading when
the first status bit is sent. However, status bit(s) are only used before the first data word
in hi-speed mode; the second data word follows immediately after the first, and so on.
Immediately following the last data word, a 32-bit CRC code is sent from the
AXI4 module to the driver software. The driver software should compare the CRC
received with one computed internally, to determine whether or not the complete
transaction must be retried.
The CRC protects only the data bits in a burst transaction; commands and status
bits are not included in the CRC computation. The CRC resets before each burst
transaction. For more information on the CRC calculation, see chapter 6.

Rev 2.2 Page 20 of 42

 Advanced Debug Interface 1/22/2015

AXI4 bus errors are captured during a burst, but the information is not transferred
during the burst transaction. After a burst, the user should check the AXI4 module error
register to see if a bus error occurred during the burst, and if so, at what address. See the
section on AXI4 sub-module internal registers for details on the error register.
Note that extra bits sent at the end of a burst read are ignored; thus, the user need
not worry about sending a valid or safe operation/opcode at the end of the burst
transaction.

Figure 7: Burst Read format

Sent m times

CRC Data Status

(word length n)

(m * n)+1 0
Access

Bits Description

32 bits R CRC
32-bit CRC computed on all of the data bits of the burst
n bits R Data
Data word. Length specified by the opcode in the burst setup
command. Sent m times.
1 bit R Status
Read '0' until a word is ready to be sent, then a single '1' bit is sent
before the data word. This is only sent before the first data word.
Table 5: AXI4 module burst read format

3.2.4 Register Select

A register select command will make the module-internal register with the given
index active (in the currently selected sub-module). While any register in the current
module can be written with a single command, only the active register can be read.

Rev 2.2 Page 21 of 42

 Advanced Debug Interface 1/22/2015

When the TAP enters CAPTURE_DR mode, the AXI4 module captures the value
of the active register into the output shift register, allowing the value to be read when the
TAP is in SHIFT_DR mode. This will happen each time a command is sent to the AXI4
module, unless the previous command was a burst setup.
The register select command uses the same top-level select bit and opcode format
as the other AXI4 module commands. In this case, the opcode is followed by a 1-bit
value, which is the index of the register which should be made active. See the API
section on registers for a complete listing of all registers in the AXI4 module, and the
meaning of each.

Figure 8: Register Select command format

0 Opcode Index
5 1 0
Access

Bit # Description

5 W Top-Level Select
Set to '0' for all sub-module commands
4:1 W Opcode
Operation to perform.
0xD = Internal Register Select
0 W Index
Index of the register to make active. The AXI4 module uses a 1-bit
index.
Table 6: AXI4 module Register Select command format

3.2.5 Register Read

There is no specific command to read a module internal register; the value of the
active register is shifted out every time a command is shifted in. In order to read a
particular register, make that register active using the register select command, then read
out the value of the register while sending a NOP command. The length of each register
may vary, and the meaning of each bit is also register-specific. The register data will be
LSB-aligned; that is, the LSB of the register data will be the first bit shifted out of the
ADI. This allows the minimum number of JTAG bits to be transferred. It is legal to read

Rev 2.2 Page 22 of 42

 Advanced Debug Interface 1/22/2015

more bits than the active register has – the additional bits will have undefined value, and
should be discarded. Note that only register data will be transferred out, no command,
index, opcodes, start, or status bits will be sent with it. It is legal to abort a register read
at any time, provided that a valid command (probably a NOP) is in the correct position in
the input shift register.

3.2.6 Register Write

A register write command contains both a register index, and data to be written to
the register at that index. The register with the given index will become the active
register after this command is executed. Note that the value of the previously active
register will be shifted out as this command is shifted in. The length of the data field is
variable, and depends on the particular register being written. See the API section on
registers for a complete description of the registers, their lengths, and their meanings.

Figure 9: Register Write command format

0 Opcode Index Data

n+5 n+1 n 0
Access

Bit # Description

5+n W Top-Level Select

Set to '0' for all sub-module commands
(4:1) + n W Opcode
Operation to perform.
0x9 = Internal Register Write
n W Index
Index of the register to make active. The AXI4 module uses a 1-bit
index.
n-1:0 W Data
n bits of data to write to the register specified by Index. n depends
on the register being written.
Table 7: AXI4 module Register Write command format

Rev 2.2 Page 23 of 42

 Advanced Debug Interface 1/22/2015

3.2.7 NOP

A NOP command will perform no operation. It is included as a “safe” command

to shift into the AXI4 module while shifting out internal register data. A NOP command
consists of five or more zeros, making it easy to send for any length of data read.

Figure 10: NOP command format

0 Opcode 0 or more '0'

n+4 n 0
Access

Bit # Description

4+n W Top-Level Select

Set to '0' for all sub-module commands
(3:0) W Opcode
+n Operation to perform.
0x0 = NOP
n:0 W Zero
Zero or more '0' bits
Table 8: AXI4 module NOP command format

3.3 CPU Commands

The CPU sub-module uses the same standardized command format as the AXI4
module. Each command must have a zero as the MSBit, to differentiate it from a module
select command. In the next four most-significant bit positions is a 4-bit opcode, which
indicates the operation to be performed. Following the opcode are zero or more data
values, whose length and meaning are command-specific. Table 9 summarizes the
opcodes supported in the CPU module.

Rev 2.2 Page 24 of 42

 Advanced Debug Interface 1/22/2015

OPCODE Operation

0x0 NOP

0x3 Burst Setup Write, 32-bit words

0x7 Burst Setup Read, 32-bit words

0x9 Internal register write

0xD Internal register select

Table 9: CPU module command opcode summary

3.3.1 Burst Setup

A burst setup command prepares the CPU module to do either a read or write
burst, in order to move data to or from a consecutive sequence of address on the
OR1ON's SPR bus. Because all SPRs are 32-bit registers, all burst transfers in the CPU
module use 32-bit words. After each individual word transfer during a burst, the address
counter in the CPU module is incremented by 1. Note that while the OR1000
architecture defines an SPR address as 16 bits, the OR1ON implementation uses a 32-bit
address in its external debug interface. The ADI is designed to use the 32-bit OR1ON
implementation.
After a burst setup command has been executed (in the UPDATE_DR state), the
CPU module will enter 'burst read' or 'burst write' mode, the next time the TAP enters
SHIFT_DR mode. Whether read or write mode is used depends on the opcode sent with
the burst setup command. Details on burst read and burst write modes are in the
following sections.

Figure 11: Burst Setup command

0 Opcode CPU Sel. Address Count

56 52 48 16 0

Rev 2.2 Page 25 of 42

 Advanced Debug Interface 1/22/2015

Access
Bit # Description

56 W Top-Level Select
Set to '0' for all sub-module commands
52:55 W Opcode
Operation to perform. The following opcodes are valid burst setup
operations for the CPU module:
0x3 = Burst Write, 32-bit words
0x7 = Burst Read, 32-bit words
48:51 W CPU Select
Selects the CPU to write to
47:16 W Address
The first OR1ON SPR address which will be read or written
0:15 W Count
Total number of 32-bit words to be transferred.
Table 10: CPU module Burst Setup command format

3.3.2 Burst Write

The next time the ADI is accessed after sending a valid burst write command, the
CPU module will be in burst write mode. In this mode, commands and data are not
interpreted or executed on transition through UPDATE_DR. Instead, counters are used to
determine position in the bitstream, and a word is written to the CPU SPR bus as soon as
it has been transferred in via JTAG. The total length of a burst write transfer depends on
the count field in the burst setup command; for a transfer of m words , the total length
will be (32 * m) + 38.
The first bit transferred in a burst write is a '1' start bit. This tells the CPU module
to begin counting bits, and is required due to the possibility of multiple devices on the
JTAG chain. After the start bit, one word of data is transferred into the ADI.
In legacy mode, a data word is followed by a status bit, which is transferred out of
the ADI, and should be read by the software driver. The status bit tells the user whether
the OR1ON was ready to accept the word just transferred; when true, the bus was ready.
When false, the word was not written to the SPR bus, and the software driver should retry
the transfer, starting from the failed word. Note that timing of the actual reception of the
status bit may vary, depending on the number of other devices on the JTAG chain.

Rev 2.2 Page 26 of 42

 Advanced Debug Interface 1/22/2015

In legacy mode, data transmission continues to alternate data word and status bit
until all words have been transferred. In hi-speed mode, a data word is followed
immediately by another data word, until all words are transferred.
Immediately following the last data word (in hi-speed mode) or status bit (in
legacy mode), a 32-bit CRC code is transferred into the CPU module. This CRC is
compared with a CRC computed internally to the CPU module. After the CRC is
transferred in, a single bit is transferred out of the ADI, indicating whether or not the
CRC written matched the CRC calculated. A burst write transaction may be aborted at
any time by moving the TAP through the UPDATE_DR state.
The CRC protects only the data bits in a burst transaction; commands and status
bits are not included in the CRC computation. The CRC resets before each burst
transaction. For more information on the CRC calculation, see chapter 6.
The OR1ON SPR bus does not provide any sort of error indication beyond ready /
not ready. As such, there is no error register to be tested after a burst (as opposed to the
AXI4 module, which has such a register).
Note that extra bits sent at the end of a burst write are ignored; thus, the user need
not worry about sending a valid or safe operation/opcode at the end of the burst
transaction.

Figure 12: Burst Write format

Sent m times

Match CRC Data 1

(32 bits)
(m * 32) + 33 (m * 32) + 1 0

Rev 2.2 Page 27 of 42

 Advanced Debug Interface 1/22/2015

Bits Access Description

1 bit R Match
'1' if CRC sent matches internal CRC computation, '0' if not
32 bits W CRC
32-bit CRC computed on all of the data bits of the burst
n bits W Data
32-bit data word. Sent m times.
1 bit W Start Bit
Set to '1' to indicate the start of a burst write.
Table 11: CPU module burst write format

3.3.3 Burst Read

The next time the ADI is accessed after sending a valid burst read command, the
CPU module will be in burst read mode. In this mode, commands and data are not
interpreted or executed on transition through UPDATE_DR. Instead, counters are used to
determine position in the bitstream, and a word is read from the CPU SPR bus while the
previous data word is transferred out via JTAG. The total length of a burst read transfer
depends on the count field in the burst setup command; for a transfer of m words, the
total length will be (32 * m) + 33, or (33 * m) + 32 in legacy mode.
The first bit (or bits) transferred during a burst read is a status bit. This bit
indicates whether or not data from the SPR bus is ready to be transferred out via JTAG.
The CPU module will send '0' bits until a word is ready, then send a single '1' bit. A data
word will follow a '1' status bit. This first status bit is required in either speed mode –
due to the time domain synchronization, a data word will not be ready when the first
status bit is sent.
In legacy mode, a status bit (or bits) is transferred before each data word. Data
transmission continues to alternate status bits and data words until all words have been
transferred. In hi-speed mode, a status bit is sent only before the first data word. After
that, each data word immediately follows the previous data word until all data has been
sent.
Immediately following the last data word, a 32-bit CRC code is sent from the
CPU module to the driver software. The driver software should compare the CRC
received with one computed internally, to determine whether or not the complete
transaction must be retried.

Rev 2.2 Page 28 of 42

 Advanced Debug Interface 1/22/2015

The CRC protects only the data bits in a burst transaction; commands and status
bits are not included in the CRC computation. The CRC resets before each burst
transaction. For more information on the CRC calculation, see chapter 6.
The OR1ON SPR bus does not provide any error indication for failed transactions
beyond ready / not ready. Thus, there is no error register to check after a burst is
completed (as opposed to the AXI4 module).
Note that extra bits sent at the end of a burst read are ignored; thus, the user need
not worry about sending a valid or safe operation/opcode at the end of the burst
transaction.

Figure 13: Burst Read format

Sent m times

CRC Data Status

(32 bits)

(m * 32)+1 0
Access

Bits Description

32 bits R CRC
32-bit CRC computed on all of the data bits of the burst
n bits R Data
Data word. Length specified by the opcode in the burst setup
command. Sent m times.
1 bit R Status
Read '0' until a word is ready to be sent, then a single '1' bit is sent
before the data word. Only sent before the first data word.
Table 12: CPU module burst read format

3.3.4 Register Select

A register select command will make the module-internal register with the given
index active (in the currently selected sub-module). While any register in the current
module can be written with a single command, only the active register can be read.

Rev 2.2 Page 29 of 42

 Advanced Debug Interface 1/22/2015

When the TAP enters CAPTURE_DR mode, the CPU module captures the value
of the active register into the output shift register, allowing the value to be read when the
TAP is in SHIFT_DR mode. This will happen each time a command is sent to the CPU
module, unless the previous command was a burst setup.
The register select command uses the same top-level select bit and opcode format
as the other module commands. In this case, the opcode is followed by a 1-bit value,
which is the index of the register which should be made active. See the API section on
register for a complete listing of all registers in the CPU module, and the meaning of
each.

Figure 14: Register Select command format

0 Opcode Index
7 3 0
Access

Bit # Description

7 W Top-Level Select
Set to '0' for all sub-module commands
6:3 W Opcode
Operation to perform.
0xD = Internal Register Select
2:0 W Index
Index of the register to make active. The CPU module uses a 3-bit
index.
Table 13: CPU module Register Select command format

3.3.5 Register Read

There is no specific command to read a module internal register; the value of the
active register is shifted out every time a command is shifted in. In order to read a
particular register, make that register active using the register select command, then read
out the value of the register while sending a NOP command. The length of each register
may vary, and the meaning of each bit is also register-specific. The register data will be
LSB-aligned; that is, the LSB of the register data will be the first bit shifted out of the

Rev 2.2 Page 30 of 42

 Advanced Debug Interface 1/22/2015

ADI. This allows the minimum number of bits to be transferred over the JTAG, and
allows the user to ignore the total length of the output shift register. It is legal to read
more bits than the active register has – the additional bits will have undefined values, and
should be discarded. Note that only register data will be transferred out; no command,
index, opcodes, start, or status bits will be sent with it. It is legal to abort a register read
at any time, provided that a valid command (probably a NOP) is in the correct position in
the input shift register.

3.3.6 Register Write

A register write command contains both a register index and data to be written to
the register at that index. The register with the given index will become the active
register after this command is executed. Note that the value of the previously active
register will be shifted out as this command is shifted in. The length of the data field is
variable, and depends on the particular register being written. See the API section on
registers for a complete description of the registers, their lengths, and their meanings.

Figure 15: Register Write command format

0 Opcode Index Data

n+7 n+3 n 0

Rev 2.2 Page 31 of 42

 Advanced Debug Interface 1/22/2015

Bit # Access Description

7+n W Top-Level Select

Set to '0' for all sub-module commands
(6:3) + n W Opcode
Operation to perform.
0x9 = Internal Register Write
(2:0) + n W Index
Index of the register to make active. The CPU module uses a 3-bit
index.
n-1:0 W Data
n bits of data to write to the register specified by Index. n depends
on the register being written.
Table 14: CPU module Register Write command format

3.3.7 NOP

A NOP command will perform no operation. It is included as a “safe” command

to shift into the CPU module while shifting out internal register data. A NOP command
consists of five or more zeros, making it easy to send for any length of data read.

Figure 16: NOP command format

0 Opcode 0 or more '0'

n+4 n 0

Rev 2.2 Page 32 of 42

 Advanced Debug Interface 1/22/2015

Access
Bit # Description

4+n W Top-Level Select

Set to '0' for all sub-module commands
(3:0) W Opcode
+n Operation to perform.
0x0 = NOP
n:0 W Zero
Zero or more '0' bits
Table 15: CPU module NOP command format

3.4 AXI4 Module Registers

Table 16 summarizes all of the registers contained within the AXI4 sub-module.
Note that the data format of a register may be different depending on whether it is read or
written; this saves the user from having to shift in extra bits to fill read-only values when
writing.

Index Register name

0x0 Error register

Table 16: AXI4 module register summary

3.4.1 Error Register

The error register captures AXI4 bus errors during burst transactions. Each time a
bus access is completed, the AXI4 error indicator bit (wb_err) is tested. If an error is
present, then the error bit in the error register is set to '1', and the address of the failed
access is stored in the rest of the error register. Once the error bit is set, the error register
will retain its value and further AXI4 errors will be ignored until the error bit is reset.
The error bit may only be reset by writing a '1' to the error bit via an internal register
write.
When read, the error bit is the first bit shifted out. This allows transferring the
minimum number of bits when testing whether an error has occurred (5 bits must be

Rev 2.2 Page 33 of 42

 Advanced Debug Interface 1/22/2015

transferred in order to send a valid NOP command while reading). If an error has
occurred, then an error handling routine in the driver software can read the error register
again to get the 32-bit error address – the value will not change until the error bit is reset.
When written, the error register consists of a single bit, the error bit. This should
be written as '1' in order to clear the error bit and re-enable error detection.

Figure 17: AXI4 module Error Register, as read

Address Err
33 1 0

Figure 18: AXI4 module Error Register, as written

Err
1 0
Access

Bit # Description

33:1 R Address
When error bit = '1', contains the address of the failed transaction
0 R Err (when read)
Error bit. Set to '1' when a AXI4 error has occurred since the last
time the error bit was reset.
0 W Err (when written)
Write as '1' to reset the error bit to '0' and re-enable error detection
Table 17: AXI4 module Error Register format

Rev 2.2 Page 34 of 42

 Advanced Debug Interface 1/22/2015

3.5 CPU Module Registers

Table 18 summarizes all of the registers present within the CPU sub-module.

Index Register name

0x0 Status register

0x1 Group1 OR mask

0x2 Group1 AND mask

0x3 Group2 OR mask

0x4 Group2 AND mask

Table 18: CPU module register summary

3.5.1 Status Register

The status register is used to detect and control breakpoint conditions. The format
is the same whether read or written.
The register is NB_CORES bit long and each bit of the status register detects
breakpoint condition for a particular core, and controls the stall line to the same CPU.
When written '1' via internal register write, the stall line to the CPU is made active, and
the CPU stops executing instructions (but retains the ability to resume). When written '0',
the stall line is negated, and the CPU resumes execution. The stall bit will also be set
when the breakpoint output of the CPU goes active. The breakpoint output will be
registered, the stall bit will be set, and the CPU will be held in the stall state by the ADI.
This condition must be detected by polling in the software driver – once stalled due to a
breakpoint, the CPU cannot resume execution until the stall bit is reset to '0' by an
internal register access via JTAG.

Figure 19: CPU module Status register

Stall …. Stall Stall

CPU N-1 CPU1 CPU0

n-1 1 0

Rev 2.2 Page 35 of 42

 Advanced Debug Interface 1/22/2015

Access

Bit # Description

15:0 R/W Stall CPUn

Set to '1' to suspend execution in the CPUn. Set to '0' to resume.
Will be set to '1' automatically when a breakpoint indicator arrives
from the CPU.
Table 19: CPU module Status Register format

Rev 2.2 Page 36 of 42

 Advanced Debug Interface 1/22/2015

4
IO Ports

4.1 TAP Ports

The Advanced Debug Interface connects to the TAP controller with the
signals shown in Table 20.
Direction
Width

Port Description

tck_i 1 input Test clock input

tdi_i 1 input Test data input
tdo_o 1 output Test data output
shift_dr_i 1 input TAP controller state “Shift DR”
pause_dr_i 1 input TAP controller state “Pause DR”
update_dr_i 1 input TAP controller state “Update DR”
capture_dr_i 1 Input TAP controller state “Capture DR”
rst_i 1 input Reset signal.
debug_select_i 1 input Instruction DEBUG is activated
Table 20: TAP Ports

Rev 2.2 Page 37 of 42

 Advanced Debug Interface 1/22/2015

4.2 CPU Ports

For each CPU module included, one set of I/O lines for that module will be
present. The 'n' in the port name will be replaced with the CPU module number, always
starting from 0. These lines are shown in Error: Reference source not found.
Width

Direction

Port Description

cpun_clk_i 1 input CPU clock signal.

cpun_addr_o 32 output CPU address
cpun_data_i 32 input CPU data input (data from CPU)
cpun_data_o 32 output CPU data output (data to CPU)
cpun_bp_i 1 input CPU breakpoint
cpun_stall_o 1 output CPU stall (selected CPU is stalled)
cpun_stb_o 1 output CPU strobe
CPU write enable signal indicates a write cycle when
cpun_we_o 1 output
asserted high (read cycle when low).
cpun_ack_i 1 input CPU acknowledge (signals end of cycle)
cpun_rst_o 1 output CPU reset output (resets CPU)
Table 21: CPU Ports

4.3 AXI4 Ports

The AXI4 module, if included, will add a set of AXI4 initiator interface signals to
the top-level IO, as described in Error: Reference source not found.
Width

Direction

Port Description

wb_clk_i 1 input AXI4 clock

wb_rst_i 1 Input AXI4 reset signal

Rev 2.2 Page 38 of 42

 Advanced Debug Interface 1/22/2015

Width

Direction
Port Description

AXI4 acknowledge indicates a normal cycle

wb_ack_i 1 input
termination
wb_adr_o 32 output AXI4 address output
wb_cyc_o 1 output AXI4 cycle encapsulates a valid transfer cycle.
wb_dat_i 32 input AXI4 data input (data from AXI4)
wb_dat_o 32 output AXI4 data output (data to AXI4)
AXI4 error acknowledge indicates an abnormal cycle
wb_err_i 1 input
termination
AXI4 select indicates which bytes are valid on the
wb_sel_o 4 output
data bus.
wb_stb_o 1 output AXI4 strobe indicates a valid transfer.
AXI4 write enable indicates a write cycle when
wb_we_o 1 output
asserted high (read cycle when low).
AXI4 consecutive address burst indicates a burst
wb_cab_o 1 output
cycle. (always false)
AXI4 cycle type identifier indicates type of cycle
wb_cti_o 3 output
(single, burst, end of burst) (always single)
wb_bte_o 2 output AXI4 burst type extension (always 0)
Table 22: AXI4 Ports

Rev 2.2 Page 39 of 42

 Advanced Debug Interface 1/22/2015

5
Module Configuration

The Advanced Debug Interface supports three options, which allow the user to
configure which sub-modules will be included when the design is synthesized.

Option: DBG_AXI4_SUPPORTED
Use: Define this option if you want to include a AXI4 module in the ADI. Default is
defined.

Option: DBG_CPU_SUPPORTED
Use: Define this option if you want to include one or more OR1ON CPU debug
modules. Default is defined.

Option: DBG_CPU_NUM
Use: Define the number of OR1ON CPU debug module to be instantiated. Default is 4.

Option: ADBG_USE_HISPEED
Use: Define this option to synthesize the AXI4 and OR1ON modules in hi-speed mode.
This mode allows an order-of-magnitude improvement in data transfer speed when using
USB JTAG cables, at the cost of some error detection. Default is defined.

Rev 2.2 Page 40 of 42

 Advanced Debug Interface 1/22/2015

6
CRC Module

A CRC calculation module is contained within each AXI4 and CPU sub-module.
The CRC module is active only during burst read and write transactions. It calculates a
32-bit CRC on only the data bits of the transaction, starting with the LSB of the first word
transferred, and ending with the MSB of the last word transferred.
In order to simplify the hardware, it was desirable to have the shift performed
during the CRC calculation be in the same direction as the shift required to read out the
CRC serially, LSB-first. This is the reverse of previous CRC implementations. As such,
the CRC polynomial used is also the bitwise-reverse of the standard Ethernet CRC-32
polynomial: 0xEDB88320. A C-language routine for computing a compatible CRC, up
to 32 bits at a time, is reproduced below. When computing a CRC for multiple words, the
output of the last call to compute_crc() should be passed to the next call as crc_in.
When calling compute_crc() for the first word of a burst, crc_in should be set to
0xFFFFFFFF.

Rev 2.2 Page 41 of 42

 Advanced Debug Interface 1/22/2015

#define CRC_POLY 0xEDB88320

uint32_t compute_crc(uint32_t crc_in, uint32_t data_in,

int length_bits)
{
uint32_t crc_out, c, d;
int i;

crc_out = crc_in;
for(i = 0; i < length_bits; i++) {
d = ((data_in >> i) & 0x1) ? 0xffffffff : 0x0;
c = (crc_out & 0x1) ? 0xffffffff : 0x0;
crc_out = crc_out >> 1;
crc_out = crc_out ^ ((d ^ c) & CRC_POLY);
}

return crc_out;
}

Rev 2.2 Page 42 of 42