Archive for the 'Architecture' Category

last week we saw physical structure of LS/ISO cells. Today lets look at

(a) Retention Registers: These are typically either dual height cells or single height wide cells. They have Primary Rail and Secondary Rail. Primary Rail is switchable and Secondary Rail supplies power, when Primary Rail is off. They are typically placed in a shut-down region. One important factor is, Secondary Rail need not be of same potential as Primary Rail in ON state. Having a potential just enough to retain the state while primary is off would be the most efficient way to optimize leakage. Higher the Secondary Rail potential more will be the standby leakage current.

One of the biggest challenge in the design process is how can we automatically identify, number of registers in the switchable block to be retained? This could be done primarily based on the design architecture knowledge and also based on how fast one wants the switchable block to be up and running. Latter part can be automated in a way using some of the formal/property checking tools.

Other challenge is in verifying the functionality of Retention Register during functional simulation. Some of the verification challenges are listed below.

(i) Simulate Save/Restore Functionality.
(ii) Verify the functionality of ” When Save is asserted Secondary Rail is already active with the required potential”.
(iii) Verify the functionality of ” When Restore is asserted Primary Rail is completely ON”.
(iv) When Retention Register is in Save mode and if Secondary Rail drops(because of adjust block waking up) to a value below the required potential, how do we recover ?
(v) What if Save/Restore Lines are not treated as ALWAYS_ON ?

……etc

Lets look at the the other 2 important cells in the next post.

Wish you all a very Happy and Prosperous New Year. Hope you all had a good holiday season.

In the last post we saw how UPF answers our questions with respect to the power behaviour of a design. Today lets look at how the various commands in UPF are catergorised.

(1) Power Domain Related
create_power_domain

(2) Power Supply/Nets related
create_supply_port
create_supply_net
connect_supply_net
set_domain_supply_net

(3) Special cell related
set_level_shifter
set_isolation_control
set_isolation
set_retention
set_retention_control
map_retention_cell

(4) Power Switch
create_power_switch

(5) State Table
add_port_state
create_pst
add_pst_state

(6) Utility Commands

In the next post, we will discuss functional verification using UPF, the first aspect of a design flow.

Once again, wish you all a very Happy and Prosperous 2008 !

UPF is a way to represent the Power Intent of a design. It directs all the tools in the flow to interpret the Power Intent in the same way. Before we jump into the details of UPF, let’s try to understand what we mean by Power Intent.

Typically for any design implementing any of the Advanced Low Power Techniques, we need to ask or have answer to the following questions:-

(a) What techniques are used to reduce power in the design?
Example: Multi-Voltage, Multi-Supply, Back-Bias, DVFS, AVFS etc.

(b) How is the design partitioned with respect to Voltage ?
Example: Core has 3 Voltages and IO has one Voltage

(c) Is there any block, whose power will be shut-down when block is not operational ?

(d) Does technology support these techniques?

(e) Are special cells such Level Shifter, Isolation Cell, Switches …. etc available in the library ?

(f) Is the architecture chosen for Power Gating, Coarse-Grain or Fine-Grain ?

(g) Is the power source internal to chip via on-chip variable regulator or an external regulator?

(h) What’s the expected Wake-Up time ? What’s the expected Ramp up Time ?

and so on.

Answers to these questions in a standard format such as UPF is the Power Intent of the design. Based on this information provided via UPF, various tools in the flow are going to make the appropriate implementation/verification decisions.

In my next post, let’s take a sample design and see how the verification tool will interpret this information.

Most common issue faced in any Low Power Design is how can we minimize noise coupling between different rails and between cells in the same power domain. I am planning on discussing these in my next 2 posts.

Power and Ground Noise can degrade timing and can lead to functional failures. Most commonly used method is to insert decoupling capacitors to minimize the IR-Drop issues. Insertion of these Decap cells can be more challenging in a Power Gated design than a normal design. One of the reason for this being more challenging is “In Rush current management“.

In any power gated design one of the main requirement is to make sure that block that’s being shut-down wakes up as quickly as possible, without impacting the functionality of the other alive blocks. But this requires a very well managed In-Rush current circuitry. Now the question is , how come this impacts Decap Insertion?

If we remember, one of the most common methodology to minimize Current Surge during wakeup is

(1) Hook up the switches in Daisy Chain fashion
(2) Hook up the switches in buffered fashion
(3) Hook up the switches in Star Topology….etc

Now main goal in the daisy-chain topology is to sequentially charge the power gated block to reduce the current surge. However the current required to turn on the first switch of each chain can cause significant noise and voltage drop to the neighbouring cells. So one of the basic thing we need to follow is insert Decap’s next to switch cells, which is the main source of noise during wake-up.

But blindly inserting lots of decap’s in a power gated design has its own implication, which I will try to cover in my next post.

I was in discussion with a designer other day on “Impact on performance of the design if the voltage range is not choosen correctly”, today I am going elaborate a bit on this topic.

While designing the system with DVFS techniques, we need to look at the impact of temperature inversion on the performance of the design.While selecting the voltages and frequencies for the design, one must consider the range such that delay/voltage consistently either increase or decrease. What this means is we must always operate above the temperature inversion point.

Especially in low power UDSM process combined use of reduced VDD and High Threshold voltage may greatly modify the temperature sensitiveness of the design. Due to this worst case timing is no longer guaranteed at highest temperature.So in order to guarantee the correct behaviour of the design, one has to verify the design at various PVT conditions. This leads to increase in the total turn around time.

In a nutshell, Normally delay increases with increase in temperature, but below a certain voltage, this relationship inverts and delay starts to decrease with increase in temperature. This is a function of threshold voltage(Threshold voltage and carrier mobility are temperature dependent). Due to this threshold voltage dependence, we have observed that non-critcal paths suddenly become critical.

Having said this as soon as Voltage/Delay relate randomly Voltage Scaling becomes a nightmare to implement and verify

Note: If both threshold voltage and carrier mobility monotonically decrease with increase in temperature, Operating Voltages(range) defines the performance of the design.

I was in Boston last week attending SNUG and got a chance to interact with many designers and one of the key concerns raised were in understanding the Voltage scaling approach . Planning to take a quick tour on this topic in my next few posts

There are various voltage scaling approaches that are in use today

Static Voltage Scaling: Different blocks in the design will be operating at different fixed supply voltages

Multi-level Voltage Scaling: An extension to static voltage scaling where in different blocks are switched between two or more voltage levels.

Dynamic Voltage and Frequency Scaling : An extension to Multi-Level Voltage Scaling Voltage levels are dynamically varied as per the work-load of the block

Adaptive Voltage Scaling : An extension to  DVFS and its a closed loop representation of the above method. Power Controller block within the design adopts itself dynamically to varying work-loads.

DVFS example: Here is an outline of tasks that will be executed within a design to scale voltage and frequency dynamically, controller first decides the minimum clock speed that meets the workload requirements. It then determines the lowest supply voltage that will support that clock speed. Given below is an example of a sequence thats followed  if the target frequency is higher than the current frequency

– Controller monitors the variance in work-load
– Controller detects variation in work-load and programs the device to operate at different voltage
– Block under question continues operating at the current clock frequency until the voltage settles to the new value
– Controller then programs the desired pre-determined clock frequency

Varying clocks and voltages during operation is  a new methodology in the design and leads to many challenges in the design process

– Identifying the optimal combination of Voltage/Frequency
– How to model the timing behavior
– Clock and Power Supply locking times.

Last week, we saw on how to simulate retention flops using $functions as well as using adhoc methods to simulate similar behaviour. We have been hearing a lot about power standards helping us in solving this problem. Here is how UPF can help us in simulating this behaviour

set_retention gated_retention -domain IGATED_DOMAIN -retention_power_net VDD -retention_ground_net VSS

set_retention_control gated_retention -domain IGATED_DOMAIN -save_signal {power_sequence/save high} -restore_signal {power_sequence/restore high}

map_retention_cell gated_retention -domain IGATED_DOMAIN -lib_cell RETENTION_FLOP

Waveform given below shows snap-shot of the simulation behaviour

In my earlier posts we discussed retention mechanisms. Today lets look at how to simulate this at RTL Level.

As we all know, today MV Simulation can be accomplished using some standard power formats such as UPF/CPF. Since some of these are not in full production, I quite often get this question : “How do we simulate retention behaviour without having a PLI routine such as $retain ?”

There are multiple ways to do this. First, you could use the MVSIM simulator. Another way could be :

(a) Partition the design to accomdate implicit $retain in simulation. Consider the example of a module ctrl, which needs to be powered down and has 3 sub-modules. This module ctrl also has retention registers to save the states. In this case if I can architect the module ctrl to have, say “ctrl/ctrl_combo”, “ctrl/decode” and “ctrl/retention_registers”.

Now ‘ctrl/retention_registers’ has all the required retention registers and nothing else. In this case $constructs can be coded as :

`ifdef SYNTHESIS
$power (“GATED_DOMAIN”,shut_down,1′b0,power_ack,1′b0,”ctrl”);
`else
$power (“GATED_DOMAIN”,shut_down,1′b0,power_ack,1′b0, “ctrl/ctrl_combo”, “ctrl/decoder”);

Now if you look at the above $code, for simulation purpose “ctrl/retention_registers” is excluded from $power and for synthesis entire ctrl block is included.

What this does is, by construction all the states within “ctrl/retention_registers” are saved. When ever sleep signal is asserted entire “ctrl” module is shut-down except “ctrl/retention_registers”. $power will corrupt all the logic except this and in a way retention behaviour is accomplished. Here all the inputs to this to block is still corrupted and all of them wakeup in a unknown state. This is close to silicon behaviour, in a sense.

I am not saying that this is always possible, but in many cases the retention flops are “state memories of a state_machine”, in this case we have to divide the state_machine into next_state_decoder block and state_memory block and the required retention can be accomplished by just including “next_state_decoder” in the $power construct.

(b) If the above method cannot be implemented due to logical partition problem, the other approach is to use MVSIM+VCS to simulate the behaviour of retention flops or PLI based approach.

One important thing to consider in PLI based approach is “Potential Race Condition” and this is going to be quite tricky to resolve.

In the last 2 posts, we discussed how retentions cells look like and what are the advantages/disadvantages. Since most of the designs do have memories and they tend to be shut-down, how is the state of memory retained ? We cannot reload the data from external memory into the local memory. Today let’s see how this is accomplished.

Fifos and Stacks are often flushed before powering down the device and caches are initialized once the device wakes up from shut-down state. In these scenarios, we can power down the memories to save static power by sacrificing memory data.

However, for high performance designs which require fast wakeup, the contents of on-chip memory need to be retained during shut-down. Various memory retention mechanisms are in use today.

The fundamental requirement is to save as much leakage as possible without corrupting the data.

It is not feasible to introduce a retention circuit like those discussed in my previous posts for memory cells. Any such circuit will cause an unacceptable area increase. Instead various retention schemes such as VDD/VSS save_restore and Source/Drain diode bias save_restore mechanisms are used.

VDD/VSS save_restore Mechanism:

In this method, a separate power supply is provided to memory, which will be lowered to a voltage closer to Vt(0.4-0.5V) during shut-down.

Source Biasing save_restore Mechanism:

The principle of the source biasing save_restore mechanism is to apply reverse body bias for further leakage reduction after lowering the memory operating voltage.

In this method a Diode is inserted in the source supply path of the memory array and this diode is controlled through a switch.

In normal operation the sleep signal is deasserted, hence the diode is bypassed as the switch is closed and works like a regular power supply. In shut-down mode switch is open and hence the source supply to the memory cell is through the Diode. The built-in threshold voltage of the diode rises the ground voltage closer to Vt and hence the leakage is reduced, similar to VDD save_restore mechanism.

Technorati Tags:

Low Power,
Architecture,
Memory Retention,
Source Biasing

Last week, we discussed about the type of retention registers available. In this post let me highlight few more points

Pro’s and Con’s of Single Pin Vs Dual Pin retention flops:

Advantages of Single Pin:

Minimal area impact
Single signal controls retention

Disadvantages of Single Pin:

Performance Impact on the register
Hold Time requirements for the input data

Advantage of Dual Pin:
Minimal leakage power
Minimal performance impact compared to the Single Pin design
Minimal dependency on the clock for the control signals.

Disadvantages of Dual Pin:
Area Impact
More Complex System Design
More Buffer Network and AON network required.

In my next post, I will try to highlight some of the key requirements w.r.t retention mechanism when memories are used.

Technorati Tags:Low Power,Architecture,Retention Flops Synopsys,