Magic Blue Smoke


Simulating Retention 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 :

$power (“GATED_DOMAIN”,shut_down,1’b0,power_ack,1’b0,”ctrl”);
$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.