Global Reset using Global Buffer

[rgamer1981@gmail.com]

Hello Group

I´ve read a lot about resets and I´ve 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.

Now, what I´ve read about using a global line as reset line, i think
it was on a discussion "on no, reset again" (something like that). So
I had tried several times to use a Global Buffer for my Global reset.
I can use the buffer, but instead of using the global lines, it uses
regular route lines wich ends ina a great reset skew.

Giving more details, I instantiate the buffer, I can see it on FPGA
Editor but it do not use the global lines. The fpga is an Spartan3,
for information.

Does anyone knows how to force the use of one global buffer (and the
global lines) for my async reset?

 

[austin]

You can't use a global clock line as a reset,

The tools realize there is no way to route a logic signal on the global
clock line, so it does it the best way it can.

In V5, we added the necessary mux wiring so a global line could be used
for a logic signal.

As far as "global reset" is concerned, there is a nice series of
articles by Ken Chapman on the subject, but right now we are moving them
to a new location.

http://209.85.173.104/search?q=cache:kUSKmhw7emUJ:www.xilinx.com/xlnx/xweb/xil_tx_printfriendly.jsp%3FiLanguageID%3D1%26category%3D%26sGlobalNavPick%3D%26sSecondaryNavPick%3D%26multPartNum%3D1%26sTechX_ID%3Dkc_smart_reset+%22ken+chapman%22+global+reset&hl=en&ct=clnk&cd=2&gl=us

it is still cached on google, read it.

http://tinyurl.com/3bj53s

a smaller length link.

Austin

 

[Rgamer]

Hello,

Thanks for your reply.

Well, just like I said before, reset, global or not, sync or async is
not a point here. I humbly ask that this discussion to be in an
appropriante topic (there are several good discussions about it).

Back to my original question: sou, in V5 you're able to route logic
through the global lines, by instantiating the BUFG is that right?
I've done this. But the problem is: after the buffer, it still uses
regular routing lines and do not use the global ones.

Be a reset or not, can that be done to Spartan3? Can I force de route
after the BUFG to use globallines?

Regards,

On Nov 27, 1:59 pm, austin <aus...@xilinx.com> wrote:

You can't use a global clock line as a reset,

The tools realize there is no way to route a logic signal on the global
clock line, so it does it the best way it can.

In V5, we added the necessary mux wiring so a global line could be used
for a logic signal.

As far as "global reset" is concerned, there is a nice series of
articles by Ken Chapman on the subject, but right now we are moving them
to a new location.

http://209.85.173.104/search?q=cache:kUSKmhw7emUJ:www.xilinx.com/xlnx...

it is still cached on google, read it.

http://tinyurl.com/3bj53s

a smaller length link.

Austin

 

[austin]

What about "no" do you not understand?

No, you cannot use global resources for a logic signal in S3.

Yes, you can use a global clock for a logic signal in V5, but the entry
into the resource, and the exit from that resource may use additional
local routes (depending on what the logic signal is connected to/from).

You missed the entire issue of Ken's note: asynchronous resets may
"break" synchronous circuits. Since we don't support any asynchronous
circuits in the FPGA (everything assumes a synchronous logic design
flow, and we support no asynchronous logic synthesis), I think you may
be confused.

Austin

 

[Eric Smith]

austin writes:

No, you cannot use global resources for a logic signal in S3.

I've heard you say that before, and I don't dispute it, but I'm curious
as to the reason. How does the S3 "know" whether the signal I've got
driving a global clock net is actually a clock? Is there a minimum
frequency for the clock net? I don't see one in the datasheet.

Eric

 

[Ed McGettigan]

Eric Smith wrote:

austin writes:
No, you cannot use global resources for a logic signal in S3.

I've heard you say that before, and I don't dispute it, but I'm curious
as to the reason. How does the S3 "know" whether the signal I've got
driving a global clock net is actually a clock? Is there a minimum
frequency for the clock net? I don't see one in the datasheet.

It's not a case of classifying the input as a "clock", but one of "you
can't get there from here". The global clock nets go to clock pins, if
your destination is something other than a clock pin then it has to
"hop off" and use the regular routing resources to get there.

Ed McGettigan
--
Xilinx Inc.

 

[Eric Smith]

Ed McGettigan wrote:

It's not a case of classifying the input as a "clock", but one of "you
can't get there from here". The global clock nets go to clock pins, if
your destination is something other than a clock pin then it has to
"hop off" and use the regular routing resources to get there.

Thanks for the explanation; that's certainly a very good reason to not
try to use the clock net for something else.

 

[Rgamer]

I thought 2 uses for a global line, as reset and clock enable, because
my application DO require both. By the way, I´m not confused about
reset.

It's not an issue about using the buffer. It does route my signal,
whatever it´s source it is, to a global buffer (I can see that on FPGA
EDITOR) but then, it indeed "jumps" to regular lines after the buffer.
So, I thought that might there is someway to force the route through
global lines, because be it a clock or not, every signal connects to
CLB using a matrix. It could do that for anysignal. Couldn't it?

No, but it seems to me that this is imposed by the PAR tool. My point
that the clock input for every FF on the FPGA can be any signal on the
design, a bad, but possible design pratice. The same for enable and
reset.
So, the limitation is not on the interconnect matrix, because ALL
signals that enter a LUT or FF comes from there.

On Nov 27, 10:58 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

Eric Smith wrote:
austin writes:
No, you cannot use global resources for a logic signal in S3.

I've heard you say that before, and I don't dispute it, but I'm curious
as to the reason. How does the S3 "know" whether the signal I've got
driving a global clock net is actually a clock? Is there a minimum
frequency for the clock net? I don't see one in the datasheet.

It's not a case of classifying the input as a "clock", but one of "you
can't get there from here". The global clock nets go to clock pins, if
your destination is something other than a clock pin then it has to
"hop off" and use the regular routing resources to get there.

Ed McGettigan
--
Xilinx Inc.

 

[John_H]

Rgamer wrote:

I thought 2 uses for a global line, as reset and clock enable, because
my application DO require both. By the way, I´m not confused about
reset.

It's not an issue about using the buffer. It does route my signal,
whatever it´s source it is, to a global buffer (I can see that on FPGA
EDITOR) but then, it indeed "jumps" to regular lines after the buffer.
So, I thought that might there is someway to force the route through
global lines, because be it a clock or not, every signal connects to
CLB using a matrix. It could do that for anysignal. Couldn't it?

No, but it seems to me that this is imposed by the PAR tool. My point
that the clock input for every FF on the FPGA can be any signal on the
design, a bad, but possible design pratice. The same for enable and
reset.
So, the limitation is not on the interconnect matrix, because ALL
signals that enter a LUT or FF comes from there.

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).

The limitation IS the interconnection matrix. Why do you believe otherwise?

 

[austin]

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

 

[Jim Wu]

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

 

[Rgamer]

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´ve 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

 

[Andrew FPGA]

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

 

[Eric Smith]

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

 

[Rgamer]

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´t
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´m still looking for a FPGA that has global generic nets.

 

[Brian Drummond]

On Wed, 28 Nov 2007 08:59:30 -0800 (PST), Rgamer <rgamer1981@gmail.com>
wrote:

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?

If you control your design from some central state machine, add several
states between the "reset" state and the central despatcher state (e.g.
"idle" where you wait for inputs to react to and depatch to states that
do the work).

That guarantees that nothing else in your design will be active for
those several cycles; therefore reset to anything OUTSIDE these states
can be constrained as a multicycle path.

- Brian

 

[Rgamer]

On Nov 29, 12:41 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

On Wed, 28 Nov 2007 08:59:30 -0800 (PST), Rgamer <rgamer1...@gmail.com
wrote:

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?

If you control your design from some central state machine, add several
states between the "reset" state and the central despatcher state (e.g.
"idle" where you wait for inputs to react to and depatch to states that
do the work).

That guarantees that nothing else in your design will be active for
those several cycles; therefore reset to anything OUTSIDE these states
can be constrained as a multicycle path.

- Brian

I thought another solution for either global reset and global enable:
I kept the global buffer, since it has more strength (greater fanout)
and I added the attribute for low skew lines. That should do a good
job.

Regards,

 

[RCIngham]

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.

 

[Carl]

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

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