Global Reset paths

Hi newsgroup people,

one question regarding global reset paths in different FPGAs:

I have found out that in the new EC/ECP FPGAs from Lattice there
is only one global asynchronous reset paths. There is one component
called "GSR" (global set / reset) which has to be fed with the reset 
signal which is used as global asynchronous reset.
This component can be instantiated only once in the top level.

So what about the idea to synchronize one asynchronous reset signal
into different clock domains ? If there is only one global reset paths
the synchronization with different clocks would make no sense then ?


What about Altera and Xilinx FPGAs ?  Do they have more than one
global reset path ?


Thank you for your information.


Rgds

Andr�s

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??

dwerdna wrote:
> 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..

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,

> What about Altera and Xilinx FPGAs ?  Do they have more than one
> global reset path ?

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. 

dwerdna wrote:
> 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..

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

Andr=E9s wrote:
> 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?

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,

>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?

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. 

Andr&#4294967295;s <nospam_nussspucke@gmx.de> wrote in message news:<39d2qnF5uomriU1@individual.net>...
> 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&#4294967295;s

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

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

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.