A question regarding asynchronous reset

--- Quote Start ---

one of the function I use these discrete lines is as asynchronous reset to blocks of the design.

so far so good.

--- Quote End ---

No, not so good.

If you simulate the post-place-and-route design, you will probably see glitching on the combinatorially generated reset line.

Register the reset signal with the same clock as your NIOS system. This will ensure that there are no glitches on the reset line.

If the reset is going to another clock domain, you should then synchronize the reset there too; it can asynchronously assert, but synchronously deassert. Altera has examples showing how to correctly synchronize reset.

Cheers,

Dave

Hi

I started to realize that after I posted my question. sometimes writing something down helps to organize the thoughts. :)

I use asynchronous reset as a habit, It always looked more robust to me. I guess I should use only at the top of the design for hard reset from the board or from the PLL lock signal, not when it is sourced from combinatorial logic...

It's strange though that Timequest didn't recognize the threat.

Thanks Dave

--- Quote Start ---

I started to realize that after I posted my question. sometimes writing something down helps to organize the thoughts. :)

--- Quote End ---

Yep, I can appreciate that!

--- Quote Start ---

I use asynchronous reset as a habit, It always looked more robust to me. I guess I should use only at the top of the design for hard reset from the board or from the PLL lock signal, not when it is sourced from combinatorial logic...

--- Quote End ---

Change your habits. Place a reset synchronizer at the top-level of the design for every different clock domain, i.e., don't have a port list with rstN, a_clk, b_clk on your lower-level components, have a_rstN, a_clk, b_rstN, b_clk. That way you have the synchronizers in one place. (SOPC Builder/Qsys will probably insert extra synchronizers).

--- Quote Start ---

It's strange though that Timequest didn't recognize the threat.

--- Quote End ---

It should analyze it via reset recovery analysis. But if you cut the path, then it'll ignore it. So it depends what you did in your .sdc file.

Cheers,

Dave

--- Quote Start ---

Hi

It's strange though that Timequest didn't recognize the threat.

--- Quote End ---

Any timing analysis can only check destination registers when source signal changes are known. I mean if your signal is just an input(unregistered) then there is no path from its entry to its destination register to be analysed as signal transitions are undefined. This rule applies to any inputs thus for any project submodule, timing analysis will not check front end registers and for asynch reset it will find no paths for recovery/removal. The remedy is to register all inputs (at least temporarily for the sake of timing until integration adds input registers).

The io timing entries(set input delay) is the way to give that info for actual final inputs. However it does not apply to asynchronous reset which is best synchronised first to its clock domain then applied to the its dedicated register port.

--- Quote Start ---

Change your habits. Place a reset synchronizer at the top-level of the design for every different clock domain, i.e., don't have a port list with rstN, a_clk, b_clk on your lower-level components, have a_rstN, a_clk, b_rstN, b_clk. That way you have the synchronizers in one place. (SOPC Builder/Qsys will probably insert extra synchronizers).

--- Quote End ---

thankfully I only have one clock driving logic.

--- Quote Start ---

It should analyze it via reset recovery analysis. But if you cut the path, then it'll ignore it. So it depends what you did in your .sdc file.

--- Quote End ---

My .sdc file is very short. the clock definitions. that Timequest derived from the PLL instantiation, SOPC builder generated assignments, and false path between my clock and altera internal JTAG clock.

KAZ, according to the RTL viewer, the decoder includes a register for it's input and then the decoding logic (a XOR not for each signal). anyway this signal are coming from the NIOS not IOs. I run the Timequst to the entire design, not for each block separately.

and as I said I only have one clock domain.

when I say asynchronous I mean that in the block VHDL code I have something like:

process (clk,areset)

if (areset = '1') then

--reset signal to a known state

elsif (rising_edge(clk)) then

-- do some stuff

I didn't mean that the signal itself is asynchronous to the design, apparently this kind of coding is appropriate, only for that kind of signals, and if I understand you correctly even then you recommend first registering the signal and then treat it as synchronous reset.

Yes that is appropriate provided reset is pre-synchronised then applied to asynch port.

It is the terminology that might confuse. Applying a nonsynchronised reset to asynch port or through D input(so called synchronous) does not synchronise it !! applying Data to D does for Q out of register but this does not apply to reset. Thats why it should pre-synchronised in either case

--- Quote Start ---

process (clk,areset)

if (areset = '1') then

--reset signal to a known state

elsif (rising_edge(clk)) then

-- do some stuff

--- Quote End ---

The areset signal must be 'synchronized' to the 'clk'. This VHDL connects the signal to the asynchronous reset port of the FPGA registers. Those registers have a 'setup/hold' timing requirement with respect to the reset port.

The TimeQuest documentation discusses this.

I first read about it a while ago in some papers by Cliff Cummings at Sunburst design (he has lots of good advice). Read the two papers on resets (and the ones on FIFOs are good too):

http://www.sunburst-design.com/papers/

Cheers,

Dave