STA and asynchronous reset

[sun_ray]

Why it is difficult to handle STA if asynchronous resets are present?

 

[jirika]

It isn't difficult if you will use CASE condition.

 

[slsindorf]

In my experience, when the .lib files are not too weird, there is never any problem with STA and asynchronous resets.
What kind of difficulties do you mean?

 

[jt_eaton]

Why it is difficult to handle STA if asynchronous resets are present?

The problem occurs when you use a soft reset system with multiple domains. Supose you wanted to put
a block of logic on it's own switched power island. You must use a soft reset to create a reset domain for
that block. To power it off you must first use the soft reset to hold the block in reset. Then you latch the
outputs while blocking the inputs going to the block. Finally you can switch off the power.

Reverse those three steps to restore power.


The problem occurs when the logic in that block uses asynchronous resets. When the soft reset system
asserts reset then it will pass through the flops and change the outputs. Since the rest of the chip is not
going in reset then these are valid timing paths and they will be longer than the usual clk-> Q path.

So Mr component designer choses an asynchronous reset because he doesn't want to see any reset logic
in his D pathways. Well he doesn't see any in his logic but he is putting it in every one of your signals that
routes between different soft reset domains.

Thats why you should never use asynchronous resets in any of your core logic.