Explicitly setting a variable to undefined

These conversations pop up about once a year or so both in this newgroup and in some of the vendor forums. And usually, like now, RAM, and Configuration "initialization values", and the GSR is brought up.

But these don't help in (many) cases. First the simple case - as Rick points out and Xilinx admits, GSR is useless to depend on for reset. It's inactive edge is slow, and asynchronous. Might as well ignore it's existance right out

- it can't work reliably on the inactive edge (the edge you care about). At the inactive edge of that reset, the conservative designer will assume all your FF's will enter an unknown state.

With *CAREFUL* inspection, one may be able to make use of the GSR (i.e. making sure D=Q for some cycles around GSR), but this is tricky, and definitely the exception, not the rule in my designs.

But this is often trumped more with the often errant assumption that "FPGA Configuration" == Reset. That's usually not true. Again, with *CAREFUL* inspection, perhaps some may make use of this. But again, for me it's the exception no the rule.

Again, this also may be just a reflection on my design use; much of the work I do is reused on many FPGAs. So it's really hard for me, when coding up a FF deep within some logic to say "This FF will *always* be ok to not reset", in *ANY* place where the logic may be used, with certainty. It's just safer to reset the thing.

I'd really like better tech and tools in the FPGA world to allow me to just reset everything. Logic is becoming cheap with these newest dense, FPGAs. Something like a clock tree, but for resets that has looser skew requirements than actual clock trees. Or better tools support to actually just create a pipelined resets as others have suggested. (BRAINSTRORMING) Or how about another "RESET_BUFG" type cells that tags along with every BUFG - but creates a pipelined (on the same clock as the BUFG) version of that reset. Fix the depth of the pipeline at some (reasonable) value. Costs some silcon, but systemically solves the problem for everyone..

Or some other (creative) systemic solutions.

Fumbling about case-by-case (or customer-by-customer) isn't optimal.

Regards,

Mark

That is the exact opposite of what I am saying. Rather than assuming all FFs go "crazy", I assume the reset is released asynchronously with the clock and so I need to control the release from reset of the few critical FFs that you can expect to change state.

He was pretty clear about what he was saying in that white paper. (Did you read and understand it?) Not saying I agree with it all, particularly the parts that are wrong. I notice that some Ken Chapman designs (e.g. picoblaze) have interesting failure modes associated with reset (e.g. don't include code to work around Xilinx AR# 42571 "block RAM contents can be corrupted even if the write enables are low"), so I wouldn't blindly trust everything he says.

How long has it been since you've used a Xilinx part? I don't believe your statement about async resets being replaced by GSR has been true for the last six generations of device (Virtex 4 onward). If you code an async reset in your HDL, an async reset ends up in the chip, and this may lock out other CLB features (e.g. sync reset) which might otherwise save a LUT.

The last time I checked, a connection to the GSR input on the startup block did *not* cause the CLB async reset connection to be removed by the tools. (At various times in the past this has worked on older Xilinx FPGA families though e.g. Virtex 2.)

Regards, Allan

According to Xilinx, the GSR in (at least modern) Xilinx FPGAs is NOT a physical, global signal in hardware that resets everything after configuration to a defined state.* It is just a signal that enables the configuration that was just loaded, i.e. it makes the FPGA start ticking with everything already being set. So, e.g. FFs are set to a specific value BEFORE this "pseudo global reset" even occurs, the logic is just not active yet; so when the reset is released and the logic starts running, everything is already in a known state. The case that e.g. an FSM gets confused because one of it's inputs isn't initialized yet when it starts running cannot occur.

Still, as you mentioned, you can of course run into problems if you need to make sure stuff starts running at the exact same clock cycle (which for me personally, having to deal with a multitude of clock domains most of the time, is something my designs can never rely on anyway).

What the Xilinx FAEs say (and again, this does not necessarily reflect my personal opinion, I'm just quoting here):

- no need for a global reset that resets EVERYTHING to a known state, configuration will take care of that

- for your design, regional, synchronous resets (or at least de-asserted synchronously) might be useful that only reset small areas of the design; so if you need to make sure that in a specific portion of the design everything starts up at the exact same clock cycle, you should generate a local synchronous reset and selectively connect that to where it's needed, but not more. The example they always bring up is algorithmic pipelines, which make up a good portion of a lot of designs; no need to reset those, there'll be garbage coming out at the end anyway until the pipeline is full.

- One of them told me (and I'm not kidding, just quoting here): Relying on a global reset signal to get your design into a known state sometime after power-up is a sign of bad design. You should make sure your designs can recover.

So, to sum up: they say you should use local, synchronous resets, not a global one, and you should consider not using a reset signal at all for most parts of the design, since in their opinion it's a completely unnecessary waste of resources in many cases.

Be that as it may, I find I often resort to using resets to make sure the tools don't optimize e.g. pipeline stages or synchronizer flipflops into SRL components (which are useless for timing). That's easier than figuring out which attribute/constraint you have to apply to which signal/component at what design stage to disable SRL optimization for this specific set of registers...

• Just googled and found this:
  formatting link
  (see Gabors answer)

Think about what you wrote. If there is no physical signal, how does the release of reset get communicated across the entire chip? It is a signal, it just isn't a *fast* signal with global buffers, etc like a clock line. That's why they include a GSR component in the design tools.

In Lattice parts it is a lot easier to use configuration as a reset because the configure so much more quickly from Flash. In a Xilinx part re-configuration can be too slow to be practical when resetting the design. The GSR can be used as an external reset.

I wouldn't argue about that. It greatly depends on the design.

That is essentially what I am saying, but how do you kick off the local synchronous resets? That requires the asynchronous GSR.

I don't look at the local reset as a local reset. I just design the circuit to work with the async GSR. It is not uncommon for a circuit to work properly without any local reset (for simple ones mostly) or just a single FF to allow the circuit to remain in reset for a clock after GSR is released.

The "global" vs. "local" reset thing is also a silly guideline from Xilinx. The signals have the same definition to the synthesizer => the synthesizer will merge all the "local" resets back into a "global" reset. We code all of our resets globally in a "clocks and resets block". In that block we synchronize the inactive edge of reset, and send it out globally.

There's every reason to do this once, globally, instead of forcing each designer to repeat the same thing locally on every block. Exactly contrary to the guideline.

The original idea had some sense, pre-synthesizers. That's long past.

Regards,

Mark

How the reset is implemented in fabric is not very straightforward thing. There is the "after configuration state", then reset lines can be lifted into clock networks which in Ultrascale for example look like the old good ASIC clock trees etc. You can get the restet to work with pretty high frequencies, but that can lead into routing congestion. Also some of the FPGA features cannot be used if FFs have resets (internal DSP, BRAM pipeline registers etc.). Also having traditional ASIC resets sometimes creates interesting logic to emulate it. And not all structures can directly connect into the clock (read reset) trees and there are limitations how many trees can connect to where.

Removing reset in data-pipeline and leaving it only to control part improves timing and congestion dramatically in some designs. I have seen many nanoseconds off by just removing unnecessary resets which enabled much better packing as control sets got smaller.

There is one good chapter on this in Ultrascale training materials, it is good reading. They also suggest interesting ways to use clock gating features to change the reset to multicycle path etc.

--Kim