Approaches for Power Management Verification of SOC
1. Approaches for Power
Management verification of SoC
having dynamic power and
voltage switching
Prabhu Bhairi
Texas Instruments
1
2. Agenda
β’β Overview of low power design
β’β Why low power verification?
β’β Limitation of traditional simulators.
β’β Tools and flows at various stages of design cycle
ββ Flow details
ββ Prosβ conβs
β’β Conclusion
2
3. Typical Low Power Design Desc.
β’β Design Size > 20 Million gates
β’β Multiple Voltage Domains and Power Domains
β’β Many Always ON Paths
β’β Lots of Power Switches, Isolations and Level Shifters and Always On buffers
β’β Many Retention Flops
β’β Power Management :
ββ Shutdown/Sleep: Voltage Domains and Power Domains
ββ Retention Schemes: Multiple retention flops
β’β IP Intensive
ββ More than 100 IPβs
4. Dynamic Power and voltage switching
ON
OFF
On State LP State1
PD1 PD2 VD1 PD1 PD2 VD1
Always Always
PD3 VD2 PD3 VD2
on on
LP State3 LP State2
PD1 PD2 VD1 PD1 PD2 VD1
Always Always
PD3 PD3 VD2
on on
5. Limitations of Traditional Simulators
β’β Limitations
ββ There is no mechanism to partition design into multiple voltages and
domains.
ββ Traditional simulators insensitive to power states of the device.
ββ Simulator engines does not recognize
1.β Voltage changes.
2.β Retention behavior of logic/memory
5
6. What is power aware Simulation?
β’β What is Power Aware Simulation ?
ββ Mimicking the power down/wakeup behavior at RTL/Gate level simulation.
β’β Why is Power Aware Simulation needed ?
ββ Todayβs complex SoC designs have considerable logic implemented for
Power Management.
ββ Most of the PM logic can be implemented at RTL/Gate level.
ββ Important to find the critical bugs at early stages in the design cycle.
7. Approaches of Low power verification
1.β ynamic/simulator based verification
D
2.β tatic/Structural Verification
S
7
8. Dynamic/simulator based verification approaches
1.β Simulator platforms
ββ RTL level(PARTL) : Power Aware RTL simulations-UPF/PCF/CPF
ββ Gate Level(PAGLS): Power Aware gate level simulations
2.β Emulator platform
ββ RTL Level : Power aware verification UPF/PCF/CPF based
ββ Gate Level: Power aware gate on accelerator platforms (Zero delay)
8
9. Top Level SoC
External IP
RTL+ Internal
RTL
IPβs
IP level
Flow
Compilation
Compiled
RTL Compilation
Deliverable
to SoC team
Simulation
External IP flow
9
SoC flow
10. Top level SoC RTL
External IP HM Power + internal IPβs
RTL Intent
IP Level
Flow
Compile Compile
Top level
Compiled Power Intent
library
Compiled library
PA generator
Simulator + PLI
External IP flow
Assertions
SoC flow 10
11. Requirement of PARTL tools for SoC
1.β Standard, inheritable and reusable (across all phases of the design cycle)
power constraint specification
2.β The constructs to have robust power intent specification
3.β Handling Multi Vendor IPs (simulator specific Compiled RTL) with in-house
logic in mixed HDL mode.
4.β The Multiple Retention scheme, schemes could be vendor specific.
5.β Low coverage at SoC level, cannot cover every flip flop and every signal by
SoC level self checking scenario simulation.
1.β Support of assertions
6.β Extract the info about Retention flops, Latches, always on signals etc from
RTL using the tool
7.β Handling behavioral models.
11
12. Proβs and Conβs of PARTL
β’β Proβs.
ββ Highlight issues very early in design cycle- Before RTL freeze.
ββ Easy to debug compared to other platforms.
ββ Run times are better than PAGLS
β’β Conβs
ββ No mechanism to validate the PCF files.
ββ Run time 2 to 3x slower than normal RTL simulation
ββ Tools are not very robust yet.
12
13. What is power aware Gate
β’β What is Power Aware gate?
ββIt is a netlist with power switches and cells with power
pins
β’β Why is Power Aware gate?
ββLot of power management features will be implemented
by BE tools .
ββThis netlist has all the switches and power connection so
can catch any potential issue in power feature
implementation
14. External IP Top Level SoC
power Netlist Power Netlist
IP level
Flow
Compile
Power aware
modeled cell
Compiled libraries Compilation
library
Deliverable
to SoC team
Simulation
External IP flow
14
SoC flow
15. Proβs and Conβs of PAGLS
β’β Proβs.
ββ Very close to final design hence best candidate to catch issues.
ββ Will catch any issue in BE implementations and power constraint file issues
ββ No Power constraint creation effort
β’β Conβs
ββ Run time and memory foot print 4 to 5x slower compared to PARTL
β’β Netlist is ~2 times bigger than normal netlist
ββ Very late in the design cycle.
ββ Debugging is very difficult.
ββ Developing the power aware library models is effort intensive.
15
16. Power aware emulations with RTL
Enable better
Run application PM feature space
Faster run time ? scenarios ? coverage! How?
Use an emulation platform!!!
16
18. External IP Top Level SoC
power netlist Power netlist
IP level
Flow
synthesis
Emulator
data base Compilation
Power aware
Emulator lib
cells
Deliverable
to SoC team
Emulator run
External IP flow
18
SoC flow
19. Advantages
β’β Randomized values may create a worst case scenario compared to βxβ in
simulations
β’β Inherently faster platform.
β’β System level use-cases for PA features can be planned and executed faster.
β’β Enables us to do full coverage due to the speed the platform offers.
Limitations
β’β There is no real βxβ hence few fails may be masked
β’β Many features not yet fully supported on production version in Emulations
platforms
β’β Debugging is tedious
β’β Vulnerable to power constraints issues like PARTL if Emulation RTL flow is
used
19
21. Conclusion
β’β Low power requirements have undoubtedly exposed a new challenge in
DV/EDA community.
β’β Lot of flows and EDA support already exist.
ββ Each of them have there own benefit and limitations
β’β Given all this Silicon still remains the best platform for low power
verification,
β’β Pre SI DV: we just do not have a perfect solution today because of
enormous complexity in the design. we should continue focus on
improvement on flows and tools.
β’β Simulation speed with low power enabled worsens even more.
21
23. Key words in low power implementation
β’β Power domain
β’β Voltage domain
β’β Isolation cell
ββ Tie cell, ISO latch
β’β Level shifter
β’β Retention flip/flop, latch
β’β Retention memory
β’β Power switch
β’β Wakeups
β’β Always on logics/domains
β’β IO iso/wakeup
23
24. Low Power Verification Challenges at
SoC level and solutions
1.β Standard, inheritable and reusable (across all phases of the design cycle)
power constraint specification
Soln:-
ββ Supports the standard power specification format (like UPF)
ββ If any legacy power intent is specified for an IP
β’β Ex: APF->UPF, PCF->UPF conversion is seamless to user.
24
25. Low Power Verification Challenges
at SoC level and solutions
2 Support of constructs to have robust power intent specification.
Soln:-
ββ Support for wild character
β’β Ex *iso_cel* for specifying always on signals
ββ Support of expressions for power control signals
β’β Ex: A xor B for shutdown.
ββ Supports specifying the source, destination and cell kind of constructs for always
on path tracing.
25
26. Low Power Verification Challenges
at SoC level and solutions
3 Handling Multi Vendor IPs (simulator specific Compiled RTL) with in-house
logic in mixed HDL mode.
Soln:-
ββ RTL cannot be provided from external IP vendors
β’β Flow should not demand RTL
ββ Supports simple flow for delivery of IP DB readable by tool.
ββ Generation of power aware DB needs to be simple and no major changes to
the existing IP flow required.
ββ UPF at IP level to be reusable in top level simulations
26
27. Low Power Verification Challenges
at SoC level and solutions
4 Support for Multiple Retention scheme, schemes could be vendor specific.
Soln:-
ββ Tool should be able to read the asic cell models of retention flops and generate
the Power Intent.
ββ Input could also be given by a generic UPF format in the early stages of the
design
27
28. Low Power Verification Challenges
at SoC level and solutions
5 Low coverage at SoC level, cannot cover every flip flop and every signal by
SoC level self checking scenario simulation.
Soln:-
ββ Use of built in assertions for the following cases can reduce the debugging time
and help in capturing bugs, which can be missed by self checking testcases
β’β βXβ propagation on always on paths
β’β Retention flop/Latch protocol violations during save or restore.
β’β Low Voltage wiggling indicators.
β’β Power Islands States and Sequence of Switching.
28
29. Low Power Verification Challenges
at SoC level and solutions
6 Cross check with gate netlist.
Soln:-
ββ Extract the info about Retention flops, Latches, always on signals etc from RTL
using the tool
ββ Extract similar info from a back end tool,
ββ Compare the two to confirm the implementation.
29
30. Low Power Verification Challenges
at SoC level and solutions
7 Handling behavioral models and initial blocks
Soln:-
ββ Corrupting behaviar models not required as it takes unnecessary toll on
performance
ββ Only output corruption is good enough
ββ Initial blocks need to be reevaluated on each wakeup
30