Global Reset paths

A

Andrés

Guest
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..
Click to expand...
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 ?
Click to expand...
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..
Click to expand...
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és 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?
Click to expand...
Howdy Andrés,

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?
Click to expand...
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é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és
Click to expand...
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.
 
A Beaujean wrote:

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.
Click to expand...
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
 
Andrés <nospam_nussspucke@gmx.de> wrote in message news:<39lghjF62701cU1@individual.net>...
A Beaujean wrote:

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.

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
Click to expand...
The setups for the two flip-flops used are very well described in the
paper mentioned :
http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf
on pages 21 and 22 (page 22 gives a VHDL implementation).

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 <= '0' ;
Else
If Rising_Edge(Clock) Then
First_Ff <= '1' ;
End If ;
End If ;
End Process ;
--
Reset_Not_Out_Process:
Process(Reset_Not_In,Clock)
Begin
If (Reset_Not_In = '0') Then
Reset_Not_Out <= '0' ;
Else
If Rising_Edge(Clock) Then
Reset_Not_Out <= First_Ff ;
End If ;
End If ;
End Process ;
--
End Arch_Of_SAFE_ASYNC_RESET ;

Hope this serves a bit.

A. Beaujean
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top