Programmable Real-Time Unit (Pru) : Extending Functionality of Existing Socs
Programmable Real-Time Unit (Pru) : Extending Functionality of Existing Socs
Programmable Real-Time Unit (Pru) : Extending Functionality of Existing Socs
Gustavo Martinez,
Applications Engineer
Gagan Maur,
Applications Engineer
Texas Instruments
Programmable Real-Time Unit (PRU):
Extending Functionality of
Existing SoCs
Abstract
Today, developers utilizing embedded pro- As the complexity of applications implemented on SoC devices continues to increase, higher
cessors in their applications require more performance and many different connectivity options are required. TI continues to extend the
flexibility from their System-on-Chip (SoC) capabilities of its SoCs by providing more connectivity options with every new generation.
solutions. Often, missing features like ad- Table 1 on the following page highlights the addition in connectivity options going from the
ditional peripherals or custom interfaces are TMS320C672x DSP generation of floating-point DSPs to the TMS320C674x DSP generation.
implemented using FPGAs, ASICs, or soft- Even with these many connectivity options, the continuing innovation of developers and
ware resources, but these approaches can diversity of applications invariably results in these devices lacking some elements needed by
be costly as they take up valuable board the application. The missing attributes can be additional peripherals, system control inter-
space or consume processing bandwidth faces, or special interfaces.
of the main processor. The programmable It is often not possible to find a SoC that meets all requirements of an application and
real-time unit (PRU) subsystem gives sys- trade-offs must be made. Application developers carefully consider different factors when
tem engineers the ability to implement a choosing the right processor for their application. These include cost, performance, power
variety of soft peripherals which are peri- consumption, peripheral features (e.g., Ethernet controller, USB, keypad controller, etc.) and
pherals implemented using a combination software support.
of on-chip hardware and software. The dual Often, application developers find that a particular SoC meets their performance, power,
reduced instruction set (RISC) cores of the and cost goals but does not meet all of their peripheral needs. Application developers have
PRU allow system engineers to implement few options when addressing this issue: implement the missing peripherals using an FPGA
additional or custom peripherals without or an ASIC, or use a combination of on-chip processor hardware and software to emulate the
taking up valuable time from the main pro- missing peripheral.
cessor. A small, deterministic instruction
set, specialized bit-manipulation instruc-
Feature SoC
tions, dedicated, fast input/output pins, and requirements features
access to all resources on the SoC are all
key features of the PRU when it comes to Smart Ethernet Serial ATA
peripheral connectivity,
the creation of soft peripherals. The PRU DDR
interface, Audio serial
is available on the following Texas Instru- 9-bit UART port
NOR Flash
ments (TI) SoC platforms: TMS320C674x Additional interface, LCD
SPI port UART ports, controller
digital signal processor (DSP) generation, SPI port
CAN
OMAP-L1x processor generation and AM1x
Sitara ARM microprocessors (MPUs). Figure 1. Application requirements vs. SoC features.
2 Texas Instruments
Using an FPGA or ASIC has several drawbacks. Both can be costly and require additional development
resources. Also, this approach requires additional board space which can be a problem for some size-con-
strained applications. Using discrete logic, for example a standalone Controller Area Network (CAN) controller,
increases the bill of materials cost and also requires resources to develop software drivers.
When implementing a peripheral through software, the application developer must consider the impact on
the performance of the main processor. If the main processor is heavily utilized, it may be necessary to lower
the performance of the implemented peripheral. In some cases, the real-time response requirements of the
peripheral are too demanding for the main processor to adequately handle without affecting other functionality.
Soft peripheral The PRU subsystem on the OMAP-L1x processors, C674x DSPs, and AM1x Sitara ARM MPUs allows the
approach with application developer to implement soft peripherals; peripherals implemented using a combination of on-chip
the PRU
hardware and software. Unlike soft peripherals implemented using the main processor, PRU soft peripherals
Programmable Real-Time Unit (PRU): Extending Functionality of Existing SoCs April 2011
Texas Instruments 3
do not take any processing time from the main processor. PRU soft peripherals can also be customized to
meet specific application requirements and they can be replaced on-the-fly with other soft peripherals.
The PRU subsystem is a programmable module which can be used for soft peripheral implementation,
specialized data handling, direct-memory access (DMA) operations, and for offloading tasks from the main
processor. The PRU subsystem consists of two 32-bit RISC cores (referred to as programmable real-time
units, or PRUs), local data and instruction memories, an interrupt controller for capturing and manipulating
system-wide events, and input/output pins. The PRU instruction set is simple and execution times
are deterministic.
A specialized DMA engine is an example of a soft peripheral that can be fully implemented by the PRU.
In other cases the PRU can leverage other SoC peripherals for tasks such as clock synchronization, external
input/output pins, and data computation to implement soft peripherals. Regardless of how it is implemented,
a soft peripheral is a programmable solution that is both flexible and customizable.
Table 2 lists some key features of the PRU subsystem when it comes to implementing soft peripherals.
Feature Benefit
Small, deterministic instruction set with multiple bit-manipulation Easy to use; fast learning curve
instructions
Dedicated, fast input/output pins Input/output interface implementation; detect and react to I/O
event within two PRU cycles
Interrupt controller for monitoring and generating system events Communication with higher level software; detection of peripheral
events (e.g., transmit ready, timer interrupts, etc.)
Access all SoC resources (peripherals, memory, etc.) Direct access to buffer data; leverage system peripherals for
implementation of soft peripherals or other specialized tasks
Constants table containing many of the most commonly-used based Maximizes usage of the PRU register file and instruction memory
addresses for SoC peripherals and memory
Each PRU has dedicated instruction and data memory and can operate Use each PRU for a different task; use PRUs in tandem for more
independently or in coordination with the ARM, DSP, or the other PRU advanced tasks
32 GPO
PRU0 core DRAM0
30 GPI (512 Bytes)
32-bit interconnect SCR
4KB IRAM
32 GPO DRAM1
PRU1 core (512 Bytes)
30 GPI
4KB IRAM
Master I/F
Interrupts to (to SCR2)
ARM/DSP INTC Interrupt
controller Slave I/F
Events from (INTC)
Periph + PRUs (from SCR2)
Programmable Real-Time Unit (PRU): Extending Functionality of Existing SoCs April 2011
4 Texas Instruments
Fast, real-time While generic general-purpose input/output (GPIO) pins can be used to implement some functions, GPIO sup-
response ported by the SoC can be inadequate when a fast response time is required since often these pins cannot be
toggled or sampled at a very fast rate. The PRU includes dedicated, fast input/output pins which can be read
or toggled within a single cycle.
A soft CAN module is an example of where fast real-time response and fast input/output pins are required.
To adjust for frequency variations between CAN nodes, each receiving node must constantly adjust its
bit-sampling point. To meet this requirement, the CAN node must oversample its input pin at rates up to
25. The real-time response requirement is determined by the baud rate and the oversampling setting. For
example, when operating at a 150-kbit/sec rate with a 16 oversample clock, the CAN node has 416 sec
to process each bit. A 300-MHz DSP would have to process each bit every 126 cycles, which is possible but
extremely difficult to implement, but offloading such a task to the PRU would free up the DSP for more critical
tasks. Figure 3 shows a block diagram of a soft CAN implementation using the PRU. Note this implementation
is compatible, but not fully compliant, with the BOSCH CAN Specification 2.0B.
ARM/DSP
Interrupts
Soft CAN
PRU RAM
Fast I/O
CAN_RXD
MBX0 PRU0
CANH
Isolated
MBX1
CAN CANL
transceiver
Fast I/O
CAN_TXD
MBX8 PRU1
PRUSS
Leveraging other The PRU has access to all SoC resources including hardware peripherals, system memory, external memory,
SoC resources and input/output pins. This allows the PRU subsystem to leverage other system resources to implement soft
peripherals. For example, a soft universal asynchronous receiver/transmitter (UART) can be implemented
using a serial port for data transmit and data receive using an 8 or 16 clock for oversampling. When data
is being received, the PRU could remove framing bits (start, stop, etc.), extract the actual data and transfer
the final result to SoC memory. For the transmit case, the PRU subsystem can move data from SoC memory,
add framing bits (start, stop, etc.) and directly access the serial port for transmission. Also, since the PRU is
programmable, custom features such as support for 9-bit characters and special baud rates can be added
to the soft UART. Figure 4 on the following page shows a block diagram of a soft UART implementation using
the PRU.
Programmable Real-Time Unit (PRU): Extending Functionality of Existing SoCs April 2011
Texas Instruments 5
ARM /DSP Configure
ARINT
Transmit buffer
TX_DATA [31:0] sUART_TXD
Serializer
PRU
RX_DATA [31:0] sUART_RXD
Receive buffer Serializer
PRUSS
Conclusion The PRU subsystem can be used to extend the functionality of existing SoCs by giving the system engineer
the capability to implement soft peripherals. Soft peripherals can vary from additional UARTs or SPI ports to
customized timers or DMA engines. Unlike traditional software peripherals, the PRU does not take processing
time away from the main processor(s) since it can operate independently. Furthermore, the reduced instruc-
tion set and deterministic operation of the PRU makes it easy to understand, allowing customers to quickly
start developing their own peripherals.
For additional information, please visit www.ti.com/sprc940-pru.
Important Notice: The products and services of Texas Instruments Incorporated and its subsidiaries described herein are sold subject to TIs standard terms and
conditions of sale. Customers are advised to obtain the most current and complete information about TI products and services before placing orders. TI assumes no liability
for applications assistance, customers applications or product designs, software performance, or infringement of patents. The publication of information regarding any
other companys products or services does not constitute TIs approval, warranty or endorsement thereof.
Sitara is a trademark of Texas Instruments Incorporated. All other trademarks are the property of their respective owners.
Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265
Copyright 2011, Texas Instruments Incorporated