Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   VHDL (http://www.velocityreviews.com/forums/f18-vhdl.html)
-   -   Global Reset paths (http://www.velocityreviews.com/forums/t23445-global-reset-paths.html)

=?ISO-8859-1?Q?Andr=E9s?= 03-09-2005 08:43 AM

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

dwerdna 03-09-2005 11:35 PM

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


Marc Randolph 03-10-2005 12:22 AM

Re: Global Reset paths
 

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


dwerdna 03-10-2005 05:10 AM

Re: Global Reset paths
 
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


Paul Leventis \(at home\) 03-10-2005 01:07 PM

Re: Global Reset paths
 
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.



Marc Randolph 03-11-2005 03:28 AM

Re: Global Reset paths
 

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


=?ISO-8859-1?Q?Andr=E9s?= 03-11-2005 08:30 AM

Re: Global Reset paths
 
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

Marc Randolph 03-11-2005 01:07 PM

Re: Global Reset paths
 

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?


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


Paul Leventis \(at home\) 03-11-2005 02:28 PM

Re: Global Reset paths
 
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.



A Beaujean 03-11-2005 04:13 PM

Re: Global Reset paths
 
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


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

http://www.sunburst-design.com/paper...ton_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.


All times are GMT. The time now is 06:44 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.