RTL considerations and Functional verification of low power designs

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.

Typical characteristics of this design style are:-

1. Some of blocks in the design will be shut-down, when not functional.
2. There will be blocks, which are always on.
3. These blocks could be of same voltage or different voltage.
4. The power structure to shut-down a block could be either completely external or internal. Most commonly used is internal power structure to shut-down blocks.
5. Either VDD or Ground can be cut-off.

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.

RTL/Micro-Architecture requirements:-

1. Some of the blocks will be shut-down. Does your design have control logic that generates signals locally to shut-down the block ?
• I think, if the design was architected from the beginning with power gating design style in mind, it will have a control block, which probably might make decisions on which blocks to shut-down and when and how long this has to be shut-down etc. Now the other question that comes to mind is, Is this sufficient? Do I need a separate power control block, which takes inputs from the control logic and generates the power down signals in the desired sequence ? I think it is a good practice to introduce such logic to control the complete power-down/power-on sequence.
2. Lets look at the control signals required:
• Control Signal for the Power Switch (Switch_enable)
• Control Signal for the Isolation Cell Enable (Isolate_enable)
• Control Signal for the retention flops (Save_Restore)
• Now, I think ideally all these control signals are derivative of each other!. Its just that these signals need to be generated in the right order for the circuit to behave as desired.
• sequence could be:
  
• Inactivity generate
1. Generate Save_Restore: This will indicate that the retention flops needs to transfer the contents from Master Latch to Slave and go into sleep mode.
2. Generate Isolate_enable: This will enable isolation cells to be active and clamp the output to a known voltage and state.
3. Since all the basic elements are informed of the shut-down operation, we can now generate Switch_enable, to turn off the power rails, that control specific blocks.
4. There could be other actions such as reduce the frequency/reduce the voltage….etc as a part of this sequencing.
5. As a part of this sequence definition, we should define the right Assertions too, so that if the right sequence is violated, this can be flagged up-front.
• Sequence power_sequence
1. Save_Restore && Isolate_enable && Switch_enable ==0
2. ##1 Save_restore ==1
3. ##1 Save_restore && Isolate_enable == 1;
4. ##1 Save_restore && Isolate_enable && Switch_enable ==1;
• endsequence
3. If the above control signals exist in RTL, these are driven by power management logic but are not connected to anything!
• Even though as said in bullet 2 these control signals are generated by Control Logic, these are not connected to anything outside this control logic. The reasons are:-
• Power Switch that's used to cut-off power does not exist in RTL. These get added probably during Power Planning. Floor-planning/Power Planning Engineer will add these based on the specification from the Architect of the chip. Till switches are in place Switch_enable is floating.
• In RTL there is nothing specifically done for Retention Flop, these are coded like any other register and Synthesis tool will infer them based on some commands. Save_restore end up floating.
• Isolation cells does not exist in the RTL and hence Isolate_enable is floating.
• Now the Question arises. How do we simulate them? We see them in order...
1. Power Switch Behaviour
2. Isolation Behaviour
3. Level Shifter Behaviour
4. Retention flop.

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:

1. Trace through the fanout of all the outputs of this block. Flag an Error if corrupted signals are propagated till the reciever.
2. When switch_enable goes inactive, either reset all the logic in the block to "X" or to some random pattern.
3. During power up, stagger the power up of different blocks randomly!!!
4. 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..

1. Is a proper sequence for all the control signals defined ? Examples of this could be:
• Switch_enable @ 5ns
• Isolate_enable @ Switch_enable "+" 10ns
• Save_Restore @ Isolate_enable "+" 20ns
2. Now the block, which we are trying to shut-down needs to generate an Acknowledgment signal, indicating power-up or power-down. This signal is again a floating output not driven by any logic,but is processed by the power management logic!!!
3. Is there a requirement, such as : Block needs to be powered-up within "n" clock cycles? What if you don't receive an Acknowledge within "n" clock cycles?
4. If all the above are taken care of during micro-architecting, there are still few more questions that need to be answered for Logic Synthesis and Functional Simulation:
   – Is Isolation Cell/Level Shifter part of your RTL ? How are you coding this ? Are you instantiating it in the RTL?
   – Are Retention Flops part of RTL ? How are you coding this ? Are you instantiating it in RTL ?
   – How will the control signal get interpreted by the implementation tool, as they (the control signals) are floating?
   – How will Acknowledge signal get generated? Since it's required by power management logic, but is not generated by any hardware?
   – How will functionality of all these get verified, given that some of them are either floating or not generated ?
   – How will the shut-down get simulated ? Nothing special is done in RTL to simulate this behaviour.
   – How do we model Shut-Down to verify the functionality?
   – How will the retention flop behaviour get simulated ? In RTL it's coded like any other register.
   – When a block wakes up from shut-down, what should be the status of all the logic? Is random better or using "X" better ? Wouldn't "X" be very pessimistic ?
   – How to simulate the behaviour of "n" clock cycle requirement of the Acknowledge Signal from power-down block ?
   – If there are some always on logic residing in a shut-down block, how do we implement them? How do we verify them ?