01.08.2013 Views

Chapter 08 Power, Reset, and Clock Management (PRCM).pdf

Chapter 08 Power, Reset, and Clock Management (PRCM).pdf

Chapter 08 Power, Reset, and Clock Management (PRCM).pdf

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

www.ti.com <strong>Power</strong>, <strong>Reset</strong>, <strong>and</strong> <strong>Clock</strong> <strong>Management</strong><br />

Each reset source is specified as being a cold or warm type. Cold types are synonymous with power-onreset<br />

(POR) types. Such sources are applied globally within each receiving entity (i.e., sub-system,<br />

module, macro-cell) upon assertion. Cold reset events include: device power-up, power-domain power-up,<br />

<strong>and</strong> eFuse programming failures.<br />

Warm reset types are not necessarily applied globally within each receiving entity. A module may use a<br />

warm reset to reset a subset of its logic. This is often done to speed-up reset recovery time, i.e., the time<br />

to transition to a safe operating state, compared to the time required upon receipt of a cold reset. Warm<br />

reset events include: software initiated per power-domain, watch-dog time-out, externally triggered, <strong>and</strong><br />

emulation initiated.<br />

<strong>Reset</strong> sources, warm or cold types, intended for device-wide effect are classified as global sources. <strong>Reset</strong><br />

sources intended for regional effect are classified as local sources.<br />

Each <strong>Reset</strong> Manager provides two reset outputs. One is a cold reset generated from the group of global<br />

<strong>and</strong> local cold reset sources it receives. The other is a warm+cold reset generated from the combined<br />

groups of, global <strong>and</strong> local, cold <strong>and</strong> warm reset sources it receives.<br />

The <strong>Reset</strong> Manager asserts one, or both, of its reset outputs asynchronously upon reset source assertion.<br />

<strong>Reset</strong> deassertion is extended beyond the time the source gets de-asserted. The reset manager will then<br />

extend the active period of the reset outputs beyond the release of the reset source, according to the<br />

<strong>PRCM</strong>’s internal constraints <strong>and</strong> device’s constraints. Some reset durations can be software-configured.<br />

Most (but not all) reset sources are logged by <strong>PRCM</strong>’s reset status registers. The same reset output can<br />

generally be activated by several reset sources <strong>and</strong> the same reset source can generally activate several<br />

reset outputs. All the reset signals output of the <strong>PRCM</strong> are active low. Several conventions are used in<br />

this document for signal <strong>and</strong> port names. They include:<br />

• "_RST" in a signal or port name is used to denote reset signal.<br />

• "_PWRON_RST" in a signal or port name is used to denote a cold reset source<br />

8.1.7.3 Global <strong>Power</strong> On <strong>Reset</strong> (Cold <strong>Reset</strong>)<br />

There are several cold reset sources. See Table 8-23 for a summary of the different reset sources.<br />

8.1.7.3.1 <strong>Power</strong> On <strong>Reset</strong> (PORz)<br />

The source of power on reset is PORz signal on the device. Everything on device is reset with assertion of<br />

power on reset. This reset is non-blockable. PORz can be driven by external power management devices<br />

or power supervisor circuitry. During power-up, when power supplies to the device are ramping up, PORz<br />

needs to be driven Low. When the ramp-up is complete <strong>and</strong> supplies reach their steady-state values,<br />

PORz need to be driven High. During normal operation when any of the device power supplies are turned<br />

OFF, PORz must be driven Low.<br />

8.1.7.3.2 PORz Sequence<br />

• PORz pin at chip boundary gets asserted (goes low). Note: state of nRESETIN_OUT during PORz<br />

assertion should be a don’t care, it should not affect PORz (only implication is if they are both asserted<br />

<strong>and</strong> nRESETIN_OUT is deasserted after PORz you will get re-latching of boot config pins <strong>and</strong> may see<br />

warm nRESETIN_OUT flag set in <strong>PRCM</strong> versus POR).<br />

• All IOs will go to tri-state immediately.<br />

• When power comes-up, PORz value will propagate to the <strong>PRCM</strong>.<br />

• <strong>PRCM</strong> will fan out reset to the complete chip <strong>and</strong> all logic which uses async reset will get reset.<br />

nRESETIN_OUT will go low to indicate reset-in-progress.<br />

• External clocks will start toggling <strong>and</strong> <strong>PRCM</strong> will propagate these clocks to the chip keeping PLLs in<br />

bypass mode.<br />

• All logic using sync reset will get reset.<br />

• When power <strong>and</strong> clocks to the chip are stable, PORz must be de-asserted.<br />

• Boot configuration pins are latched upon de-assertion of PORz pin<br />

• IO cell controls from IPs for all the IOs with a few exceptions (see datasheet for details) are driven by<br />

GPIO module. GPIO puts all IOs in input mode.<br />

SPRUH73E–October 2011–Revised May 2012 <strong>Power</strong>, <strong>Reset</strong>, <strong>and</strong> <strong>Clock</strong> <strong>Management</strong> (<strong>PRCM</strong>)<br />

Submit Documentation Feedback<br />

Copyright © 2011–2012, Texas Instruments Incorporated<br />

665

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!