Table of Contents
Advertisement
Reset Management
14.5 Reset Management
14.5.1 Overview
The PRCM manages the resets to all power domains inside device. And, it manages generation of a
single reset output signal through device pin, SYS_RESWARM_RST, for external use. The PRCM has
no knowledge of or control over resets generated locally within a module, e.g., via the OCP
configuration register bit IPName_SYSCONFIG.SoftReset.
All PRM reset outputs are asynchronously asserted. These outputs are active-low except for the DPLL
resets. Deassertion is synchronous to the clock which runs a counter used to stall, or delay, reset
de-assertion upon source deactivation. This clock will be SYS_CLK used by all the reset managers. All
modules receiving a PRCM generated reset are expected to treat the reset as asynchronous and
implement local re-synchronization upon de-activation as needed.
One or more Reset Managers are required per power domain. Independent management of multiple
reset domains is required to meet the reset sequencing requirements of all modules in the power
domain.
14.5.2 Reset Concepts and Definitions
The PRCM collects many sources of reset. Here below is a list of qualifiers of the source of reset:
•
Cold reset: it affects all the logic in a given entity
•
Warm reset: it is a partial reset which doesn't affect all the logic in a given entity
•
Global reset: it affects the entire device
•
Local reset: it affects part of the device (1 power domain for example)
•
Software reset: it is initiated by software
•
Hardware reset: it is hardware driven
Each reset source is specified as being a cold or warm type. Cold types are synonymous with
power-on-reset (POR) types. Such sources are applied globally within each receiving entity (i.e.,
sub-system, module, macro-cell) upon assertion. Cold reset events include: device power-up,
power-domain power-up, and E-Fuse programming failures.
Warm reset types are not necessarily applied globally within each receiving entity. A module may use a
warm reset to reset a subset of its logic. This is often done to speed-up reset recovery time, i.e., the
time to transition to a safe operating state, compared to the time required upon receipt of a cold reset.
Warm reset events include: software initiated per power-domain, watch-dog time-out, security violation,
externally triggered, and emulation initiated.
Reset sources, warm or cold types, intended for device-wide effect are classified as global sources.
Reset sources intended for regional effect are classified as local sources.
Each Reset Manager provides two reset outputs. One is a cold reset generated from the group of
global and local cold reset sources it receives. The other is a warm+cold reset generated from the
combined groups of, global and local, cold and warm reset sources it receives.
The Reset Manager asserts one, or both, of its reset outputs asynchronously upon reset source
assertion. Reset deassertion is extended beyond the time the source gets de-asserted. The reset
manager will then extend the active period of the reset outputs beyond the release of the reset source,
according to the PRCM's internal constraints and device's constraints. Some reset durations can be
software-configured. Most (but not all) reset sources are logged by PRCM's reset status registers. The
same reset output can generally be activated by several reset sources and the same reset source can
generally activate several reset outputs. All the reset signals output of the PRCM are active low.
Several conventions are used in this document for signal and port names. They include:
•
"_RST" in a signal or port name is used to denote reset signal.
•
"_PWRN_RST" in a signal or port name is used to denote a cold reset source
1416
Power, Reset, and Clock Management (PRCM) Module
Preliminary
© 2011, Texas Instruments Incorporated
www.ti.com
SPRUGX9 – 15 April 2011
Submit Documentation Feedback
Advertisement
Table of Contents
