Lecture 3 Power, Reset, and Clock Management NCHUEE 720A Lab Prof. Jichiang Tsai Device Power-Management Architecture Ensures maximum performance and operation time for user satisfaction Offers versatile power-management techniques for maximum design flexibility Built with three levels of resource management Clock, power, and voltage management Enforced by defining the clock, power, and voltage domains A group of modules or subsections share a common entity, e.g., common clock source, common voltage source, or common power switch The group is managed by a policy manager, e.g., a clock for a clock domain is managed by a dedicated clock manager within the power, reset, and clock management (PRCM) module The clock manager considers the joint clocking constraints of all the modules receiving that clock NCHUEE 720A Lab Prof. Jichiang Tsai PRCM Module Overview Supports an enhanced power management scheme based on four functional power domains WAKEUP, MPU, PER, and RTC Features: Software configurable for direct, automatic, or a combination thereof, functional power domain state transition control Device power-up sequence control Device sleep/wake-up sequence control Centralized reset generation and management Centralized clock generation and management NCHUEE 720A Lab Prof. Jichiang Tsai Clock Management The PRCM module along with the control module manages the gating and enabling of the clocks of modules The clocks are managed based on the requirement constraints of the associated modules Each module has specific clock input characteristic requirements Based on the characteristics, the clocks are divided into Interface clocks and functional clocks NCHUEE 720A Lab Prof. Jichiang Tsai Clock Management (cont.) The interface clocks have the characteristics Ensure proper communication between any module/subsystem and interconnect In most cases, supply the system interconnect interface and registers of the module A typical module has one interface clock Modules with multiple interface clocks may also exist When connected to multiple interconnect buses Interface clock management is done at the device level An interface clock is identified by an _ICLK suffix Functional clocks have the characteristics Supply the functional part of a module or subsystem NCHUEE 720A Lab Prof. Jichiang Tsai Clock Management (cont.) A module can have one or more functional clocks Some functional clocks are mandatory, Others are optional A module needs its mandatory clock(s) to be operational. The optional clocks are used for specific features A functional clock is distributed directly to the related modules through a dedicated clock tree Can be shut down without stopping the module activity Identified with an _FCLK suffix Each module may also have specific clock requirements Certain module clocks must be active when operating in specific modes, or may be gated otherwise The activation and gating of clocks are managed by the PRCM module NCHUEE 720A Lab Prof. Jichiang Tsai Clock Management (cont.) The PRCM module must be aware of when to activate and when to gate the module clocks The PRCM module differentiates the clock-management behavior based on Whether the module can initiate transactions on the device interconnect (master module or initiators) Or cannot initiate transactions and only responds to the transactions initiated by the master (slave module or targets) Two hardware-based power-management protocols are used Master standby protocol: Clock-management protocol between the PRCM and master modules A master module must initiate a transaction on the device interconnect and requests specific (functional and interface) clocks for the purpose NCHUEE 720A Lab Prof. Jichiang Tsai Clock Management (cont.) The PRCM module ensures that the required clocks are active when the master module requests the PRCM module to enable them Called a module wake-up transition The module is said to be functional after this transition completes When the master module no longer requires the clocks, it informs the PRCM module, which can then gate the clocks to the module The master module is then said to be in standby mode Slave idle protocol: Clock-management protocol between the PRCM and slave modules Allows the PRCM module to control the state of a slave module The PRCM module informs the slave module, through assertion of an idle request, when its clocks (interface and functional) can be gated. The slave can then acknowledge the request from the PRCM module The PRCM module is then allowed to gate the clocks to the module A slave module is said to be in IDLE state when its clocks are gated by the PRCM module NCHUEE 720A Lab Prof. Jichiang Tsai Clock Management (cont.) Both protocols are completely hardware-controlled An idled slave module may need to be wakened because of a service request from a master module or as a result of an event received by the slave module (called a wake-up event; e.g., interrupt or DMA request) The PRCM module enables the clocks to the module and then deasserts the idle request to signal the module to wake up But software must configure the clock-management behavior for the master or slave modules PRCM offers also the possibility to manage optional clocks, through a direct SW control NCHUEE 720A Lab Prof. Jichiang Tsai Clock Domain A group of modules fed by clock signals controlled by the same clock manager in the PRCM module By gating the clocks in a clock domain, the clocks to all the modules of that domain can be cut To lower their active power consumption The device is on and the clocks to the modules are dynamically switched to ACTIVE or INACTIVE (GATED) states A clock domain allows control of the dynamic power consumption The device is partitioned into multiple clock domains Each clock domain is controlled by an associated clock manager within the PRCM module Allows the PRCM module to individually activate and gate each clock domain of the device NCHUEE 720A Lab Prof. Jichiang Tsai Clock Domain (cont.) Two clock managers: CM_a and CM_b The clock domain of CM_b is composed of two clocks A functional clock (FCLK2) and an interface clock (ICLK1) The clock domain of CM_a consists of a clock (CLK1) Used by the module as a functional and interface clock NCHUEE 720A Lab Prof. Jichiang Tsai Clock Domain (cont.) The clocks to Module 2 can be gated independently of the clock to Module 1 Ensuring power savings when Module 2 is not in use The PRCM module lets software check the status of the clock domain functional clocks: Active or Gated The CM_<Clock domain>_CLKSTCTRL[x] CLKACTIVITY_<FCLK/Clock name_FCLK> bit in the PRCM module identifies the state of the functional clock(s) within the clock domain NCHUEE 720A Lab Prof. Jichiang Tsai Clock Domain (cont.) The domain clock manager can automatically and jointly manage the interface clocks within the clock domain The former is based on hardware conditions The functional clocks within the clock domain are managed through software settings A clock domain can switch between three possible states NCHUEE 720A Lab Prof. Jichiang Tsai Clock Domain (cont.) ACTIVE IDLE_TRANSITION Every nondisabled slave module is put out of IDLE state All interface clocks to the nondisabled slave modules are provided All functional and interface clocks to the active master are provided All enabled optional clocks to the modules are provided This is a transitory state Every master module is in STANDBY state Every idle request to all the slave modules is asserted The functional clocks to the slave module in enabled remain active All enabled optional clocks to the modules are provided INACTIVE All clocks within the clock domain are gated NCHUEE 720A Lab Prof. Jichiang Tsai Clock Domain (cont.) Every slave module is in IDLE state and set to disabled Every optional functional clock is gated Each clock domain transition behavior is managed by an associated register bit field in the CM_<Clock domain>_CLKSTCTRL[x] CLKTRCTRL PRCM module NCHUEE 720A Lab Prof. Jichiang Tsai Power Management The PRCM module manages the switching on and off of the power supply to the device modules To minimize device power consumption, the power to the modules can be switched off when they are not in use Independent power control of sections allows PRCM to turn on and off specific sections without affecting the others A power domain is a section device with an independent and dedicated power manager To minimize power consumption, the modules are grouped A power domain can be split into a logic area and a memory area The power manager is assigned the task of managing the domain power transitions It ensures that all hardware conditions are satisfied before it can initiate a power domain transition from a source to a target power state NCHUEE 720A Lab Prof. Jichiang Tsai Power Management (cont.) NCHUEE 720A Lab Prof. Jichiang Tsai Power Management (cont.) NCHUEE 720A Lab Prof. Jichiang Tsai Power Modes In order of the lowest power to the highest power RTC-Only, DeepSleep0, DeepSleep1, DeepSleep2, Standby and Active All voltage supplies must be maintained for the each of the Deep Sleep, Standby and Active modes The contents of SDRAM are preserved in any of the Deep Sleep/Standby modes By placing SDRAM in self-refresh prior to entering Deep Sleep Active The supply to all voltage rails must be maintained All power domains come up in ON state The device is fully functional NCHUEE 720A Lab Prof. Jichiang Tsai Power Modes (cont.) NCHUEE 720A Lab Prof. Jichiang Tsai Power Modes (cont.) NCHUEE 720A Lab Prof. Jichiang Tsai Power Modes (cont.) Standby The supply to all voltage rails must be maintained The power consumption can be minimized if the supply voltage placed at its minimum operating voltage Using Software, the required PLL’s are made active depending upon wakeup or use case requirements The rest are placed in low power bypass modes All non-essential IP blocks are powered down SDRAM contents are preserved This is useful for quick standby/resume kind of application DeepSleep0 The supply to all voltage rails are maintained Only the PD_RTC and PD_WKUP power domains are ON NCHUEE 720A Lab Prof. Jichiang Tsai Power Modes (cont.) The master crystal oscillator is disabled The contents of OCMC RAM are preserved The contents of the SDRAM are preserved by placing the SDRAM in self-refresh Activity on wake up peripherals via wake up events enables the master crystal oscillator using the oscillator control circuit Deepsleep1 The supply to all voltage rails are maintained The PD_RTC, PD_WKUP & PD_PER power domains are ON The PD_GFX power domain is OFF But could be optionally ON at the cost of more power The master crystal oscillator is disabled The contents of internal SRAM are preserved NCHUEE 720A Lab Prof. Jichiang Tsai Power Modes (cont.) The contents of the SDRAM are preserved by placing the SDRAM in self-refresh Activity on wake up peripherals via wake up events enables the master crystal oscillator using the oscillator control circuit Deepsleep2 The supply to all voltage rails are maintained All power domains are ON The PD_GFX power domain is OFF The master crystal oscillator is disabled The contents of internal SRAM are preserved The contents of the SDRAM are preserved by placing the SDRAM in self-refresh NCHUEE 720A Lab Prof. Jichiang Tsai Power Modes (cont.) Activity on wake up peripherals via wake events enables the master crystal oscillator using the oscillator control circuit RTC-Only Only the supplies to the RTC subsystem are supplied Only the RTC power supply is expected to be ON All the remaining supplies are expected to be OFF. For SDRAM to be in self-refresh during this mode, the CKE pin of the DDR interface needs to have a pulldown on the board Wakeup Sources/Events Events will wake up the device from Deep sleep modes These are part of the Wakeup Power domain and remain always ON GPIO0 bank NCHUEE 720A Lab Prof. Jichiang Tsai Power Modes (cont.) dmtimer1_1ms (timer based wakeup) USB2PHY (USB resume signaling from suspend) TSC (Touch screen controller), ADC monitor functions UART0 (Infra-red support), I2C0 Both USB ports supported These events apply on any of the deep sleep and standby modes Wakeup Sequencing The wake up event will switch on the oscillator If it was configured to go OFF during sleep Cortex A8 MPU starts executing from ROM reset vector Restore the application context Only for Deep sleep 0 NCHUEE 720A Lab Prof. Jichiang Tsai Reset Management The PRCM manages the resets to all power domains and generation of a single reset output signal The PRCM has no knowledge of or control over resets generated locally within a module All PRM reset outputs are asynchronously asserted e.g., via the OCP configuration register bit IPName_SYSCONFIG.SoftReset These outputs are active-low except for the PLL resets Through device pin, PWRONRSTn, for external use Deassertion is synchronous to a clock The clock runs a counter used to stall, or delay, reset deassertion upon source deactivation This clock will be CLK_M_OSC used by all the reset managers NCHUEE 720A Lab Prof. Jichiang Tsai Reset Management (cont.) All modules receiving a PRCM generated reset are expected to treat the reset as asynchronous One or more Reset Managers are required per power domain Implement local re-synchronization upon de-activation as needed Independent management of multiple reset domains is required to meet the reset sequencing requirements of all modules The PRCM collects many sources of reset Cold reset: it affects all the logic in a given entity Warm reset: it is a partial reset It does not affect all the logic in a given entity Global reset: it affects the entire device Local reset: it affects part of the device e.g., One power domain NCHUEE 720A Lab Prof. Jichiang Tsai Reset Management (cont.) S/W reset: it is initiated by software H/W reset: it is hardware driven Each reset source is specified as being a cold or warm type Cold types are applied globally within each receiving entity i.e., sub-system, module, macro-cell Synonymous with power-on-reset (POR) types Cold reset events include: device power-up, power-domain power-up, and eFuse programming failures Warm types are not necessarily applied globally within each entity A module may use a warm reset to reset a subset of its logic To speed-up reset recovery time, i.e., the time to transition to a safe operating state, compared to the time required by a cold reset Warm reset events include: software initiated per power-domain, watchdog time-out, externally triggered, and emulation initiated NCHUEE 720A Lab Prof. Jichiang Tsai Reset Management (cont.) 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 A cold reset generated from the group of global and local cold reset sources it receives 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 deasserted NCHUEE 720A Lab Prof. Jichiang Tsai Reset Management (cont.) The reset manager will 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 The same reset source can generally activate several reset outputs All the reset signals output of the PRCM are active low NCHUEE 720A Lab Prof. Jichiang Tsai Global Power On Reset (Cold Reset) Power On Reset (PORz) The source of power on reset is PORz signal on the device This reset is non-blockable PORz can be driven by external power management devices or power supervisor circuitry Bad Device Reset Everything on device is reset with assertion of power on reset Asserted whenever an unsupported device type is encoded Global Cold Software Reset (GLOBAL_COLD_SW_RST) Generated internally by the PRM Upon setting the RM_RSTCTRL.RST_GLOBAL_COLD_SW bit in the PRM memory map NCHUEE 720A Lab Prof. Jichiang Tsai Global Warm Reset External Warm Reset nRESETIN_OUT is a bidirectional warm reset signal As an input, it is typically used by an external source as a device reset As an output, nRESETIN_OUT can be used to reset external devices Drive low during a cold reset or an internally generated warm reset After completion, nRESETIN_OUT will continue to drive low for a period defined by PRM_RSTTIME.RSTTIME1 RSTTIME1 is a timer that counts down to zero at a rate equal to the high frequency system input clock CLK_M_OSC This allows external devices to be held in reset for some time after the AM335x comes out of reset The device and its related peripherals are reset together nRESETIN_OUT also reflects chip reset status Watchdog Timer and Global Warm Software Reset NCHUEE 720A Lab Prof. Jichiang Tsai Reset Priority POR TRSTz (Trace Functionality Test Reset ) External warm reset Emulation Reset requestors Triggered from TRSTz pin on JTAG interface. A non-blockable reset and resets test and emulation logic The reset from the watchdog timer is not blockable Software resets NCHUEE 720A Lab Prof. Jichiang Tsai Power-Up/Down Sequence Each power domain has dedicated warm and cold reset Warm reset gets asserted each time there is any warm reset source requesting reset Warm reset is also asserted when power domain moves from ON to OFF state Cold reset for the domain is asserted in response to cold reset sources When domain moves from OFF to ON state, cold reset also gets asserted This is similar to power-up condition for that domain NCHUEE 720A Lab Prof. Jichiang Tsai