Analog Devices, Inc. reserves the right to change this product without
prior notice. Information furnished by Analog Devices is believed to be
accurate and reliable. However, no responsibility is assumed by Analog
Devices for its use; nor for any infringement of patents or other rights of
third parties which may result from its use. No license is granted by implication or otherwise under the patent rights of Analog Devices, Inc.
Trademark and Service Mark Notice
The Analog Devices logo, Blackfin, EZ-KIT Lite, SHARC, TigerSHARC,
and VisualDSP++ are registered trademarks of Analog Devices, Inc.
All other brand and product names are trademarks or service marks of
their respective owners.
CONTENTS
PREFACE
Purpose of This Manual ............................................................. xxxi
Thank you for purchasing and developing systems using an enhanced
Blackfin® processor from Analog Devices.
Purpose of This Manual
The ADSP-BF59x Blackfin Processor Hardware Reference provides architec-
tural information about the ADSP-BF59x processors. This hardware
reference provides the main architectural information about these processors. The architectural descriptions cover functional blocks, buses, and
ports, including all features and processes that they support. For programming information, see the Blackfin Processor Programming Reference. For
timing, electrical, and package specifications, see the ADSP-BF592 Black-fin Processor Data Sheet.
Intended Audience
The primary audience for this manual is a programmer who is familiar
with Analog Devices processors. The manual assumes the audience has a
working knowledge of the appropriate processor architecture and instruction set. Programmers who are unfamiliar with Analog Devices processors
can use this manual, but should supplement it with other texts, such as
hardware reference and programming reference manuals, that describe
their target architecture.
•Chapter 1, “Introduction”
Provides a high level overview of the processor, including peripherals, power management, and development tools.
•Chapter 2, “Memory”
Describes processor-specific memory topics, including L1memories
and processor-specific memory MMRs.
•Chapter 3, “Chip Bus Hierarchy”
Describes on-chip buses, including how data moves through the
system.
•Chapter 4, “System Interrupts”
Describes the system peripheral interrupts, including setup and
clearing of interrupt requests.
•Chapter 5, “Direct Memory Access”
Describes the peripheral DMA and Memory DMA controllers.
Includes performance, software management of DMA, and DMA
errors.
•Chapter 6, “Dynamic Power Management”
Describes the clocking, including the PLL, and the dynamic power
management controller.
•Chapter 7, “General-Purpose Ports”
Describes the general-purpose I/O ports, including the structure of
each port, multiplexing, configuring the pins, and generating
interrupts.
•Chapter 8, “General-Purpose Timers”
Describes the eight general-purpose timers.
•Chapter 9, “Core Timer”
Describes the core timer.
•Chapter 10, “Watchdog Timer”
Describes the watchdog timer.
•Chapter 11, “UART Port Controllers”
Describes the Universal Asynchronous Receiver/Transmitter port
that converts data between serial and parallel formats. The UART
supports the half-duplex IrDA® SIR protocol as a mode-enabled
feature.
•Chapter 12, “Two Wire Interface Controller”
Describes the Two Wire Interface (TWI) controller, which allows a
device to interface to an Inter IC bus as specified by the Philips IBus Specification version 2.1 dated January 2000.
•Chapter 13, “SPI-Compatible Port Controller”
Describes the Serial Peripheral Interface (SPI) port that provides an
I/O interface to a variety of SPI compatible peripheral devices.
2
C
•Chapter 14, “SPORT Controller”
Describes the independent, synchronous Serial Port Controller
which provides an I/O interface to a variety of serial peripheral
devices.
•Chapter 15, “Parallel Peripheral Interface”
Describes the Parallel Peripheral Interface (PPI) of the processor.
The PPI is a half-duplex, bidirectional port accommodating up to
16 bits of data and is used for digital video and data converter
applications.
•Chapter 16, “System Reset and Booting”
Describes the booting methods, booting process and specific boot
modes for the processor.
•Chapter 17, “System Design”
Describes how to use the processor as part of an overall system. It
includes information about bus timing and latency numbers, semaphores, and a discussion of the treatment of unused pins.
•Appendix A, “System MMR Assignments”
Lists the memory-mapped registers included in this manual, their
addresses, and cross-references to text.
•Appendix B, “Test Features”
Describes test features for the processor, discusses the JTAG standard, boundary-scan architecture, instruction and boundary
registers, and public instructions.
This hardware reference is a companion document to the Blackfin
Processor Programming Reference.
What’s New in This Manual
This revision (1.0) is the second release of the ADSP-BF59x Blackfin Processor Hardware Reference. Minor typographical errors have been corrected
in this revision.
Technical or Customer Support
You can reach Analog Devices, Inc. Customer Support in the following
ways:
•Visit the Embedded Processing and DSP products Web site at
•Contact your Analog Devices, Inc. local sales office or authorized
distributor
•Send questions by mail to:
Analog Devices, Inc.
One Technology Way
P.O. Box 9106
Norwood, MA 02062-9106
USA
Registration for MyAnalog.com
Preface
MyAnalog.com is a free feature of the Analog Devices Web site that allows
customization of a Web page to display only the latest information about
products you are interested in. Click Register to use this site. Registration
takes about five minutes and serves as a means to select the information
you want to receive.
If you are already a registered user, just log on. Your user name is your
e-mail address.
EngineerZone
EngineerZone is a technical support forum from Analog Devices. It allows
you direct access to ADI technical support engineers. You can search
FAQs and technical information to get quick answers to your embedded
processing and DSP design questions.
Use EngineerZone to connect with other DSP developers who face similar
design challenges. You can also use this open forum to share knowledge
and collaborate with the ADI support team and your peers. Visit
http://ez.analog.com to sign up.
Social Networking Web Sites
You can now follow Analog Devices SHARC development on Twitter and
LinkedIn. To access:
•Twitter:
•LinkedIn: Network with the LinkedIn group, Analog Devices
SHARC: http://www.linkedin.com
http://twitter.com/ADISHARC
Supported Processors
The following is the list of Analog Devices, Inc. processors supported in
VisualDSP++®.
Blackfin (ADSP-BFxxx) Processors
The name Blackfin refers to a family of 16-bit, embedded processors.
VisualDSP++ currently supports the following Blackfin families
ADSP-BF51x, ADSP-BF52x, ADSP-BF53x, ADSP-BF54x, ADSP-BF59x,
and ADSP-BF561 processors.
TigerSHARC® (ADSP-TSxxx) Processors
The name TigerSHARC refers to a family of floating-point and fixed-point
[8-bit, 16-bit, and 32-bit] processors. VisualDSP++ currently supports the
following TigerSHARC families: ADSP-TS101 and ADSP-TS20x.
The name SHARC refers to a family of high-performance, 32-bit,
floating-point processors that can be used in speech, sound, graphics, and
imaging applications. VisualDSP++ currently supports the following
SHARC families: ADSP-2106x, ADSP-2116x, ADSP-2126x,
ADSP-2136x, and ADSP-214xx.
Product Information
Product information can be obtained from the Analog Devices Web site,
VisualDSP++ online Help system, and a technical library CD.
Analog Devices Web Site
The Analog Devices Web site, www.analog.com, provides information
about a broad range of products—analog integrated circuits, amplifiers,
converters, and digital signal processors.
To access a complete technical library for each processor family, go to
http://www.analog.com/processors/technical_library. The manuals
selection opens a list of current manuals related to the product as well as a
link to the previous revisions of the manuals. When locating your manual
title, note a possible errata check mark next to the title that leads to the
current correction report against the manual.
Also note,
MyAnalog.com is a free feature of the Analog Devices Web site
that allows customization of a Web page to display only the latest information on products you are interested in. You can also choose to receive
weekly e-mail notifications containing updates to the Web pages that meet
your interests, including documentation errata against all manuals.
MyAnalog.com provides access to books, application notes, data sheets,
www.myanalog.com to sign up. If you are already a registered user, just
log on. Your user name is your e-mail address.
VisualDSP++ Online Documentation
Online documentation comprises the VisualDSP++ Help system, software
tools manuals, hardware tools manuals, processor manuals, Dinkum
Abridged C++ library, and FLEXnet License Tools software
documentation. You can search easily across the entire VisualDSP++ documentation set for any topic of interest.
For easy printing, supplementary Portable Documentation Format (.pdf)
files for all manuals are provided on the VisualDSP++ installation CD.
Each documentation file type is described as follows.
File Description
.chmHelp system files and manuals in Microsoft help format
.htm or
.html
.pdfVisualDSP++ and processor manuals in PDF format. Viewing and printing the
Dinkum Abridged C++ library and FLEXnet License Tools software documentation. Viewing and printing the
Explorer 6.0 (or higher).
.pdf files requires a PDF reader, such as Adobe Acrobat Reader (4.0 or higher).
.html files requires a browser, such as Internet
Technical Library CD
The technical library CD contains seminar materials, product highlights, a
selection guide, and documentation files of processor manuals,
VisualDSP++ software manuals, and hardware tools manuals for the following processor families: Blackfin®, SHARC, TigerSHARC®,
ADSP-218x, and ADSP-219x.
To order the technical library CD, go to
sors/manuals
, navigate to the manuals page for your processor, click the
request CD check mark, and fill out the order form.
Data sheets, which can be downloaded from the Analog Devices Web site,
change rapidly, and therefore are not included on the technical library
CD. Technical manuals change periodically. Check the Web site for the
latest manual revisions and associated documentation errata.
Notation Conventions
Text conventions used in this manual are identified and described as follows. Additional conventions, which apply only to specific chapters, may
appear throughout this document.
ExampleDescription
Close command
(File menu)
{this | that}Alternative required items in syntax descriptions appear within curly
[this | that]Optional items in syntax descriptions appear within brackets and sepa-
[this,…]Optional item lists in syntax descriptions appear within brackets delim-
SECTIONCommands, directives, keywords, and feature names are in text with let-
.
filenameNon-keyword placeholders appear in text with italic style format.
Titles in reference sections indicate the location of an item within the
VisualDSP++ environment’s menu system (for example, the Close command appears on the File menu).
brackets and separated by vertical bars; read the example as this or that.
One or the other is required.
rated by vertical bars; read the example as an optional this or that.
ited by commas and terminated with an ellipse; read the example as an
optional comma-separated list of
ter gothic
Note: For correct operation, ...
A Note provides supplementary information on a related topic. In the
online version of this book, the word Note appears instead of this symbol.
Caution: Incorrect device operation may result if ...
Caution: Device damage may result if ...
A Caution identifies conditions or inappropriate usage of the product that
could lead to undesirable results or product damage. In the online version
of this book, the word Caution appears instead of this symbol.
War ni ng : Injury to device users may result if ...
A Warning identifies conditions or inappropriate usage of the product
that could lead to conditions that are potentially hazardous for the devices
users. In the online version of this book, the word War ni ng appears
instead of this symbol.
The ADSP-BF59x processors are members of the Blackfin processor family that offer significant high performance and low power features while
retaining their ease-of-use benefits.
This hardware reference is a companion document to the Blackfin
Processor Programming Reference.
General Description of Processor
The ADSP-BF59x processor is a member of the Blackfin® family of products, incorporating the Analog Devices/Intel Micro Signal Architecture
(MSA). Blackfin processors combine a dual-MAC state-of-the-art signal
processing engine, the advantages of a clean, orthogonal RISC-like microprocessor instruction set, and single-instruction, multiple-data (SIMD)
multimedia capabilities into a single instruction-set architecture.
The ADSP-BF59x processor is completely code compatible with other
Blackfin processors. ADSP-BF59x processors offer performance up to
400 MHz and reduced static power consumption. The processor features
are shown in Table 1-1.
By integrating a rich set of industry-leading system peripherals and memory, Blackfin processors are the platform of choice for next-generation
applications that require RISC-like programmability, multimedia support,
and leading-edge signal processing in one integrated package.
1 Maximum instruction rate is not available with every
possible SCLK selection.
Portable Low-Power Architecture
Blackfin processors provide world-class power management and performance. They are produced with a low-power and low-voltage design
methodology and feature on-chip dynamic power management, which
provides the ability to vary both the voltage and frequency of operation to
significantly lower overall power consumption. This capability can result
in a substantial reduction in power consumption, compared with just
Most of the peripherals are supported by a flexible DMA structure. There
are also two separate memory DMA channels dedicated to data transfers
between the processor’s memory spaces. Multiple on-chip buses provide
enough bandwidth to keep the processor core running even when there is
also activity on all of the on-chip and external peripherals.
Figure 1-1. ADSP-BF59x Processor Block Diagram
Memory Architecture
The Blackfin processor architecture structures memory as a single, unified
4G byte address space using 32-bit addresses. All resources, including
internal memory, external memory, and I/O control registers, occupy separate sections of this common address space. The memory portions of this
address space are arranged in a hierarchical structure to provide a good
cost/performance balance of some very fast, low latency on-chip memory,
and larger, lower cost and lower performance off-chip memory systems.
Table 1-2 shows the memory for the ADSP-BF59x processors.
Table 1-2. Memory Configurations
Type of MemoryADSP-BF59x
Instruction SRAM32K byte
Instruction ROM64K byte
Data SRAM32K byte
Data scratchpad SRAM4K byte
L3 Boot ROM4K byte
Total136K byte
Internal Memory
The processor has four blocks of on-chip memory that provide high bandwidth access to the core:
•L1 instruction SRAM memory. This memory is accessed at full
processor speed.
•L1 data SRAM memory. This memory block is accessed at full processor speed.
•L1 scratchpad RAM, which runs at the same speed as the L1 memories but is only accessible as data SRAM.
•L1 instruction ROM memory, accessed at full processor speed.
I/O Memory Space
Blackfin processors do not define a separate I/O space. All resources are
mapped through the flat 32-bit address space. Control registers for
on-chip I/O devices are mapped into memory-mapped registers (MMRs)
at addresses near the top of the 4G byte address space. These are separated
into two smaller blocks: one contains the control MMRs for all core functions and the other contains the registers needed for setup and control of
the on-chip peripherals outside of the core. The MMRs are accessible only
in supervisor mode. They appear as reserved space to on-chip peripherals.
DMA Support
The processor has a DMA controller which supports automated data
transfers with minimal overhead for the core. DMA transfers can occur
between the internal memories and any of its DMA-capable peripherals.
DMA-capable peripherals include the SPORTs, SPI ports, UART, and
PPI. Each individual DMA-capable peripheral has at least one dedicated
DMA channel.
The DMA controller supports both one-dimensional (1D) and
two-dimensional (2-D) DMA transfers. DMA transfer initialization can
be implemented from registers or from sets of parameters called descriptor
blocks.
The 2-D DMA capability supports arbitrary row and column sizes up to
64K elements by 64K elements, and arbitrary row and column step sizes
up to +/- 32K elements. Furthermore, the column step size can be less
than the row step size, allowing implementation of interleaved datastreams. This feature is especially useful in video applications where data
can be de-interleaved on the fly.
Examples of DMA types supported include:
•A single, linear buffer that stops upon completion
•A circular, auto-refreshing buffer that interrupts on each full or
fractionally full buffer
•1-D or 2-D DMA using a linked list of descriptors
•2-D DMA using an array of descriptors specifying only the base
DMA address within a common page
In addition to the dedicated peripheral DMA channels, there are two separate pairs of memory DMA channels provided for transfers between the
various memories of the system. Memory DMA transfers can be controlled
by a very flexible descriptor-based methodology or by a standard register-based autobuffer mechanism.
General-Purpose I/O (GPIO)
The ADSP-BF59x processors have 32 bi-directional, general-purpose I/O
(GPIO) pins allocated across two separate GPIO modules—PORTFIO,
and PORTGIO, associated with port F and port G, respectively. Port J
does not provide GPIO functionality. Each GPIO-capable pin shares
functionality with other ADSP-BF59x processor peripherals via a multiplexing scheme; however, the GPIO functionality is the default state of
the device upon powerup. Neither GPIO output or input drivers are
active by default. Each general-purpose port pin can be individually controlled by manipulation of the port control, status, and interrupt registers:
•GPIO direction control register – Specifies the direction of each
individual GPIO pin as input or output.
•GPIO control and status registers – The ADSP-BF59x processors
employ a “write one to modify” mechanism that allows any combination of individual GPIO pins to be modified in a single
instruction, without affecting the level of any other GPIO pins.
Four control registers are provided. One register is written in order
to set pin values, one register is written in order to clear pin values,
one register is written in order to toggle pin values, and one register
is written in order to specify a pin value. Reading the GPIO status
register allows software to interrogate the sense of the pins.
•GPIO interrupt mask registers – The two GPIO interrupt mask
registers allow each individual GPIO pin to function as an interrupt to the processor. Similar to the two GPIO control registers
that are used to set and clear individual pin values, one GPIO
interrupt mask register sets bits to enable interrupt function, and
the other GPIO interrupt mask register clears bits to disable interrupt function. GPIO pins defined as inputs can be configured to
generate hardware interrupts, while output pins can be triggered by
software interrupts.
•GPIO interrupt sensitivity registers – The two GPIO interrupt sensitivity registers specify whether individual pins are level- or
edge-sensitive and specify—if edge-sensitive—whether just the rising edge or both the rising and falling edges of the signal are
significant. One register selects the type of sensitivity, and one register selects which edges are significant for edge-sensitivity.
Two-Wire Interface
The Two-Wire Interface (TWI) is compatible with the widely used I2C
bus standard. It was designed with a high level of functionality and is
compatible with multi-master, multi-slave bus configurations. To preserve
processor bandwidth, the TWI controller can be set up and a transfer initiated with interrupts only to service FIFO buffer data reads and writes.
Protocol related interrupts are optional.
The TWI externally moves 8-bit data while maintaining compliance with
2
C bus protocol. The Philips I2C Bus Specification version 2.1 covers
the I
many variants of I2C. The TWI controller includes these features:
•Simultaneous master and slave operation on multiple device
systems
•Master clock synchronization and support for clock low extension
•Separate multiple-byte receive and transmit FIFOs
•Low interrupt rate
•Individual override control of data and clock lines in the event of
bus lock-up
•Input filter for spike suppression
•Serial camera control bus support as specified in the OmniVision
Serial Camera Control Bus (SCCB) Functional Specification
version 2.1
Parallel Peripheral Interface
The processor provides a Parallel Peripheral Interface (PPI) that can connect directly to parallel A/D and D/A converters, ITU-R 601/656 video
encoders and decoders, and other general-purpose peripherals. The PPI
consists of a dedicated input clock pin and three multiplexed frame sync
pins. The input clock supports parallel data rates up to half the system
clock rate.
In ITU-R 656 modes, the PPI receives and parses a data stream of 8-bit or
10-bit data elements. On-chip decode of embedded preamble control and
synchronization information is supported.
•Active video only - The PPI does not read in any data between the
End of Active Video (EAV) and Start of Active Video (SAV) preamble symbols, or any data present during the vertical blanking
intervals. In this mode, the control byte sequences are not stored to
memory; they are filtered by the PPI.
•Vertical blanking only - The PPI only transfers Vertical Blanking
Interval (VBI) data, as well as horizontal blanking information and
control byte sequences on VBI lines.
•Entire field - The entire incoming bitstream is read in through the
PPI. This includes active video, control preamble sequences, and
ancillary data that may be embedded in horizontal and vertical
blanking intervals.
Though not explicitly supported, ITU-R 656 output functionality can be
achieved by setting up the entire frame structure (including active video,
blanking, and control information) in memory and streaming the data out
the PPI in a frame sync-less mode. The processor’s 2-D DMA features
facilitate this transfer by allowing the static frame buffer (blanking and
control codes) to be placed in memory once, and simply updating the
active video information on a per-frame basis.
The general-purpose modes of the PPI are intended to suit a wide variety
of data capture and transmission applications. The modes are divided into
four main categories, each allowing up to 16 bits of data transfer per
PPI_CLK cycle:
•Data receive with internally generated frame syncs
•Data receive with externally generated frame syncs
•Data transmit with internally generated frame syncs
•Data transmit with externally generated frame syncs
These modes support ADC/DAC connections, as well as video communication with hardware signalling. Many of the modes support more than
one level of frame synchronization. If desired, a programmable delay can
be inserted between assertion of a frame sync and reception/transmission
of data.
SPORT Controllers
The processor incorporates two dual-channel synchronous serial ports
(SPORT0 and SPORT1) for serial and multiprocessor communications.
The SPORTs support these features:
•Bidirectional, I2S capable operation
Each SPORT has two sets of independent transmit and receive
pins, which enable eight channels of I2S stereo audio.
•Buffered (eight-deep) transmit and receive ports
Each port has a data register for transferring data words to and
from other processor components and shift registers for shifting
data in and out of the data registers.
•Clocking
Each transmit and receive port can either use an external serial
clock or can generate its own in a wide range of frequencies.
•Word length
Each SPORT supports serial data words from 3 to 32 bits in
length, transferred in most significant bit first or least significant
bit first format.
Each transmit and receive port can run with or without frame sync
signals for each data word. Frame sync signals can be generated
internally or externally, active high or low, and with either of two
pulse widths and early or late frame sync.
•Companding in hardware
Each SPORT can perform A-law or µ-law companding according
to ITU recommendation G.711. Companding can be selected on
the transmit and/or receive channel of the SPORT without additional latencies.
•DMA operations with single cycle overhead
Each SPORT can automatically receive and transmit multiple buffers of memory data. The processor can link or chain sequences of
DMA transfers between a SPORT and memory.
•Interrupts
Each transmit and receive port generates an interrupt upon completing the transfer of a data word or after transferring an entire
data buffer or buffers through DMA.
•Multichannel capability
Each SPORT supports 128 channels out of a 1024-channel window and is compatible with the H.100, H.110, MVIP-90, and
HMVIP standards.
The processor has two SPI-compatible ports that enable the processor to
communicate with multiple SPI-compatible devices.
Each SPI interface uses three pins for transferring data: two data pins and
a clock pin. An SPI chip select input pin lets other SPI devices select the
processor, and several SPI chip select output pins let the processor select
other SPI devices. The SPI select pins are reconfigured general-purpose
I/O pins. Using these pins, the SPI port provides a full-duplex, synchronous serial interface, which supports both master and slave modes and
multimaster environments.
Each SPI port’s baud rate and clock phase/polarities are programmable,
and it has an integrated DMA controller, configurable to support either
transmit or receive datastreams. The SPI’s DMA controller can only service unidirectional accesses at any given time.
During transfers, the SPI port simultaneously transmits and receives by
serially shifting data in and out of its two serial data lines. The serial clock
line synchronizes the shifting and sampling of data on the two serial data
lines.
Timers
There are three general-purpose programmable timer units in the processor. Eight timers have an external pin that can be configured either as a
Pulse Width Modulator (PWM) or timer output, as an input to clock the
timer, or as a mechanism for measuring pulse widths of external events.
These timer units can be synchronized to an external clock input connected to the TMRCLK/PPI_CLK pin or to the internal SCLK.
The timer units can be used in conjunction with the UARTs to measure
the width of the pulses in the datastream to provide an autobaud detect
function for a serial channel.
The timers can generate interrupts to the processor core to provide periodic events for synchronization, either to the processor clock or to a count
of external signals.
In addition to the eight general-purpose programmable timers, a 9th timer
is also provided. This extra timer is clocked by the internal processor clock
and is typically used as a system tick clock for generation of operating system periodic interrupts.
UART Port
The processor provides one Universal Asynchronous Receiver/Transmitter
(UART) port, which is fully compatible with PC-standard UARTs. The
UART port provides a simplified UART interface to other peripherals or
hosts, providing half-duplex, DMA-supported, asynchronous transfers of
serial data. The UART port includes support for 5 to 8 data bits; 1 or 2
stop bits; and none, even, or odd parity. The UART port supports two
modes of operation:
•Programmed I/O
The processor sends or receives data by writing or reading
I/O-mapped UART registers. The data is double buffered on both
transmit and receive.
•Direct Memory Access (DMA)
The DMA controller transfers both transmit and receive data. This
reduces the number and frequency of interrupts required to transfer data to and from memory. The UART has two dedicated DMA
channels, one for transmit and one for receive. These DMA channels have lower priority than most DMA channels because of their
relatively low service rates.
The UART’s baud rate, serial data format, error code generation and status, and interrupts can be programmed to support:
•Wide range of bit rates
•Data formats from 7 to 12 bits per frame
•Generation of maskable interrupts to the processor by both transmit and receive operations
In conjunction with the general-purpose timer functions, autobaud detection is supported.
The capabilities of the UART port is further extended with support for
the Infrared Data Association (IrDA
Specification (SIR) protocol.
®
) Serial Infrared Physical Layer Link
Watchdog Timer
The processor includes a 32-bit timer that can be used to implement a
software watchdog function. A software watchdog can improve system
availability by forcing the processor to a known state through generation
of a hardware reset, nonmaskable interrupt (NMI), or general-purpose
interrupt, if the timer expires before being reset by software. The programmer initializes the count value of the timer, enables the appropriate
interrupt, then enables the timer. Thereafter, the software must reload the
counter before it counts to zero from the programmed value. This protects
the system from remaining in an unknown state where software that
would normally reset the timer has stopped running due to an external
noise condition or software error.
If configured to generate a hardware reset, the watchdog timer resets both
the CPU and the peripherals. After a reset, software can determine if the
watchdog was the source of the hardware reset by interrogating a status bit
in the watchdog control register.
The processor can be clocked by an external crystal, a sine wave input, or a
buffered, shaped clock derived from an external clock oscillator.
This external clock connects to the processor’s
cannot be halted, changed, or operated below the specified frequency during normal operation. This clock signal should be a TTL-compatible
signal.
The core clock (CCLK) and system peripheral clock (SCLK) are derived from
the input clock (CLKIN) signal. An on-chip Phase Locked Loop (PLL) is
capable of multiplying the CLKIN signal by a user-programmable (5× to
64×) multiplication factor (bounded by specified minimum and maximum VCO frequencies). The default multiplier is 6×, but it can be modified
by a software instruction sequence. On-the-fly frequency changes can be
made by simply writing to the PLL_DIV register.
CLKIN pin. The CLKIN input
All on-chip peripherals are clocked by the system clock (SCLK). The system
clock frequency is programmable by means of the SSEL[3:0] bits of the
PLL_DIV register.
Dynamic Power Management
The processor provides four operating modes, each with a different performance/power profile. In addition, dynamic power management provides
the control functions to dynamically alter the processor core supply voltage to further reduce power dissipation. Control of clocking to each of the
peripherals also reduces power consumption.
In the full-on mode, the PLL is enabled, not bypassed, providing the maximum operational frequency. This is the normal execution state in which
maximum performance can be achieved. The processor core and all
enabled peripherals run at full speed.
Active Mode (Moderate Power Savings)
In the active mode, the PLL is enabled, but bypassed. Because the PLL is
bypassed, the processor’s core clock (CCLK) and system clock (SCLK) run at
the input clock (CLKIN) frequency. In this mode, the CLKIN to VCO multiplier ratio can be changed, although the changes are not realized until the
full on mode is entered. DMA access is available to appropriately configured L1 memories.
In the active mode, it is possible to disable the PLL through the PLL control register (PLL_CTL). If disabled, the PLL must be re-enabled before
transitioning to the full on or sleep modes.
Sleep Mode (High Power Savings)
The sleep mode reduces power dissipation by disabling the clock to the
processor core (CCLK). The PLL and system clock (SCLK), however, continue to operate in this mode. Typically an external event will wake up the
processor. When in the sleep mode, assertion of any interrupt causes the
processor to sense the value of the bypass bit (
register (PLL_CTL). If bypass is disabled, the processor transitions to the
full on mode. If bypass is enabled, the processor transitions to the active
mode.
When in the sleep mode, system DMA access to L1 memory is not
supported.
The deep sleep mode maximizes dynamic power savings by disabling the
processor core and synchronous system clocks (CCLK and SCLK). Asynchronous systems may still be running, but cannot access internal resources or
external memory. This powered-down mode can only be exited by assertion of the reset interrupt or by an wakeup input. When in deep sleep
mode, a wakeup input interrupt causes the processor to transition to the
active mode. Assertion of RESET while in deep sleep mode causes the processor to transition to the full on mode.
Hibernate State
For lowest possible power dissipation, this state allows the internal supply
(V
DDINT
running. Although not strictly an operating mode like the four modes
detailed above, it is illustrative to view it as such.
) to be powered down, while keeping the I/O supply (V
DDEXT
)
Instruction Set Description
The Blackfin processor family assembly language instruction set employs
an algebraic syntax designed for ease of coding and readability. Refer to
the Blackfin Processor Programming Reference for detailed information. The
instructions have been specifically tuned to provide a flexible, densely
encoded instruction set that compiles to a very small final memory size.
The instruction set also provides fully featured multifunction instructions
that allow the programmer to use many of the processor core resources in
a single instruction. Coupled with many features more often seen on
microcontrollers, this instruction set is very efficient when compiling C
and C++ source code. In addition, the architecture supports both user
(algorithm/application code) and supervisor (O/S kernel, device drivers,
debuggers, ISRs) modes of operation, allowing multiple levels of access to
core resources.
The assembly language, which takes advantage of the processor’s unique
architecture, offers these advantages:
•Embedded 16/32-bit microcontroller features, such as arbitrary bit
and bit field manipulation, insertion, and extraction; integer operations on 8-, 16-, and 32-bit data types; and separate user and
supervisor stack pointers
•Seamlessly integrated DSP/CPU features optimized for both 8-bit
and 16-bit operations
•A multi-issue load/store modified Harvard architecture, which supports two 16-bit MAC or four 8-bit ALU + two load/store + two
pointer updates per cycle
•All registers, I/O, and memory mapped into a unified 4G byte
memory space, providing a simplified programming model
Code density enhancements include intermixing of 16- and 32-bit
instructions with no mode switching or code segregation. Frequently used
instructions are encoded in 16 bits.
Development Tools
The processor is supported with a complete set of CROSSCORE® software and hardware development tools, including Analog Devices
emulators and the VisualDSP++® development environment. The same
emulator hardware that supports other Analog Devices products also fully
emulates the Blackfin processor family.
The VisualDSP++ project management environment lets programmers
develop and debug an application. This environment includes an
easy-to-use assembler that is based on an algebraic syntax, an archiver
(librarian/library builder), a linker, a loader, a cycle-accurate instruction-level simulator, a C/C++ compiler, and a C/C++ runtime library that
includes DSP and mathematical functions. A key point for these tools is
C/C++ code efficiency. The compiler has been developed for efficient
translation of C/C++ code to Blackfin processor assembly. The Blackfin
processor has architectural features that improve the efficiency of compiled C/C++ code.
Debugging both C/C++ and assembly programs with the VisualDSP++
debugger, programmers can:
•View mixed C/C++ and assembly code (interleaved source and
object information)
•Insert breakpoints
•Set conditional breakpoints on registers, memory, and stacks
•Trace instruction execution
•Perform linear or statistical profiling of program execution
•Fill, dump, and graphically plot the contents of memory
•Perform source level debugging
•Create custom debugger windows
The VisualDSP++ Integrated Development and Debugging Environment
(IDDE) lets programmers define and manage software development. Its
dialog boxes and property pages let programmers configure and manage all
development tools, including color syntax highlighting in the VisualDSP++ editor. These capabilities permit programmers to:
•Control how the development tools process inputs and generate
outputs
•Maintain a one-to-one correspondence with the tool’s command-line switches
The VisualDSP++ Kernel (VDK) incorporates scheduling and resource
management tailored specifically to address the memory and timing constraints of DSP programming. These capabilities enable engineers to
develop code more effectively, eliminating the need to start from the very
beginning, when developing new application code. The VDK features
include threads, critical and unscheduled regions, semaphores, events, and
device flags. The VDK also supports priority-based, pre-emptive, cooperative and time-sliced scheduling approaches. In addition, the VDK was
designed to be scalable. If the application does not use a specific feature,
the support code for that feature is excluded from the target system.
Because the VDK is a library, a developer can decide whether to use it or
not. The VDK is integrated into the VisualDSP++ development environment but can also be used with standard command-line tools. The VDK
development environment assists in managing system resources, automating the generation of various VDK-based objects, and visualizing the
system state during application debug.
Analog Devices emulators use the IEEE 1149.1 JTAG test access port of
the processor to monitor and control the target board processor during
emulation. The emulator provides full speed emulation, allowing inspection and modification of memory, registers, and processor stacks.
Nonintrusive in-circuit emulation is assured by the use of the processor’s
JTAG interface—the emulator does not affect target system loading or
timing.
In addition to the software and hardware development tools available
from Analog Devices, third parties provide a wide range of tools supporting the Blackfin processor family. Hardware tools include the
ADSP-BF59x EZ-KIT Lite standalone evaluation/development cards.
Third party software tools include DSP libraries, real-time operating systems, and block diagram design tools.
This chapter discusses memory population specific to the ADSP-BF59x
processors. Functional memory architecture is described in the Blackfin Processor Programming Reference.
Note that the ADSP-BF59x processors do not have L1 instruction
cache or data cache. For ADSP-BF59x processors, disregard those
portions of the Blackfin Processor Programming Reference that pertain to cache.
Memory Architecture
Figure 2-1 on page 2-2 provides an overview of the ADSP-BF59x proces-
sor system memory map. For a detailed discussion of how to use them, see
the Blackfin Processor Programming Reference.
Note the architecture does not define a separate I/O space. All resources
are mapped through the flat 32-bit address space. The memory is
byte-addressable.
The upper portion of internal memory space is allocated to the core and
system MMRs. Accesses to this area are allowed only when the processor is
in supervisor or emulation mode (see the Operating Modes and States
chapter of the Blackfin Processor Programming Reference).
The processor core reads the instruction memory through the 64-bit wide
instruction fetch bus. All addresses from this bus are 64-bit aligned. Each
instruction fetch can return any combination of 16-, 32-, or 64-bit
instructions (for example, four 16-bit instructions, two 16-bit instructions
and one 32-bit instruction, or one 64-bit instruction).
Table 2-1 lists the memory start locations of the L1 instruction SRAM
subbanks.
Table 2-1. L1 Instruction Memory Subbanks
Memory BbankMemory SubbankMemory Start Location for
Memory BbankMemory SubbankMemory Start Location for
ADSP-BF59x Processors
Instruction Bank A20xFFA0 2000
Instruction Bank A30xFFA0 3000
Instruction Bank B00xFFA0 4000
Instruction Bank B10xFFA0 5000
Instruction Bank B20xFFA0 6000
Instruction Bank B30xFFA0 7000
L1 Instruction ROM
The 64K byte L1 instruction ROM consists of a single 64K byte bank of
read-only memory. The instruction ROM is typically read by the processor to acquire instructions for execution, but contents of instruction ROM
may also be read using the DTEST_COMMAND and DTEST_DATA registers.
Attempts to write ROM using the DTEST_COMMAND and DTEST_DATA registers fail without any errors or exceptions signaled by hardware. DMA
access of instruction ROM is not possible.
L1 Data SRAM
Table 2-2 shows how the subbank organization is mapped into memory.
Table 2-2. L1 Data Memory SRAM Subbank Start Addresses
Table 2-2. L1 Data Memory SRAM Subbank Start Addresses (Continued)
Memory Bank and Subbank ADSP-BF59x Processors
Data Bank A, Subbank 30xFF80 3000
Data Bank A, Subbank 40xFF80 4000
Data Bank A, Subbank 50xFF80 5000
Data Bank A, Subbank 60xFF80 6000
Data Bank A, Subbank 70xFF80 7000
Boot ROM
A 4K byte area of internal memory space is occupied by the boot ROM,
starting from address 0xEF00 0000. This 16-bit boot ROM is not part of
the L1 memory module. Read accesses take one SCLK cycle and no wait
states are required. The read-only memory can be read by the core as well
as by DMA. The boot ROM not only contains boot-strap loader code, it
also provides some subfunctions that are user-callable at runtime. For
more information, see “System Reset and Booting” in Chapter 16, System
Reset and Booting.
External Memory
Aside from the Boot ROM, which sits in External Memory space, there is
no additional external memory address space on the processor.
Processor-Specific MMRs
The complete set of memory-related MMRs is described in the Blackfin
Processor Programming Reference. Several MMRs have bit definitions spe-
cific to the processors described in this manual. These registers are
described in the following sections.
000 - L1 Data SRAM from 0xFF80 0000 to 0xFF80 7FFF
100 - L1 Inst SRAM from 0xFFA0 0000 to 0xFFA0 3FFF
101 - L1 Inst ROM from 0xFFA1 000 to 0xFFA1 FFFF
Note that the ITEST COMMAND register must be used to
access to L1 Inst SRAM from 0xFFA0 4000 to 0xFFA0 7FFF
0 - Read access
1 - Write access
Reserved - Write 1
ADR[10:3]
Address bits [10:3]
ADR[15:14]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
XXXXXXXXX XX XXXXX
0xFFE0 0300
Address bits [15:14]
DTEST_COMMAND Register
When the data test command register (DTEST_COMMAND) is written to, L1
memory is accessed, and the data is transferred through the data test data
registers (DTEST DATA[1:0]). This register is shown in Figure 2-2.
DTEST_COMMAND MMR to L1 instruction SRAM.
Figure 2-2. Data Test Command Register
The data/instruction access bit allows direct access via the
The instruction test command register (ITEST_COMMAND), shown in
Figure 2-3, contains control bits for the L1 data memory.
Figure 2-3. Instruction Test Command Register
This register may be used to gain access to the 16K bytese of L1 instruction SRAM from address 0xFFA04000 to address 0xFFA07FFF. All other
regions of L1 memory—both data and instruction—are accessed using the
This chapter discusses on-chip buses, how data moves through the system,
and other factors that determine the system organization. Following an
overview and a list of key features is a block diagram of the chip bus hierarchy and a description of its operation. The chapter concludes with
details about the system interconnects and associated system buses.
This chapter provides
•“Chip Bus Hierarchy Overview” on page 3-1
•“Interface Overview” on page 3-2
Chip Bus Hierarchy Overview
ADSP-BF59x Blackfin processors feature a powerful chip bus hierarchy on
which all data movement between the processor core, internal memory,
and its rich set of peripherals occurs. The chip bus hierarchy includes the
controllers for system interrupts, test/emulation, and clock and power
management. Synchronous clock domain conversion is provided to support clock domain transactions between the core and the system.
The processor system includes:
•The peripheral set including timers, TWI, UART, SPORTs, SPIs,
PPI, and watchdog timer
The core processor clock (CCLK) rate is highly programmable with respect
to CLKIN. The CCLK rate is divided down from the Phase Locked Loop
(PLL) output rate. This divider ratio is set using the CSEL parameter of the
PLL divide register.
The PAB, the DAB, and the DCB run at system clock frequency (SCLK
domain). This divider ratio is set using the SSEL parameter of the PLL
divide (PLL_DIV) register and must be set so that these buses run as specified in the processor data sheet, and slower than or equal to the core clock
frequency.
These buses can also be cycled at a programmable frequency to reduce
power consumption, or to allow the core processor to run at an optimal
frequency. Note all synchronous peripherals derive their timing from the
SCLK. For example, the UART clock rate is determined by further divid-
ing this clock frequency.
Core Bus Overview
For the purposes of this discussion, level 1 memories (L1) are included in
the description of the core; they have full bandwidth access from the processor core with a 64-bit instruction bus and two 32-bit data buses.
Figure 3-2 shows the core processor and its interfaces to the peripherals
and external memory resources.
The core can generate up to three simultaneous off-core accesses per cycle.
The core bus structure between the processor and L1 memory runs at the
full core frequency and has data paths up to 64 bits.
When the instruction request is filled, the 64-bit read can contain a single
64-bit instruction or any combination of 16-, 32-, or 64-bit (partial)
instructions.
The processor has a dedicated low latency peripheral bus that keeps core
stalls to a minimum and allows for manageable interrupt latencies to
time-critical peripherals. All peripheral resources accessed through the
PAB are mapped into the system MMR space of the processor memory
map. The core accesses system MMR space through the PAB bus.
The core processor has byte addressability, but the programming model is
restricted to only 32-bit (aligned) access to the system MMRs. Byte
accesses to this region are not supported.
PAB Arbitration
The core is the only master on this bus. No arbitration is necessary.
PAB Agents (Masters, Slaves)
The processor core can master bus operations on the PAB. All peripherals
have a peripheral bus slave interface which allows the core to access control and status state. These registers are mapped into the system MMR
space of the memory map. Appendix B lists system MMR addresses.
For the PAB, the primary performance criteria is latency, not throughput.
Transfer latencies for both read and write transfers on the PAB are two
SCLK cycles.
For example, the core can transfer up to 32 bits per access to the PAB
slaves. With the core clock running at 2x the frequency of the system
clock, the first and subsequent system MMR read or write accesses take
four core clocks (CCLK) of latency.
The PAB has a maximum frequency of SCLK.
DMA Access Bus (DAB), DMA Core Bus (DCB)
The DAB and DCB buses provide a means for DMA-capable peripherals
to gain access to on-chip memory with little or no degradation in core
bandwidth to memory.
DAB and DCB Arbitration
Thirteen DMA channels and bus masters support the DMA-capable
peripherals in the processor system. The nine peripheral DMA channel
controllers can transfer data between peripherals and internal memory.
Both the read and write channels of the dual-stream memory DMA controller access their descriptor lists through the DAB.
The DCB has priority over the core processor on arbitration into L1
SRAM. The processor has a programmable priority arbitration policy on
the DAB. Table 3-1 shows the default arbitration priority.
Table 3-1. DAB and DCB Arbitration Priority (Continued)
DAB, DCB MasterDefault Arbitration Priority
SPORT0 transmit2
SPORT1 receive3
SPORT1 transmit4
SPI0 transmit/receive5
SPI1 transmit/receive6
UART0 receive7
UART0 transmit8
Not available on this product9
Not available on this product10
Not available on this product11
Mem DMA has no peripheral mapping.12
Mem DMA has no peripheral mapping.13
Mem DMA has no peripheral mapping.14
Mem DMA has no peripheral mapping.15 - lowest
DAB Bus Agents (Masters)
All peripherals capable of sourcing a DMA access are masters on this bus,
as shown in Table 3-1. A single arbiter supports a programmable priority
arbitration policy for access to the DAB.
When two or more DMA master channels are actively requesting the
DAB, bus utilization is considerably higher due to the DAB’s pipelined
design. Bus arbitration cycles are concurrent with the previous DMA
access’s data cycles.
The processor DAB supports data transfers of 16 bits or 32 bits. The data
bus has a 16-bit width with a maximum frequency as specified in the processor data sheet.
The DAB has a dedicated port into L1 memory. No stalls occur as long as
the core access and the DMA access are not to the same memory bank (4K
byte size for L1). If there is a conflict, DMA is the highest priority
requester, followed by the core.
Note that a locked transfer by the core processor effectively disables arbitration for the addressed memory bank or resource until the memory lock
is deasserted. DMA controllers cannot perform locked transfers.
DMA access to L1 memory can only be stalled by an access already in
progress from another DMA channel. Latencies caused by these stalls are
in addition to any arbitration latencies.
This chapter discusses the system interrupt controller (SIC). While this
chapter does refer to features of the core event controller (CEC), it does
not cover all aspects of it. Please refer to the Blackfin Processor Program-ming Reference for more information on the CEC.
Specific Information for the ADSP-BF59x
For details regarding the number of system interrupts for the
ADSP-BF59x product, please refer to the ADSP-BF592 Blackfin Processor Data Sheet.
To determine how each of the system interrupts is multiplexed with other
functional pins, refer to Table 7-1 on page 7-3 through Table 7-2 on
page 7-4 in Chapter 7, “General-Purpose Ports”.
For a list of MMR addresses for each DMA, refer to Chapter A, “System
MMR Assignments”.
System interrupt behavior for the ADSP-BF59x that differs from the general information in this chapter can be found at the end of this chapter in
the section “Unique Information for the ADSP-BF59x Processor” on
page 4-15.
Overview
The processor system has numerous peripherals, which therefore require
many supporting interrupts.
The Blackfin architecture provides a two-level interrupt processing
scheme:
•The core event controller (CEC) runs in the CCLK clock domain. It
interacts closely with the program sequencer and manages the event
vector table (EVT). The CEC processes not only core-related interrupts such as exceptions, core errors, and emulation events; it also
supports software interrupts.
•The system interrupt controller (SIC) runs in the SCLK clock
domain. It masks, groups, and prioritizes interrupt requests signalled by on-chip or off-chip peripherals and forwards them to the
CEC.
Description of Operation
The following sections describe the operation of the system interrupts.
Events and Sequencing
The processor employs a two-level event control mechanism. The processor SIC works with the CEC to prioritize and control all system
interrupts. The SIC provides mapping between the many peripheral interrupt sources and the prioritized general-purpose interrupt inputs of the
core. This mapping is programmable, and individual interrupt sources can
be masked in the SIC.
The CEC of the processor manages five types of activities or events:
Note the word event describes all five types of activities. The CEC manages fifteen different events in all: emulation, reset, NMI, exception, and
eleven interrupts.
An interrupt is an event that changes the normal processor instruction
flow and is asynchronous to program flow. In contrast, an exception is a
software initiated event whose effects are synchronous to program flow.
The event system is nested and prioritized. Consequently, several service
routines may be active at any time, and a low priority event may be
pre-empted by one of higher priority.
The CEC supports nine general-purpose interrupts (
IVG7 – IVG15) in
addition to the dedicated interrupt and exception events that are described
in Table 4-1. It is common for applications to reserve the lowest or the
two lowest priority interrupts (IVG14 and IVG15) for software interrupts,
leaving eight or seven prioritized interrupt inputs (IVG7 – IVG13) for
peripheral purposes. Refer to Table 4-1.
Table 4-1. System and Core Event Mapping (Continued)
Event SourceCore Event
Name
System interruptsIVG7–IVG13
Software interrupt 1IVG14
Software interrupt 2 (lowest priority)IVG15
System Peripheral Interrupts
To service the rich set of peripherals, the SIC has multiple interrupt
request inputs and outputs that go to the CEC. The primary function of
the SIC is to mask, group, and prioritize interrupt requests and to forward
them to the nine general-purpose interrupt inputs of the CEC (IVG7–
IVG15). Additionally, the SIC controller can enable individual peripheral
interrupts to wake up the processor from Idle or power-down state.
The nine general-purpose interrupt inputs (IVG7–IVG15) of the core event
controller have fixed priority. Of this group, the IVG7 channel has the
highest priority and IVG15 has the lowest priority. Therefore, the interrupt
assignment in the SIC_IAR registers not only groups peripheral interrupts;
it also programs their priority by assigning them to individual IVG channels. However, the relative priority of peripheral interrupts can be set by
mapping the peripheral interrupt to the appropriate general-purpose interrupt level in the core. The mapping is controlled by the
SIC_IAR register
settings shown in Figure 4-2 on page 4-11 and the tables in Chapter A,
“System MMR Assignments”. If more than one interrupt source is
mapped to the same interrupt, they are logically OR’ed, with no hardware
prioritization. Software can prioritize the interrupt processing as required
for a particular system application.
For general-purpose interrupts with multiple peripheral interrupts
assigned to them, take special care to ensure that software correctly
processes all pending interrupts sharing that input. Software is
responsible for prioritizing the shared interrupts.
The core timer has a dedicated input to the CEC controller. Its interrupt
is not routed through the SIC controller and always has higher priority
than requests from all peripherals.
The
SIC_IMASK register allows software to mask any peripheral interrupt
source at the SIC level. This functionality is independent of whether the
particular interrupt is enabled at the peripheral itself. At reset, the contents of the SIC_IMASK register are all 0s to mask off all peripheral
interrupts. Turning off a system interrupt mask and enabling the particular interrupt is performed by writing a 1 to a bit location in the SIC_IMASK
register.
The SIC includes one or more read-only SIC_ISR registers with individual
bits which correspond to the interrupt status of one of the peripheral
interrupt sources. When the SIC detects the interrupt, the bit is asserted.
When the SIC detects that the peripheral interrupt input has been deasserted, the respective bit in the system interrupt status register is cleared.
Note for some peripherals, such as general-purpose I/O asynchronous
input interrupts, many cycles of latency may pass from the time an interrupt service routine initiates the clearing of the interrupt (usually by
writing a system MMR) to the time the SIC senses that the interrupt has
been deasserted.
Depending on how interrupt sources map to the general-purpose interrupt
inputs of the core, the interrupt service routine may have to interrogate
multiple interrupt status bits to determine the source of the interrupt.
One of the first instructions executed in an interrupt service routine
should read the
SIC_ISR register to determine whether more than one of
the peripherals sharing the input has asserted its interrupt output. The service routine should fully process all pending, shared interrupts before
executing the RTI, which enables further interrupt generation on that
interrupt input.
Many systems need relatively few interrupt-enabled peripherals, allowing
each peripheral to map to a unique core priority level. In these designs, the
SIC_ISR register will seldom, if ever, need to be interrogated.
The SIC_ISR register is not affected by the state of the SIC_IMASK register
and can be read at any time. Writes to the SIC_ISR register have no effect
on its contents.
Peripheral DMA channels are mapped in a fixed manner to the peripheral
interrupt IDs. However, the assignment between peripherals and DMA
channels is freely programmable with the DMA_PERIPHERAL_MAP registers.
Table 4-1 on page 4-3 and Table 4-2 on page 4-11 show the default DMA
assignment. Once a peripheral has been assigned to any other DMA channel it uses the new DMA channel’s interrupt ID regardless of whether
DMA is enabled or not. Therefore, clean DMA_PERIPHERAL_MAP management is required even if the DMA is not used. The default setup should be
the best choice for all non-DMA applications.
When an interrupt’s service routine is finished, the RTI instruction
clears the appropriate bit in the IPEND register. However, the relevant SIC_ISR bit is not cleared unless the service routine clears the
mechanism that generated the interrupt.
For dynamic power management, any of the peripherals can be configured
to wake up the core from its idled state to process the interrupt, simply by
enabling the appropriate bit in the
page 4-3 and Table 4-2 on page 4-11). If a peripheral interrupt source is
enabled in SIC_IWR and the core is idled, the interrupt causes the DPMC
to initiate the core wakeup sequence in order to process the interrupt.
Note this mode of operation may add latency to interrupt processing,
depending on the power control state. For further discussion of power
modes and the idled state of the core, see the Dynamic Power Management chapter.
The
SIC_IWR register has no effect unless the core is idled. By default, all
interrupts generate a wakeup request to the core. However, for some
applications it may be desirable to disable this function for some peripherals, such as for a SPORT transmit interrupt. The
read from or written to at any time. To prevent spurious or lost interrupt
activity, this register should be written to only when all peripheral interrupts are disabled.
SIC_IWR register can be
The peripheral interrupt structure of the processor is flexible. Upon reset,
multiple peripheral interrupts share a single, general-purpose interrupt in
the core by default, as shown in Table 4-2 on page 4-11.
An interrupt service routine that supports multiple interrupt sources must
interrogate the appropriate system memory mapped registers (MMRs) to
determine which peripheral generated the interrupt.
The wakeup function is independent of the interrupt mask function. If an interrupt source is enabled in the SIC_IWR but masked
off in the SIC_IMASK register, the core wakes up if it is idled, but it
does not generate an interrupt.
Programming Model
The programming model for the system interrupts is described in the following sections.
System Interrupt Initialization
If the default peripheral-to-IVG assignments shown in Table 4-1 on
page 4-3 and Table 4-2 on page 4-11 are acceptable, then interrupt initial-
ization involves only:
•Initialization of the core event vector table (EVT) vector address
entries
•Unmasking the specific peripheral interrupts that the system
requires in the SIC_IMASK register
System Interrupt Processing Summary
Referring to Figure 4-1 on page 4-9, note when an interrupt (interrupt A)
is generated by an interrupt-enabled peripheral:
1. SIC_ISR logs the request and keeps track of system interrupts that
are asserted but not yet serviced (that is, an interrupt service routine hasn’t yet cleared the interrupt).
2. SIC_IWR checks to see if it should wake up the core from an idled
state based on this interrupt request.
3. SIC_IMASK masks off or enables interrupts from peripherals at the
system level. If interrupt A is not masked, the request proceeds to
Step 4.
4. The SIC_IAR registers, which map the peripheral interrupts to a
smaller set of general-purpose core interrupts (IVG7 – IVG15),
determine the core priority of interrupt A.
ILAT adds interrupt A to its log of interrupts latched by the core
5.
but not yet actively being serviced.
6.
IMASK masks off or enables events of different core priorities. If the
IVGx event corresponding to interrupt A is not masked, the process
proceeds to Step 7.
7. The event vector table (EVT) is accessed to look up the appropriate
vector for interrupt A’s interrupt service routine (ISR).
NOTE: NAMES IN PARENTHESES ARE MEMORY-MAPPED REGISTERS.
EMU
RESET
NMI
EVX
IVTMR
IVHW
PERIPHERAL
INTERRUPT
REQUESTS
CORE
EVENT
VECTOR
TABLE
(EVT[15:0])
CORE
PENDING
(IPEND)
CORE
STATUS
(ILAT)
CORE
INTERRUPT
MASK
(IMASK)
SYSTEM
WAKEUP
(SIC_IWR)
SYSTEM
STATUS
(SIC_ISR)
TO DYNAMIC POWER
MANAGEMENT
CONTROLLER
8. When the event vector for interrupt A has entered the core pipeline, the appropriate
ILAT bit. Thus, IPEND tracks all pending interrupts, as well as those
IPEND bit is set, which clears the respective
being presently serviced.
9. When the interrupt service routine (ISR) for interrupt A has been
executed, the RTI instruction clears the appropriate IPEND bit.
However, the relevant SIC_ISR bit is not cleared unless the interrupt service routine clears the mechanism that generated interrupt
A, or if the process of servicing the interrupt clears this bit.
Figure 4-1. Interrupt Processing Block Diagram
It should be noted that emulation, reset, NMI, and exception events, as
well as hardware error (IVHW) and core timer (IVTMR) interrupt requests,
enter the interrupt processing chain at the ILAT level and are not affected
If multiple interrupt sources share a single core interrupt, then the interrupt service routine (ISR) must identify the peripheral that generated the
interrupt. The ISR may then need to interrogate the peripheral to determine the appropriate action to take.
System Interrupt Controller Registers
The SIC registers are described in the following sections.
These registers can be read from or written to at any time in supervisor
mode. It is advisable, however, to configure them in the reset interrupt
service routine before enabling interrupts. To prevent spurious or lost
interrupt activity, these registers should be written to only when all
peripheral interrupts are disabled.
System Interrupt Assignment (SIC_IAR) Register
The SIC_IAR register maps each peripheral interrupt ID to a corresponding IVG priority level. This is accomplished with 4-bit groupings that
translate to IVG levels as shown in Table 4-2 and Figure 4-2 on
page 4-11. In other words, Table 4-2 defines the value to write in a 4-bit
field within
particular IVG priority. Refer to Table 4-1 on page 4-3 for information
on SIC_IAR mappings for this specific processor.
SIC_IAR in order to configure a peripheral interrupt ID for a
The SIC_IMASK register masks or enables peripheral interrupts at the system level. A "0" in a bit position masks off (disables) interrupts for that
particular peripheral interrupt ID. A "1" enables interrupts for that interrupt ID. Refer to Table 4-1 on page 4-3 and Table 4-2 on page 4-11 for
information on how peripheral interrupt IDs are mapped to the
SIC_IMASK register(s) for this particular processor.
System Interrupt Status (SIC_ISR) Register
The SIC_ISR register keeps track of system interrupts that are asserted but
not yet serviced. A "0" in a bit position indicates that a particular interrupt is deasserted. A "1" indicates that it is asserted. Refer to Table 4-1 on
page 4-3 and Table 4-2 on page 4-11 for information on how peripheral
interrupt IDs are mapped to the SIC_ISR register(s) for this particular
processor.
System Interrupt Wakeup-Enable (SIC_IWR)
Register
The SIC_IWR register allows an interrupt request to wake up the processor
core from an idled state. A "0" in a bit position indicates that a particular
peripheral interrupt ID is not configured to wake the core (upon assertion
of the interrupt request). A "1" indicates that it is configured to do so.
Refer to Table 4-1 on page 4-3 and Table 4-2 on page 4-11 for information on how peripheral interrupt IDs are mapped to the
register(s) for this particular processor.
The following section provides an example for servicing interrupt
requests.
Clearing Interrupt Requests
When the processor services a core event it automatically clears the
requesting bit in the ILAT register and no further action is required by the
interrupt service routine. It is important to understand that the SIC controller does not provide any interrupt acknowledgment feedback
mechanism from the CEC controller back to the peripherals. Although
the ILAT bits clear in the same way when a peripheral interrupt is serviced,
the signalling peripheral does not release its level-sensitive request until it
is explicitly instructed by software. If however, the peripheral keeps
requesting, the respective ILAT bit is set again immediately and the service
routine is invoked again as soon as its first run terminates by an RTI
instruction.
Every software routine that services peripheral interrupts must clear the
signalling interrupt request in the respective peripheral. The individual
peripherals provide customized mechanisms for how to clear interrupt
requests. Receive interrupts, for example, are cleared when received data is
read from the respective buffers. Transmit requests typically clear when
software (or DMA) writes new data into the transmit buffers. These
implicit acknowledge mechanisms avoid the need for cycle-consuming
software handshakes in streaming interfaces. Other peripherals such as
timers, GPIOs, and error requests require explicit acknowledge instructions, which are typically performed by efficient W1C (write-1-to-clear)
operations.
Listing 4-1 shows a representative example of how a GPIO interrupt
#include <defBF527.h>
/*ADSP-BF527 product is used as an example*/
.section program;
_portg_a_isr:
/* push used registers */
[--sp] = (r7:7, p5:5);
/* clear interrupt request on GPIO pin PG2 */
/* no matter whether used A or B channel */
p5.l = lo(PORTGIO_CLEAR);
p5.h = hi(PORTGIO_CLEAR);
r7 = PG2;
w[p5] = r7;
/* place user code here */
/* sync system, pop registers and exit */
ssync;
(r7:7, p5:5) = [sp++];
rti;
_portg_a_isr.end:
The W1C instruction shown in this example may require several SCLK
cycles to complete, depending on system load and instruction history. The
program sequencer does not wait until the instruction completes and continues program execution immediately. The
SSYNC instruction ensures that
the W1C command indeed cleared the request in the GPIO peripheral
before the RTI instruction executes. However, the
SSYNC instruction does
not guarantee that the release of interrupt request has also been recognized
by the CEC controller, which may require a few more
ing on the
instructions only, two
CCLK-to-SCLK ratio. In service routines consisting of a few
SSYNC instructions are recommended between the
CCLK cycles depend-
clear command and the RTI instruction. However, one SSYNC instruction
is typically sufficient if the clear command performs in the very beginning
of the service routine, or the
of instructions before the service routine returns. Commonly, a pop-multiple instruction is used for this purpose as shown in Listing 4-1.
The level-sensitive nature of peripheral interrupts enables more than one
of them to share the same IVG channel and therefore the same interrupt
priority. This is programmable using the assignment registers. Then a
common service routine typically interrogates the SIC_ISR register to
determine the signalling interrupt source. If multiple peripherals are
requesting interrupts at the same time, it is up to the service routine to
either service all requests in a single pass or to service them one by one. If
only one request is serviced and the respective request is cleared by software before the RTI instruction executes, the same service routine is
invoked another time because the second request is still pending. While
the first approach may require fewer cycles to service both requests, the
second approach enables higher priority requests to be serviced more
quickly in a non-nested interrupt system setup.
SSYNC instruction is followed by another set
Unique Information for the ADSP-BF59x
Processor
This section describes Interfaces and System Peripheral Interrupts that are
unique to the ADSP-BF59x processor.
Interfaces
Figure 4-3 provides an overview of how the individual peripheral inter-
rupt request lines connect to the SIC. It also shows how the eight
registers control the assignment to the nine available peripheral request
inputs of the CEC.
Table 4-3 shows the peripheral interrupt events, the default mapping of
each event, the peripheral interrupt ID used in the system interrupt
assignment registers (SIC_IAR), and the core interrupt ID.
Note that the system interrupt to core event mappings shown are the
default values at reset and can be changed by software.
The peripheral interrupt structure of the processor is flexible. Upon reset,
multiple peripheral interrupts share a single, general-purpose interrupt in
the core by default, as shown in Table 4-3.
An interrupt service routine that supports multiple interrupt sources must
interrogate the appropriate system memory mapped registers (MMRs) to
determine which peripheral generated the interrupt.