This article is about RTL in a Multi-Voltage environment and it's implication on verification.
In the earlier posts i discussed Multi Voltage design infrastructure. Today let's look at 'Power Gating', the most common design style to reduce Leakage Power.
Consider a classical scenario, wherein implementation/verification becomes a real challenge.
"We have a chip taped-out, working fine in 65nm. We want to add more functionality to the same chip and want to accommodate the logic within the same die-area as before. To accommodate this silicon real estate requirement, we decided to move to 45nm. Since the application as well as the technology node demands extremely low leakage, we want to shut-down some blocks in the design."
Given this, it's very very challenging to accommodate Power Gating, since this chip is not architected to accommodate Power Gating
Now, given the characteristics of Power Gating Design Style, here are some facts I think, we need to consider while Micro-Architecting the design.
Remember, we don't have any representation of the above cells in the RTL. Firstly do we need to simulate the behavior of all of them? Typically in good old days, PLI's were written by verification teams to simulate all of them.
For example say,
Power Switch Behaviour: We can write a function/pli with following specification
$power(block_to_be_pd, type_of_pd(aon/shut-down)signal_used_for_shut_down(switch_enable), acknowledge signal(acknowledge))
Now this PLI should look at the "
type_of_pd", which is either always_on or shut-down and act accordingly. In case the block under consideration is of type shut-down, then whenever it detects an activity on the "
switch_enable" signal, it should corrupt all the signals of the block. Once all the signals are corrupted, it should generate an "
acknowledge" signal after a user specified delta delay.
In my humble opinion, this should also include something like:
#0
$power(block1)
#20
$power(block2)
This enables us to simulate the behaviour of power sequencing. There is lot more that can be added to this PLI routine such as:
- Trace through the fanout of all the outputs of this block. Flag an Error if corrupted signals are propagated till the reciever.
- When switch_enable goes inactive, either reset all the logic in the block to "X" or to some random pattern.
- During power up, stagger the power up of different blocks randomly!!!
- Emulate Impact of IR-drop using staggering principle!
Isolation Behaviour: This is again pretty straight-forward. All we need is a PLI or a simple function in Verilog, which will be something like:
$isolate(input,early_switch_enable,output,output_sense)
If "
early_switch_enable" is active, maintain the output at "
output_sense(1/0)" value, irrespective of the state of input.
Retention Behaviour: This is again pretty straight-forward from a simulation perspective. The PLI or a simple function, which will be something like:
$retain("register_names",early_early_switch_enable,wake_up)
Whenever "
early_early_switch_enable" is active, copy the contents of "
register_names " onto a local shadow_register or a local memory, and whenever "
wake_up" goes active, reload the "
register_names" with contents of the shadow_register.
Now there are various complex flavors of all the above depending the circuit behaviour of these speciall cells. The major question to be answered is, are we looking at 2 different RTL? One for synthesis without any PLIs and one for simulation with PLIs. Can these PLIs be synthesized into H/W automatically by all the EDA tools available? Is this the right approach? Can these be solved using a different approach?
More Questions that need answers..