Global Reset paths

Hi Andres

Why do you need to have the reset signal sync'd?? Usually a reset is a pretty 'abrupt' sort of action, with no return, so you dont need it to be sync'd, and it can go over many clock domains..

process: (gsr, sys_clk)

if (gsr = '1') then

--reset

elsif rising_edge(sys_clk) then

--sync signals...

end if;

end process;

Or am I not understanding you properly??

to

If you don't have a reset pulse within your FPGA, you'll have to reload the device everytime you want to get back to a known good condition. Although it may be unnecessary with FPGA's most people tend to pulse reset at the beginning of action, not just at the end... and/or they pulse it to recover from error conditions, or reinitialize after a reboot.

Granted people tend to overuse resets, but even so, most designs need to be able to recover from them.

To answer the OP's question, all FPGA's that I'm aware of have a single global reset net. And despite what many say, a co-worker has found a very smart way to use it (at least on V2Pro and newer), even for designs with multiple domains. If you don't end up using it, then you'll chew up quite a few resources if there are many loads

Have fun,

Marc

Hi Marc

Sorry if it wasnt clear, I understand what resets are used for, and your examples are no different to what I was thinking off, and they are still asyncronous arnt they?? I dont understand what issue there is over multiple clock domains, which is the essence of this topic though..

Thanks

Hi Andres,

In Stratix/Stratix II/Cyclone/Cyclone II/Max II I believe that you can route an async reset using any global clock or local routing. For example, Stratix II has 16 global clocks plus a bunch of quadrant-wide clocks. These clock networks can be used to route non-clock signals -- they are very good for distributing high-fanout signals. The clock networks can be driven directly by clock pins and by PLLs, or they can be fed from any other resource in the chip by routing a signal to an internal access port.

The Quartus II software will automaticaly promote high-fanout and asynchronous signals onto the clock network (which are thus called "globals" in Quartus).

Regards,

Paul Leventis Altera Corp.

are

When you release the reset, it may be asynchronous to the clock - so some FF's may come out of reset before others. That can cause problems for things like state machines and counters. Search comp.arch.fpga (and probably comp.lang.vhdl) for reset+release ...

Have fun,

Marc

Thank you for your answers,

although I have searched for the topic "reset + release" I am still confused. If Mr Randolph says that there in only one global reset path so does it make any sense to release the reset signals for the different clock domains separately that is to synchronize the reset with the corresponding clock and distribute different reset signals?

Best regards Andrés

different

Howdy Andr=E9s,

Sorry, I wasn't very clear - but believe it or not, Paul and I aren't contradicting each other.

Although all FPGA's that I'm aware of have only one global reset net, Altera has considerably more total local and global control resouces. Just take a look at the block diagram for their LE.

I had somehow forgotten about Altera's LAB level resets LABCLR1 and LABCLR2 (in addition to chip level clear). I must defer to Paul Leventis for the details on how you can use them (after all, he works for Altera), but hopefully he'll confirm that you can run your reset net through a series of synchronoizing FF's before you put it onto one of the LAB (or global) reset nets so that when the reset is deasserted, it isn't asynchronous to the clock.

Paul?

Have fun,

Marc

Marc,

The "global" networks can be driven by the general routing in the chip, which in turn can be sourced from any logic block in the chip. So you can bring in a reset on a normal I/O, whip it through synchronizers, and then pass the synchronized signal(s) through the global low-skew network to distribute to all the affect nets. Or you can route the resulting synchronized signal on normal routing with an appropriate timing constraint to ensure that all flops will be released on the same clock cycle.

I don't think we have a dedicated chip-level clear, but I could be wrong... I thought that a chip-wide clear is implemented just by driving a global network directly from a user or clock I/O. But its not my area of specialty -- I'll ask around to confirm.

BTW, the Quartus 4.2 timing analyzer software will perform Recovery and Removal Analysis for asynchronous paths.

Regards,

Paul Leventis Altera Corp.

OK. Well, there follows a link with a very interesting paper on potential problems with (too) simple asynchronous resets.

Having acknowledged the potential dangers described in that paper, I now systematically create for my VHDL designs a synced reset per clock domain and uses those synced resets as async reset inputs on all registers of the design. I just let the synthesis and PAR tool operate as usual, giving no special directive, and got not problem until now.

Hi Beaujean,

do the registers which are used to sync the external reset have an asynchronous reset input ? If yes, what signal does feed these reset inputs ?

Thanks for all posts.

Best Rgds Andrés

The setups for the two flip-flops used are very well described in the paper mentioned :

The form I used in VHDL is very slightly different, but strictly equivalent in terms of functionality.

Architecture Arch_Of_SAFE_ASYNC_RESET Of SAFE_ASYNC_RESET Is

--

-- Signals

-- Signal First_Ff : std_logic ;

-- Begin

--

-------------------------------------------------------------------------------

--

-- SYNCHRONOUS PROCESSES

--

-------------------------------------------------------------------------------

-- First_Ff_Process: Process(Reset_Not_In,Clock) Begin If (Reset_Not_In = '0') Then First_Ff