UPF fundamentals--Defining Power Domains

文章来源：

　　http://www.docin.com/p-1084596099.html?docfrom=rrela

 

1. Introduction to power domains

Power Domains--Why Do We Use Them?

a. Advanced low power designs look to reduce dynamic and/or leakage power by:

--creating sub-regions of the design (power domains) that use advanced LP techniques such as

• shut down
• multi-voltage
• DVFS, AVFS
• low Vdd standby
• well biasing

b. Any block where the power behavior is desired to be different will require a power domain

--power behavior is defined with respect to power domains

 

How do we use power domains?

a. Power domains (PD) determine the connections of power nets and the implementation of powered-down voltage areas

b. For UPF designs, you must have at least one PD

--A top-level PD must be defined before any supply-related synthesis or analysis of the design can be performed.

c. PD’s should be defend on hierarchical blocks

--Start with the top level of hierarchy and work your way down

--Nested PD’s are allowed as long as each PD is contiguous and completely enclosed within any higher level PD.

--Each hierarchical cell can belong to only one PD

 

 

 

2. Power domain partitioning

Partitioning guidelines

Power domain creation must save power

a. Additional power domain logic consumes power *and* can negatively impact timing

• switch cells
• isolation cells
• retention registers
• level shifters
• power controller logic

b. If there is not a significant value to the power being saved then do not add complexity with a new domain

　　Requires analysis

　　　　Create basic UPF with needed logic (i.e. isolation cells; retention registers)

　　　　　　--synthesis with minimal constraints to allow power analysis with and without advanced low power features.

　　　　　　--Analyze libraries to provide an estimate of power consumed by switch cells

　　　　　　　　>> Ideally a floorplan with switched voltage area should be created to allow switch cell exploration up front.

 Do not force a power domain inappropriately

a. logic not powered down much of the time should not be considered for a shutdown domain.

b. Timing critical logic should not be considered for low voltage or dynamic voltage and frequency scaling

c. Only create power domain where functionality AND performance of the logic makes it useful to either do shutdown or use a different supply voltage

Consider design priorities when partitioning

a. If area is critical, consider area consumed by additional logic before creating a power domain

--switch cells, to avoid IR drop issues, can require an additional 10% area in a shutdown block.

--Isolation cells and level shifters require more area than buffers

--Retention register can require 30% more area than normal registers

--Power control logic takes up additional real estate

--Power control routing and additional PG mesh routing also take up additional die area

b. If performance is critical, consider:

--Special cells can impact critical path timing

　　Isolation cells and level shifters increase path delay

--Restoring known state after shutdown can cause multi-cycle delay before device can return to normal operation

 

Partitioning Tradeoffs

 Another way to consider the problem

a. Designs are all about tradeoffs

b. Advanced low power designs are no different

c. Additional power domains add:

--Complexity

• power structures
• control logic

--Time to schedule

• RTL generation, mainly with power control logic
• Floorplanning
• Power network creation
• Verification
• Design analysis due to additional power modes (i.e. timing; power; LVS/DRC; EM/IR Drop analysis is made more complex)

d. These are the tradeoffs for whatever power the domains might save

e. May be easier to consider what is timing critical and/or always-on and wok forward based on that consideration

 

Partitioning Tradeoffs

 What about shutdown style?

Top-level being shutdown vs. always-on

　　Top-level shutdown:

• Allows test logic to be shutdown
• Must manually specify AO logic
• Isolation strategies are tricky

　　　　--Where to specify isolation insertion?

• Always-on macro handing becomes tricky

　　　　--Logic feeding must be correctly isolated/shifted/AO

• IOs require special handing

　　　　--set_related_supply_net required for defining AO IO's

　　Top always-on:

• AO logic will not cause design issues
• Easier feedthrough insertion
• No dedicated VA required for IO's

 

Minimizing Complexity

a. Consider methodology first

　--Keep the methodology as simple as possible

　--walk before running

　　i.e., do not add domains with DVFS and shutdown if the team has never done shutdown or multi-voltage design previously

　　　　--Add complexity to methodology as schedule allows.

　　Because of the methodology complexity the flow is not turnkey

　　　　-- Requires development of experience

b. Create power domains based on:

• Highest power savings
• Lowest additional cost

c. Be sure to consider control logic and verification in determining cost

 

 Other considerations for complexity

a. Make sure libraries are MV ready before expending effort

b. There are many more mainstream techniques for reducing power

--Dynamic power reduction

• Architecture and system changes
• IP an RAM/macro selection
• Clock-gating
• Low power design components (i.e. Min Power Components)
• Date gating
• Relative placement

 --Leakage power reduction

• Multi-threshold optimization
• IP and RAM/macro selection

c. Consider the value of each method and only add complexity as necessary

--If other techniques help reduce power to a reasonable level, consider using those rather than adding power domains

 

Key Recommendations

a. Create new power domain only if

--It saves power

--It will not compromise higher priority deign constraints

--It will not cause unreasonable impact on schedule due to added complexity

b. Design tradeoffs are made all the time

-- Power domain partitioning needs to have tradeoffs understood before committing

 

3. Scope

UPF Terminology: Scope

a. The logic hierarchy level where a power domain is defined is called the scope of that power domain

b. UPF objects can be local or global, depending on whether the -domain option was used when they were defined

--Local scope -object only available in the scope of the power domain to which they were associated

--Global scope -object available in all power domains defined in the current scope and below

c. To set the working scope in UPF

　　set_scope instance_name

d. To set the scope to the top level

　　set_scope /

 

 

 

Single- vs. Multi-Scope UPF

a. Defining UPF only in the top level scope (Single-Scope)

--All UPF objects exist in the top level of hierarchy

--Child domains do not need supply ports

--Will need to use –reuse option to share supply nets between power domains.

b. Defining UPF in child scope (Multi-Scope)

--UPF is more modular, child RTL + child UPF

--Not everything can be defined/done in the child scope

          Example: cannot connect supply nets from parent to self

--Child UPF is loaded in top level UPF

          >load_upf –scope u_dhm_core core.upf

          OR

          >set_scope u_dhm_core

          >load_upf core.upf

 

3. Partitioning on hierarchical blocks

Defining Power Domains

Power domains can be defined on hierarchical sub blocks

--Each hierarchical cell can belong to only one power domain

--If undefined, power domain is inherited from parent

--A leaf cell inherits its power domain from its parent

--Nested power domains are allowed

 

 

Defining Power Domains –Examples

a. Defining power domains on logical hierarchical boundaries is ideal

b. UPF command: create_power_domain

 

 

Power Domain Definitions on Hierarchical Blocks: Many-to-1 Design Structure

Defining boundary strategies can be problematic

--Implementation tools see sub designs as not having shared interfaces

--Interface to every block in the element list is handled as a separate interface

 

Can’t do this: create_power_domain PD1 –elements{A, A/D} =>errors out

  Instead do this: define A and A/C in two different power domains

          create_power_domain PD1 –elements {A}

          create_power_domain PD2 –elements {A/C}

 

 

Can’t do this: create_power_domain PD1 –elements {B, B/E/G} =>errors out

          Instead do this: define B and B/F in two different power domains

                    create_power_domain PD1 –elements {B}

                    create_power_domain PD2 –elements {B/F}

 

 

5. Implementing power domains

Implementing Power Domains

a. Power Domain (PD) is a virtual concept

--Parts of a design sharing common power behavior

b. Voltage Area (VA) is a physical object

--Physical representation of a PD

--Specific coordinates defining the boundary where elements of a given PD are located

c. For implementation, each PD must correspond to a VA, and a vice versa

d. Strongly recommended that PD and its corresponding VA have

--1:1 relationship

--same name

--same hierarchical cells

e. To define VA: -create_volage_area *

 

 

Voltage Area Mapping

RTL vs. Power Domains vs. Voltage Area

 

 

Defining PD’s and VA’s On Hierarchical Blocks

Example 1: IP synthesized as part of flat design

 

 

Defining PD’s and VA’s on Hierarchical Blocks

Example2: IP module synthesized separately

 

 

Defining PD’s and VA’s on Hierarchical Blocks

Example3: Sibling elements in a common power domain

 

 

a. In a flat flow, A, C, D and B can belong to one power domain

   NOTE: Nets that connect between A and B logically traverse Default Domain

b. In a hierarchical flow, [A, B] cannot be a partition, because B belongs to a separate hierarchy

 

 

What happens if I don’t have 1:1 correspondence between PD and VA?

a. It is possible to define a VA boundary that does not correspond to the PD boundary

--Useful then logical block needs to be physically spread across the design

--Referred to as a disjoint voltage area

b. Since PD separated into multiple VA’s allows more flexibility in floorplanning

--However, signals interconnecting the disjoint VA regions must be handled properly

c. Placement optimized across disjoint VA regions

 

DRC on Nets Crossing Disjoint Vas

a. Nets in the same power domain that traverse default VA require special handing

  

b. Problem could also occur on a feedthrough net crossing a non-default VA

 

c. Essentially a physical feedthrough issue in both cases