Posted by namitg on 4th February 2013
When I see around most common electronic devices I find are smartphones, tablets, laptops, televisions. One of the common user need which drives competition among these devices is to conserve battery life and at the same time save/restore the application. From the semiconductor perspective, requirement is translated to â€śdesigns should be using advanced low power techniques to use minimum power and at the same time save/restore critical design statesâ€ť.
Present and future chip designs, it is almost a necessity that from very beginning power intent is mostly clear. This is the main reason that power intent description has become integral part of RTL development. Are you concerned about power consumption during RTL development?
Using UPF 2.0 abstract power supply networks are defined, also called as â€śsupply setsâ€ť. There is no ambiguity in defining supply network as it is part of planning power architecture. But the most important step which needs careful planning is to define valid power states combinations. Let me go in more depth to explain this, once supplies are defined explicitly using â€ścreate_supply_portâ€ť OR implicitly using â€ścreate_supply_setâ€ť, then valid supply states are defined next using â€śadd_port_stateâ€ť and â€śadd_power_stateâ€ť. This means defining when state will be â€śoffâ€ť, â€śhigh_voltageâ€ť, â€ślow_voltageâ€ť etc. There can be many permutation and combination of these supply states which are possible, but not all are expected and needed for design functionality. So valid combinations (or legal states) of these supplies are defined as â€śpower state tableâ€ť (PST). How complex is PST in your current designs?
PST holds the key regarding which power domain crossovers needs protection policies like isolation. Implementation tools uses PST as reference to insert protection devices on power domain crossovers, similarly static verification tools uses PST as reference to validate correctness of power intent. But what if PST has some bug, like while defining UPF user provided invalid state in PST. In such cases relying on static tools and implementation tools is not enough, and this is one of the many reasons where there is a need for dynamic verification. Based on design specification (power specification), verification team will create testplan which will create test vectors and this includes putting design into all specified valid states and once power-aware simulation will corrupt crossovers during shutdown, failing simulation will uncover PST bug. Did you ever catch PST bug in simulation? What if that bug was not caught and slipped to implementation?
Â Consider following example, where there are 2 domains PD1 and PD2, where VDD1 is primary supply of PD1 and VDD2 is primary supply of PD2, as per specification below are the valid states
While writing UPF, user forget to define power state â€śState3â€ť, in such cases static verifier such as MVRC may not be able to spot this problem as PST is reference. But verification engineer developing test will create a test to cover state â€śState3â€ť and VCS-NLP will spot the problem in simulation.
In above example consider a situation where â€śState3â€ť is not a valid state and not defined, in such situation if isolation policy is defined for domain PD1 which is applying isolation on all outputs, static verifier such as MVRC will immediately pin-point that paths from VDD1 to VDD2 does not need isolation as they are simultaneously getting ON and OFF states.
Above example illustrates low power verification flow which guarantees smooth implementation of designs using advanced low power techniques.
As size of SoC is growing and increased usage of IP, there is a strong need for hierarchical methodology, which is also applicable on low power. In hierarchical low power methodology, block level power intent is captured in UPF and once blocks are verified at top-level all block UPF are loaded using â€śload_upf â€“scopeâ€ť, this create some interesting situations where there can be many supplies and power states at block level, but top level supplies are not that many, which means many block supplies are connected to same supply at top-level and so are there power states. This is the basic need of PST merging, concept where different power state tables needs to be merged in a smart way to create top-level PST.
Consider the following example:
PST defined in block level UPF of block_b and block_c are following:
Merged PST will merge in such a way that matches top level connection like VDD_B2 and VDD_C1 is connected to same supply at top level which is VDD2. Below is the merged PST for this example:
Once dynamic verification/simulation is done, it is very important to review low power specific coverage to ensure all valid states mentioned using PST are properly verified. How your current low power verification flow ensures that proper coverage mechanism is in place to cover power intent. Does it covers PST states/transitions, power switch states/transitions, supply net/set power state/simstate transitions?
Reviewing coverage results is same as non-LP coverage, it is important from PST verification perspective to review illegal states reached during simulation. How do you ensure all legal state combinations are covered during simulation?
To summarize, best practices for implementing low power techniques on a design, power network should be defined in UPF, along with this careful addition of power states and PST will be done. This point onwards either manually defines protection policies or quickly verifies using static checker like MVRC OR iterates with MVRC and completes the protection policies. Verification team will create test plan based on design specification which will also include tests for bringing design in all legal PST states. After performing power aware simulation using tool like VCS-NLP, usual simulation debug will be done for failing tests, it is important to ensure LP specific coverage is met. At this point, design is ready for implementation using tool like Design Compiler. Are you using these best practices in your low power verification flow? Share your experience or best practices.
Posted in Low Power | Comments Off