Reset Query

First of all I assume that all the resets will be synchronous resets (if any asynchronous reset is present it will be inherently independent of the clock).

Then you have to analyze what will happen in the transient which takes place soon after the reset signal. If any "out-of-sync" transient is acceptable in your system then you can use a single reset signal common for the two clock domains.

If, on the other side, also the data produced by your system during the post-reset transient period are essential and cannot be worng, then you should think about a dedicated reset logic. This logic shall be fed by both clock signals and shall produce a "reset_release" signal for the faster domain which has to be asserted when the reset for the slower domain has been active at least for a clock edge.

Hi,

Thanks for your reply.

First of all reset is asynchronous (sorry that i did not mentioned it earlier)

Is there any advantage or disadvantage of using same or different resets in multi clock domain designs. Which one a exp guy will prefer;

1. Separate resets for two clock domains (Both are asynchronous)

2. Single asynchronous reset and synchronous deassertion

Please reply

Regards,

freak

As I have eplained before, it depends on how much the transient data is important for your design. If you can accept a transient with incorrect data then solution 1 is OK, there is no need to use separate resets if your design is equipped with cross-domain control signals which guarantee steady-state synchronization (enables, sync-pitches, etc.).

If, otherwise, you cannot accept "false" transient data the solution 2 will guarantee data integrity from the first data soon after the reset because of the synchronous deassertion to the slow domain.

Next Thursday you may be interestet in the webinar http://www.aldec.com/products/evaluation.aspx?productevaluationid=1b6796a6-6782-4ae0-920a-a723420036c6

which will cover also the aspects of cross-domain reset.

I hope that I have been helpful enough.

I believe that one of the issues of async resets (In this case async deassertion) is that is you have a large amount of clock skew throughout a large FPGA then if the reset is deasserted asynchronously very close to the clock edge then it is possible that some flip-flops will see one clock edge as the first after reset and others will see subsequent edges.

It all depends on the amoutn of clock skew in your design and clock frequency.

For example a 2 bit counter, bit 0 might be first clocked on clock edge n and Bit 1 on clock edge n+1, giving perhaps not the results you expected!

The clock skew may vary on each fit so you might see behavioural changes on each re-fit with async resets.

Hence I always go for synchronous deassertion, usually with async assertion.

So a long winded way of saying, I would use your option 2 :)

Hi freak,

sorry for my late reply, in the last days I was on holiday and out of any internet connection...

I don't know if you had the opportunity to have access to the webinar, the proposed solution was exactly the one that we are speaking about. So asynchronous reset first, and synchronous deassertion after.

It is really the one which is fitter-independant and more-or-less speed-independant.

Cheers

OD

I'd like to add some comments based on my ASIC design experience. One of the golden rules for ASIC design is OCPM (one clock per module). Sure, it's not possible to comply with a unknown rule. If you knew it and followed it then the question would not have arisen.

In the ASIC world (and in the FPGA world, too) there is a need to have one reset signal per clock domain and this usually is a fully synchronous reset, meaning that the signal is asserted and de-asserted synchronously. An asynchronous assertion is only needed in these seldom cases when the power-up level of output pins is critical for the external components of the system. Synchronour de-assertion is mandatory.

One of your questions has not been answered fo far in this thread: What all are Altera recommended methods for synchronization when control signals move from a faster clock domain to a slower clock domain? I don't know what Altera recommends. But there is a simple answer: If a signal passes a clock boundary then it must be synchronized with the usual 2-flipflop stage. There is no exception.

Cheers,

Harald