Explicitly setting a variable to undefined

[rickman]

On 5/31/2016 9:31 AM, Allan Herriman wrote:

On Tue, 31 May 2016 08:53:27 -0400, rickman wrote:

On 5/31/2016 8:09 AM, Sean Durkin wrote:
Ilya Kalistru wrote:
They advise it for a reason. In big and complex designs big reset
network with high fanout dramatically decrease maximum achievable
frequency.

That's only part of the reason. The other part is that every FF, every
BRAM, every component of the FPGA is guaranteed by design to come up as
'0' at power up (after configuration is complete). So their claim is
that a reset (at least a global power-up reset) is simply unneccessary
and only maybe needed for things you do not wish to start up at '0'
(like, maybe a FSM state variable that dictates the initial state of an
FSM). And even in these cases it's not really needed, since the Xilinx
tools honor signal initialization values (in VHDL), and BRAMs can be
pre-loaded also. So you can be absolutely sure how every component in
the FPGA comes up after power-up, without having to use a reset signal.

You can forget about the resources the global reset signal needs,
pipelining or how to code it properly because it plain and simple is
useless and unnecessary in most cases.*
If you need to set FFs or so to specific values after power-up, then
that's a set, not a reset. Different port on the FF, different
scenario,
and certainly needed in a lot less occasions/signals, hence a signal
with much smaller fanout.

* = That's their claim, not necessarily my personal view...

I don't believe Xilinx or any other FPGA vendor makes that claim.


It seems they do (at least Ken Chapman does) make that claim.

Xilinx WP272:
"applying a global reset to your FPGA designs is not a very good
idea and should be avoided"

We are miscommunicating. I thought Sean was saying Xilinx was claiming
a proper reset was not needed. If so, I'd love to read the details on
how they justify that claim. Sean was saying the configuration reset is
adequate, which is not correct for most designs (which uses the GSR).
Yes, every FF is guaranteed to be set to a known state, but since the
max delay is typically greater than the clock cycle used, this signal
much be considered to be async with the clock which means you have to
code with this in mind.

Since every Xilinx FPGA uses the GSR to put the chip in a defined state,
I'm not sure what Ken Chapman is really saying. If you use a global
set/reset signal in your design it will be replaced by the GSR signal,
so it is used by default whether or not you infer it.

--

Rick C

 

[Mark Curry]

In article <nik4i8$fhm$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:

On 5/31/2016 9:31 AM, Allan Herriman wrote:
On Tue, 31 May 2016 08:53:27 -0400, rickman wrote:

On 5/31/2016 8:09 AM, Sean Durkin wrote:
Ilya Kalistru wrote:
They advise it for a reason. In big and complex designs big reset
network with high fanout dramatically decrease maximum achievable
frequency.

That's only part of the reason. The other part is that every FF, every
BRAM, every component of the FPGA is guaranteed by design to come up as
'0' at power up (after configuration is complete). So their claim is
that a reset (at least a global power-up reset) is simply unneccessary
and only maybe needed for things you do not wish to start up at '0'
(like, maybe a FSM state variable that dictates the initial state of an
FSM). And even in these cases it's not really needed, since the Xilinx
tools honor signal initialization values (in VHDL), and BRAMs can be
pre-loaded also. So you can be absolutely sure how every component in
the FPGA comes up after power-up, without having to use a reset signal.

You can forget about the resources the global reset signal needs,
pipelining or how to code it properly because it plain and simple is
useless and unnecessary in most cases.*
If you need to set FFs or so to specific values after power-up, then
that's a set, not a reset. Different port on the FF, different
scenario,
and certainly needed in a lot less occasions/signals, hence a signal
with much smaller fanout.

* = That's their claim, not necessarily my personal view...

I don't believe Xilinx or any other FPGA vendor makes that claim.


It seems they do (at least Ken Chapman does) make that claim.

Xilinx WP272:
"applying a global reset to your FPGA designs is not a very good
idea and should be avoided"

We are miscommunicating. I thought Sean was saying Xilinx was claiming
a proper reset was not needed. If so, I'd love to read the details on
how they justify that claim. Sean was saying the configuration reset is
adequate, which is not correct for most designs (which uses the GSR).
Yes, every FF is guaranteed to be set to a known state, but since the
max delay is typically greater than the clock cycle used, this signal
much be considered to be async with the clock which means you have to
code with this in mind.

Since every Xilinx FPGA uses the GSR to put the chip in a defined state,
I'm not sure what Ken Chapman is really saying. If you use a global
set/reset signal in your design it will be replaced by the GSR signal,
so it is used by default whether or not you infer it.

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

 

[rickman]

On 5/31/2016 1:58 PM, Mark Curry wrote:

In article <nik4i8$fhm$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 5/31/2016 9:31 AM, Allan Herriman wrote:
On Tue, 31 May 2016 08:53:27 -0400, rickman wrote:

On 5/31/2016 8:09 AM, Sean Durkin wrote:
Ilya Kalistru wrote:
They advise it for a reason. In big and complex designs big reset
network with high fanout dramatically decrease maximum achievable
frequency.

That's only part of the reason. The other part is that every FF, every
BRAM, every component of the FPGA is guaranteed by design to come up as
'0' at power up (after configuration is complete). So their claim is
that a reset (at least a global power-up reset) is simply unneccessary
and only maybe needed for things you do not wish to start up at '0'
(like, maybe a FSM state variable that dictates the initial state of an
FSM). And even in these cases it's not really needed, since the Xilinx
tools honor signal initialization values (in VHDL), and BRAMs can be
pre-loaded also. So you can be absolutely sure how every component in
the FPGA comes up after power-up, without having to use a reset signal.

You can forget about the resources the global reset signal needs,
pipelining or how to code it properly because it plain and simple is
useless and unnecessary in most cases.*
If you need to set FFs or so to specific values after power-up, then
that's a set, not a reset. Different port on the FF, different
scenario,
and certainly needed in a lot less occasions/signals, hence a signal
with much smaller fanout.

* = That's their claim, not necessarily my personal view...

I don't believe Xilinx or any other FPGA vendor makes that claim.


It seems they do (at least Ken Chapman does) make that claim.

Xilinx WP272:
"applying a global reset to your FPGA designs is not a very good
idea and should be avoided"

We are miscommunicating. I thought Sean was saying Xilinx was claiming
a proper reset was not needed. If so, I'd love to read the details on
how they justify that claim. Sean was saying the configuration reset is
adequate, which is not correct for most designs (which uses the GSR).
Yes, every FF is guaranteed to be set to a known state, but since the
max delay is typically greater than the clock cycle used, this signal
much be considered to be async with the clock which means you have to
code with this in mind.

Since every Xilinx FPGA uses the GSR to put the chip in a defined state,
I'm not sure what Ken Chapman is really saying. If you use a global
set/reset signal in your design it will be replaced by the GSR signal,
so it is used by default whether or not you infer it.

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.

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.

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

--

Rick C

 

[Allan Herriman]

On Tue, 31 May 2016 09:45:42 -0400, rickman wrote:

On 5/31/2016 9:31 AM, Allan Herriman wrote:
On Tue, 31 May 2016 08:53:27 -0400, rickman wrote:

On 5/31/2016 8:09 AM, Sean Durkin wrote:
Ilya Kalistru wrote:
They advise it for a reason. In big and complex designs big reset
network with high fanout dramatically decrease maximum achievable
frequency.

That's only part of the reason. The other part is that every FF,
every BRAM, every component of the FPGA is guaranteed by design to
come up as '0' at power up (after configuration is complete). So
their claim is that a reset (at least a global power-up reset) is
simply unneccessary and only maybe needed for things you do not wish
to start up at '0' (like, maybe a FSM state variable that dictates
the initial state of an FSM). And even in these cases it's not really
needed, since the Xilinx tools honor signal initialization values (in
VHDL), and BRAMs can be pre-loaded also. So you can be absolutely
sure how every component in the FPGA comes up after power-up, without
having to use a reset signal.

You can forget about the resources the global reset signal needs,
pipelining or how to code it properly because it plain and simple is
useless and unnecessary in most cases.*
If you need to set FFs or so to specific values after power-up, then
that's a set, not a reset. Different port on the FF, different
scenario,
and certainly needed in a lot less occasions/signals, hence a signal
with much smaller fanout.

* = That's their claim, not necessarily my personal view...

I don't believe Xilinx or any other FPGA vendor makes that claim.


It seems they do (at least Ken Chapman does) make that claim.

Xilinx WP272:
"applying a global reset to your FPGA designs is not a very good idea
and should be avoided"

We are miscommunicating. I thought Sean was saying Xilinx was claiming
a proper reset was not needed. If so, I'd love to read the details on
how they justify that claim. Sean was saying the configuration reset is
adequate, which is not correct for most designs (which uses the GSR).
Yes, every FF is guaranteed to be set to a known state, but since the
max delay is typically greater than the clock cycle used, this signal
much be considered to be async with the clock which means you have to
code with this in mind.

Since every Xilinx FPGA uses the GSR to put the chip in a defined state,
I'm not sure what Ken Chapman is really saying.

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.

If you use a global
set/reset signal in your design it will be replaced by the GSR signal,
so it is used by default whether or not you infer it.

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

 

[Sean Durkin]

rickman wrote:

Since every Xilinx FPGA uses the GSR to put the chip in a defined state,
I'm not sure what Ken Chapman is really saying. If you use a global
set/reset signal in your design it will be replaced by the GSR signal,
so it is used by default whether or not you infer it.

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:
https://forums.xilinx.com/t5/Archived-ISE-issues-Archived/FPGA-Power-On-Reset/m-p/7027?query.id=134602#M2035
(see Gabors answer)

 

[Mark Curry]

In article <dr7cdkFhkh0U1@mid.individual.net>,
Sean Durkin <news_MONTH@tuxroot.de> wrote:

rickman wrote:
Since every Xilinx FPGA uses the GSR to put the chip in a defined state,
I'm not sure what Ken Chapman is really saying. If you use a global
set/reset signal in your design it will be replaced by the GSR signal,
so it is used by default whether or not you infer it.

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.

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

 

[rickman]

On 6/1/2016 2:08 AM, Sean Durkin wrote:

rickman wrote:
Since every Xilinx FPGA uses the GSR to put the chip in a defined state,
I'm not sure what Ken Chapman is really saying. If you use a global
set/reset signal in your design it will be replaced by the GSR signal,
so it is used by default whether or not you infer it.

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.

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.

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

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.

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

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

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.

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.

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:
https://forums.xilinx.com/t5/Archived-ISE-issues-Archived/FPGA-Power-On-Reset/m-p/7027?query.id=134602#M2035
(see Gabors answer)

--

Rick C

 

[Kim Enkovaara]

On 1.6.2016 16:04, rickman wrote:

On 6/1/2016 2:08 AM, Sean Durkin wrote:
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.

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.

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