Professional Documents
Culture Documents
Instruments
1
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 cons
Conclusion
IP Intensive
More than 100 IPs
On State
LP State1
VD1
PD1
PD2
Always on
PD1
PD2 Always on
VD1
PD3
VD2
PD3
VD2
LP State3
LP State2
VD1
PD1
PD2 Always on
PD1
PD2 Always on
VD1
PD3
PD3
VD2
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)
External IP RTL
IP level Flow
Compilation
Compiled RTL
Compilation
Simulation
External IP RTL
IP Level Flow
Compile Compiled library
HM Power Intent
Compile
Compiled library
PA generator
Simulator + PLI
Assertions
11
Cons
No mechanism to validate the PCF files. Run time 2 to 3x slower than normal RTL simulation Tools are not very robust yet.
12
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
Compiled library
Compilation
Simulation
Cons
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 Emulation
17
Compilation
Emulator run
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
Static/Structure verification
1. Lint tools to verify PM connectivity 2. Static low power verification on power netlist 3. STA based static checks
20
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
BACK UP
22
Level shifter Retention flip/flop, latch Retention memory Power switch Wakeups Always on logics/domains IO iso/wakeup
23
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
Support of expressions for power control signals Supports specifying the source, destination and cell kind of constructs for always on path tracing.
25
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
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
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
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
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