Global Reset using Global Buffer

Eric,

The global clock network on Virtex, Virtex E, Virtex II, Spartan 3, and
Virtex 4, has dedicated IOB locations to get onto the global tree
easily, which then goes to a clock switchbox in the center of the die,
and then on to the H-tree which then goes to every CLB/IOB/BRAM/DSP/DCM
tile's clock input (it goes nowhere else).

The switchbox also is able to "see" clock outputs from the DCM tiles
which have been connected to drive a global clock resource.

So, if you place a logic signal on the global clock resource, it has
only one possible destination:  the clock inputs of the tiles.

In V5 we added the ability of the global signal to "get off" the H-tree
at the destination, and re-enter local interconnect.

Austin

I understood. And thanks for all for the replies.

So, I can't use a global line for reset and like all Xilinx guys say,
I shouldn't use it.
IMHO the lack of reset circuitry is a serious flaw.
I have a global enable too, that must get everypart of the design.
Again, no way to use it as global. This is even a more serious flaw,
since enable is the best design pratice regarding FPGAs.

I think I'll have to prey that PAR meet my timing constraints, as they
are somewhat tight... Does anyone have a better idea than using low
skew lines?

Can it be done with any other FPGA that can route a common signal to a
global net, without being a clock? I=B4ve read that both Altera and
Lattice support reset signals, *maybe* they support other signals too.

Regards,

On Nov 28, 12:54 pm, Jim Wu <jimwu88NOOOS...@yahoo.com> wrote:
> > In FPGA Editor, if you click on the interconnect matrix where the global=

> > lines feed each CLB, each bubble that connects to a global line - when
> > clicked on - will highlight the paths that connection can feed.  They
> > are all clock lines, no reset.  If you highlight the bubble connected to=

> > the slice clock lines, you'll see where the clock can get its signal.
>
> > Through the CLB interconnect matrix, the global lines can only feed
> > clocks (at least in families before V5).
>
> Using global lines for reset should work in Virtex4 as well.
>
> Cheers,
> Jim

> IMHO the lack of reset circuitry is a serious flaw.

Bold statement :) More likely we don't know or understand their
reasons for not including it. Every new thing added has a cost. I can
guess at some reasons:
-global routing networks are expensive, clearly they are justified for
clocks, but reset?
-this is reconfigurable hardware so following power up the FPGA is put
into a known state following configuration - so is reset really
required?
-Reset can be coded into your design where needed. Providing resets on
the inputs and outputs, and waiting for the pipeline/intermediate
registers to flush gives the appearance of, and has the same effect as
a design wide reset.

Regards
Andrew

Andrew FPGA wrote (in response to the inabilty to use global clock nets
to drive FF resets:
> Every new thing added has a cost. I can guess at some reasons:
> -global routing networks are expensive, clearly they are justified for
> clocks, but reset?

I don't think anyone was proposing adding additional global nets.  The
question is how expensive would it be to add either:

1)  Additional routing resources within the CLB to allow an existing
    global clock net to drive the FF reset

2)  Additional routing resources within the CLB to allow an existing
    global clock net to drive local lines, which could then be used
    for logic and/or to drive the FF reset

Apparently the Virtex 4 and 5 have done one of these, so the answer
is that the cost isn't too high to preclude doing it in high-end FPGAs.
Maybe the cost is too much for Spartan series FPGAs, or maybe it will
appear in a future part, i.e., the 65nm Spartan-4 parts that Wim Roelandts
said we'd get in 2007.  Time's running out, guys!  :-)
    http://www.ednasia.com/article-2591-itisamyththatxilinxhasnolowkproduct-Asia.html

About Andrew comment "global routing networks are expensive, clearly
they are justified for clocks, but reset?"

Yes, reset! Lets say I have a computational block, that must be
cleared after computaion and I must save older values. I won=B4t
reprogram the FPGA every time.
Or let me say that one can use partial reconfiguration. The other
parts of the system are always allowed to keep an unkown state?
But some will say: "use a sync reset". And I tell: same problem. I
wish it global!

And how about a global enable signal? Or somekind of global control?

I still find that the lack of global lines for logic is even a serious
flaw, worst then the reset one.

Regarding to Erics comments, as follow:

> I don't think anyone was proposing adding additional global nets.  The
> question is how expensive would it be to add either:

Agreed. And even if its expensive, global generic nets would be
useful. Be for reset or not. Like I said, I'd like to use a global
enable too.

> 1)  Additional routing resources within the CLB to allow an existing
>     global clock net to drive the FF reset
>
> 2)  Additional routing resources within the CLB to allow an existing
>     global clock net to drive local lines, which could then be used
>     for logic and/or to drive the FF reset
>
> Apparently the Virtex 4 and 5 have done one of these, so the answer
> is that the cost isn't too high to preclude doing it in high-end FPGAs.
> Maybe the cost is too much for Spartan series FPGAs, or maybe it will
> appear in a future part, i.e., the 65nm Spartan-4 parts that Wim Roelandts=

> said we'd get in 2007.  Time's running out, guys!  :-)
>    http://www.ednasia.com/article-2591-itisamyththatxilinxhasnolowkprodu..=
.

But I=B4m still looking for a FPGA that has global generic nets.

>
>But I'm still looking for a FPGA that has global generic nets.
>
>
Try looking on the Actel web-site. From memory, the ProASIC family has
them.

(If my memory is wrong, I apologise in advance for the waste of time).

On 30 Nov, 12:50, "RCIngham" <robert.ing...@gmail.com> wrote:
> >But I'm still looking for a FPGA that has global generic nets.
>
> Try looking on the Actel web-site. From memory, the ProASIC family has
> them.
>
> (If my memory is wrong, I apologise in advance for the waste of time).

Yes Actel does have this facility, the ProAsic family anyway.  They
also have the ability to split a single global net into lots of little
local global nets, or spines as they call them.  I have previously
used this on the APA devices and found it very useful for things like
enables.  The PA3 and fusion devices give you even more global nets to
play with.

Depending on your design complexity, they are well worth a look at.
My only problem with them is the lack of dedicated multipliers.

An article on the local/global and synchronous/asynchronous aspects of resets:

http://www.fpga-dev.com/resets-make-them-synchronous-and-local/

>Hello Group
>
>I=B4ve read a lot about resets and I=B4ve decided that for my designs, an
>asynchronous solution with a synchronous source is a better solution.
>No discussions here, this is a personal (almost religious) choice.
>

Religious choice is an apt description. How else can you justify something
that has zero scientific evidence to support it?

What you are looking for is called a synchronous reset distribution tree.
Google that and you find some papers on it on Cliff Cumming's web site. It
is the only way to distribute an asynchronous assert/synchronous deassert
reset without skew.

Global resources are used when you have to deal with fast signals. PowerOn
reset is very very slow. Don't waste resources on it.

Remember that the reset system only has two requirements. 

  1) Force the chip into a known good state while the reset button is
pressed.

  2) Do nothing while the reset button is not pressed.

Most designers obsess over making sure the first condition is met while
barely considering the second one. This is odd because if you screw up
either one then your product will fail. Which one should keep you awake at
night?


Your product will spend 99.999999% of its power on time running and
susceptible to esd induced resets but it is only possible to have a power
on reset failure during the 0.000001% of the time that it is powering up.

Modern digital tool flows can easily catch design errors that would prevent
a chip reset in the RTL phase. Simulating esd events is a lot harder and
most of this  is done by QA testing.


These failures are asymmetric. If an esd event can get into your chip and
change state on a flop then your product is crap. If your power on reset
fails to reach a flop it will simply take on the next state value provided
by the mission mode logic. What will that be? It will almost always be the
same as the reset state.

The power on reset system has a good deal of redundancy.Everybody first
puts in a power on reset system and then adds their mission mode logic that
backs up the power on reset with the mission mode soft reset systems. You
can forget to connect a flop into the power on system and it will likely
still work.

It is almost impossible to screw up the reset system so that your product
fails to power up AND to do so in a way that your verification suite won't
catch it.

But it is very easy to have a esd entry path and not catch it till you get
the customer returns. You should first worry about preventing phantom
resets and after you have solved that then worry about getting power on
reset into your chip.


If you do that then you will never run an asynchronous reset signal down to
the core flops. Read Xilinx WP-231.


John Eaton

 



  




 
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

jt_eaton <1590@embeddedrelated> wrote:
>>Hello Group
>>
>>I=B4ve read a lot about resets and I=B4ve decided that for my designs, an
>>asynchronous solution with a synchronous source is a better solution.
>>No discussions here, this is a personal (almost religious) choice.

> Religious choice is an apt description. How else can you 
> justify something that has zero scientific evidence to support it?

> What you are looking for is called a synchronous reset distribution tree.
> Google that and you find some papers on it on Cliff Cumming's web site. It
> is the only way to distribute an asynchronous assert/synchronous deassert
> reset without skew.

For FPGAs, power up is always asynchronous, and you have to have
some way to get from configuration reset to operation.

> Global resources are used when you have to deal with fast signals. 
> PowerOn reset is very very slow. Don't waste resources on it.

Hopefully the FPGA designers did use (not waste) resources on it.

> Remember that the reset system only has two requirements. 

>  1) Force the chip into a known good state while the reset button is
> pressed.

>  2) Do nothing while the reset button is not pressed.

> Most designers obsess over making sure the first condition is met while
> barely considering the second one. This is odd because if you screw up
> either one then your product will fail. Which one should keep you awake at
> night?

If you can stop the clock until the system is out of reset and ready,
then there should be no problem. Otherwise, yes, you do have to be
very careful about the transition. 

-- glen