Combining two async resets

Hi,

I am having two async reset inputs to my design. If I have to OR both the resets, where should I use the OR gate?
1. Should I synchronize(async assertion and sync deassertion) resets separately and then put an OR gate?
2. Should I first combine (OR gate) both the reset and then use the reset synchronizer?
3. Should I use the method 1 and then put one more reset synchronizer after OR gate?

Which method is best/suggested? What are the pros/cons of these methods?

Thanks,
Ashish

Method 2 sounds like it might generate unwanted glitches. Method 3 is the most reliable, but it's going to cost more registers. I think method 1 should work. The OR gate is not going to generate much delay, but you could always add a single register after the OR gate.

Does it create any problem for Scan/ATPG?
How the OR gate is tested? Let's say if there is any stuck at fault in OR gate (combo in reset path)?

I was speaking from FPGA experience. I don't really know ASIC requirements.

Ashish Agrawal said:

Does it create any problem for Scan/ATPG?
How the OR gate is tested? Let's say if there is any stuck at fault in OR gate (combo in reset path)?

Click to expand...

you have direct controlability over the inputs of the OR gate, testing should not be a problem.

Given we have an OR gate the reset is active high and the reset synchonizer would look like follows:
If either RESET1 or RESET2 is 1 then both FFs are set to 1 and the active high SYNC_RESET is enabled asyncrhonously.

Therefore due to the OR gate we have one of the following conditions:
00 - No reset active
01|10 - one reset active
11 - both resets active
regardless how the resets overlap or don't overlap there are no reset glitches produce from the OR gate. You can potentially have a low going pulse (to inactive reset) if the two resets are close but do not overlap. e.g.
but that is not going to produce a reset glitch, but it may or may not produce a inactive reset pulse (synchronous de-assert, synchronous assert) if the width of that pulse exceeds the two clock cycle period of the two FF synchronizer.

So the #2 version of the syncrhonizer is perfectly fine.

The #1 synchronizer virtually guarantees that there is always a low going glitch every time the resets occur such that one reset being removed lines up with the start of the other reset being asserted. But considering this reassertion of resets is done asynchronously does it really mater? probably not. Though this low pulse will change dependent on the delays from the FFs to the OR gate over temperature, voltage, and process. Besides that the drawback IMO is the additional gate delay for an already heavily loaded net. I suppose this OR gate can be the driver cell for the net, but I'm sure there are other "driver only" cells better suited for this.

#3 is pretty much the same as #2, but with the input synchronized to the clock. Which begs the question of why this is more reliable than just doing #2 by itself as the reset synchronizers of #1 don't help all that much, it just leaves you with a low going pulse that goes low aligned with the clock edge.

Hi ads-ee,
Thanks for the detailed analysis.

In my design some flops need only RESET1, some need only RESET2 and some need both. So anyway I have to synchronize both the resets separately.
Now If I combine both of the resets and then put one more synchronizer, this will add 2 cycle additional delay to these flops (using combined reset) for reset de-assertion (assuming async assertion and sync de-assertion). I am not sure, if this will affect the functionality.

Ashish Agrawal said:

I am not sure, if this will affect the functionality.

Click to expand...

It might, depends on your design. If you have another signal that you can use as a 'start computing now' flag, it should be fine. Just make sure it is asserted N cycles after the resets are done, with N>2.