Global Reset using Global Buffer

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:

it is still cached on google, read it.

a smaller length link.

Austin

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,

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

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.

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

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

It's not an issue about using the buffer. It does route my signal, whatever it=B4s 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 po> Eric Smith 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).

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

Using global lines for reset should work in Virtex4 as well.

Cheers, Jim

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,

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:

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! :-)

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:

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.

.

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

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,

Try looking on the Actel web-site. From memory, the ProASIC family ha 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:

Something that always seems to be missing when I read articles like this is any mention whatsoever of the FPGA?s built-in reset capabilities. For Xilinx Spartan FPGAs anyway, this is called ?GSR? (global set/reset). It?s certainly global, and I believe it?s asynchronous. I don?t know what kind of skew it typically has, but it has one wonderful benefit when it?s usable: it?s absolutely 100% free. The GSR network is built into the chip whether you use it or not, so using it to reset all your FFs costs absolutely nothing in terms of LUTs and routing, something no other solution can claim. When dealing with a nearly-full FPGA, that?s a very attractive property.

As far as issues of different FFs leaving reset on different clock cycles are concerned, could one not solve these issues by asserting GSR for long enough to reset all FFs, deassert it, then activate the clocks afterwards? Using BUFGCEs (in Xilinx parlance) one could do this with a very small chunk of logic, far less than the overhead of building synchronous resets by routing the reset signal around the chip and then feeding it into all the LUTs that make up feedback loops (increasing LUT count in, say, one sixth of such cases where the LUT was already populated by six inputs). Driving the ENABLE input of a canned oscillator off a shift register of sufficient length clocked by the internal configuration clock would probably achieve something similar. Am I missing something about this proposed solution?

I really wish someone would write one of these articles about system reset that acknowledges the existence of GSR and compares it to other reset mechanisms and points out the advantages and disadvantages of each. Unfortunately ?someone? won?t be me, because I?m nowhere near an FPGA expert and couldn?t hope to give it a proper treatment. Maybe someone has written such an article, but I haven?t seen it.

Chris