Explicitly setting a variable to undefined

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello,
my question is probably best explained on a piece of code (the snippet is V
erilog, but the question should be mostly language-agnostic)

reg memory_access;
reg[1:0] memory_access_size;

always @ (posedge clk) begin
    if (clk_en && should_decode_input) begin
        memory_access_size <= 2'bxx;   // <---

        case(some_input_data)
        ACTION_1: begin
            memory_access <= 1;
            memory_access_size <= 2'b10;
        end
        ACTION_2: begin
            memory_access <= 1;
            memory_access_size <= 2'b01;
        end
        ACTION_3: begin
            memory_access <= 0;
        end
        endcase
    end
end

(the actual scenario is a Thumb instruction decoder)

My question is about the line marked with "// <---". If I understand the se
mantics correctly, including this line should make the compiler's job easie
r, by basically saying "unless I assign a new value to memory_access_size,  
do whatever with it". Thus, in the ACTION_3 case, it doesn't have to care a
bout preserving its previous value (which is no longer relevant), presumabl
y reducing the logic complexity.

I'm wondering whether this really is the case, in particular:
- Will this actually lead to more efficient logic realization with generall
y available (Altera, Xilinx) tools?
- Does this introduce any caveats to be aware of?
- Would you generally consider this a good coding practice?

Thanks in advance
-M

Re: Explicitly setting a variable to undefined
Quoted text here. Click to load it

I *AGGRESSIVELY* avoid introducing Xs, and work hard to eliminate ANY sources of  
X in my design.  Goggle search term "X-optimism", and "X-pessimism".
Any logic optimization's going to me TINY in the grand scheme of things.
The hazards waiting to bite you are not worth it.

I'd "eye" optimize it, by just assigning it to one of the other values
you've already assigned in the other qualifications.  It'll likely
come out darn near equivalent.

Regards,

Mark  



Re: Explicitly setting a variable to undefined
Dne st?eda 25. kv?tna 2016 20:16:39 UTC+2 Mark Curry napsal(a):
Quoted text here. Click to load it
s Verilog, but the question should be mostly language-agnostic)
Quoted text here. Click to load it
 semantics correctly, including this line should make the compiler's job ea
sier, by basically saying
Quoted text here. Click to load it
. Thus, in the ACTION_3 case, it doesn't have to care about preserving its  
previous value (which is no
Quoted text here. Click to load it
ally available (Altera, Xilinx) tools?
Quoted text here. Click to load it
rces of  
Quoted text here. Click to load it

Isn't that exactly the point, though? The variable at that point really bec
omes undefined - and if any other code assumes it to be defined, it is a bu
g. If the X ends up propagating where it shouldn't, it means there is somet
hing wrong with the logic.

I'll look into the terms you mentioned. They seem to be what I was looking  
for, but couldn't find.

Thank you,
M.

Re: Explicitly setting a variable to undefined
Quoted text here. Click to load it

There's finding bugs and creating the most optimal design.
The second goal is way behind the first, IMHO.  I'll not introduce
X's to get a more optimal design.  Ever.  

As a matter of fact I go extensively out of my way to avoid hidden bugs
at sometimes significant costs to Quality of Results.  

Xilinx likes to preach "Don't reset everything.  Reset should be the
exception not the rule."  My design style is exacty the opposite.
Reset everything (to avoid initialization Xs), with some exceptions.
I'm of the opinion that Xilinx is hopelessly wrong in this regard,
and is advocating wreckless guidance.  

As to finding bugs, your mileage may vary.  I avoid introducing X's.  I don't
think they buy me anything actually, and may hinder.  Read the papers -
there's a lot out there.  There's no easy answer.

Regards,

Mark


Re: Explicitly setting a variable to undefined
On Wednesday, May 25, 2016 at 9:46:51 PM UTC+3, Mark Curry wrote:
Quoted text here. Click to load it
:
Quoted text here. Click to load it
t is Verilog, but the question should be mostly language-agnostic)
Quoted text here. Click to load it
the semantics correctly, including this line should make the compiler's job
 easier, by basically saying
Quoted text here. Click to load it
it". Thus, in the ACTION_3 case, it doesn't have to care about preserving i
ts previous value (which is no
Quoted text here. Click to load it
nerally available (Altera, Xilinx) tools?
Quoted text here. Click to load it
sources of  
Quoted text here. Click to load it
s.
becomes undefined
 ends up
Quoted text here. Click to load it
he logic.
on't

They advise it for a reason. In big and complex designs big reset network w
ith high fanout dramatically decrease maximum achievable frequency. I follo
w that  for a long time and I've never had any problems as long as you rese
t properly that few signals which really need it. Usually it's some sort of
 Valid signal and the state of some FSMs.

Re: Explicitly setting a variable to undefined
On Wednesday, May 25, 2016 at 9:46:51 PM UTC+3, Mark Curry wrote:
Quoted text here. Click to load it

They advise it for a reason. In big and complex designs big reset network w
ith high fanout dramatically decrease maximum achievable frequency. I follo
w that  for a long time and I've never had any problems as long as you rese
t properly that few signals which really need it. Usually it's some sort of
 Valid signal and the state of some FSMs.

Re: Explicitly setting a variable to undefined
Dne sobota 28. kv?tna 2016 19:31:19 UTC+2 Ilya Kalistru napsal(a):
Quoted text here. Click to load it
 with high fanout dramatically decrease maximum achievable frequency. I fol
low that  for a long time and I've never had any problems as long as you re
set properly that few signals which really need it. Usually it's some sort  
of Valid signal and the state of some FSMs.

Can't this be solved by a pipelined reset?
With each step you could increase the fan-out significantly.

Re: Explicitly setting a variable to undefined
On 5/28/2016 3:49 PM, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

The issue with a large reset is not on the leading edge, it is on the  
trailing edge or exit from reset.  That can be mitigated by careful  
design so the logic does not care about the exact timing of the reset  
release.  In other words, design your circuits as if the reset signal  
were asynchronous.

Often separate circuits do not need to come out of reset synchronously.  
The circuits will however need to have multiple FFs synchronized.  This  
can be done by including one FF to provide a synchronized reset to that  
circuit.  In other cases it can be done by making sure the exit from the  
reset state only affects one FF in your circuit.  As long as the  
circuits do not require a synchronous release from reset, the problem is  
much simpler to handle.

--  

Rick C

Re: Explicitly setting a variable to undefined

Quoted text here. Click to load it

We could come up with a bunch of ideas how to solve this problem in different situations but it's much wiser just not to create the problem if you can.

Re: Explicitly setting a variable to undefined
Quoted text here. Click to load it

Which is *precisely* why I reset almost everything.

The argument is that "resets" are expensive may be true.  Reset trees
are expensive, and may be overkill.  But first-pass success, and not
having latent (and hard to find bugs) trumps this for me.  Reset
and initialization problems can be the devil to find and debug.  

I'd rather have a correct design first, rather than an optimal one.
(Maybe my industry can tolerate this more).

I just think Xilinx emphasizes the "don't reset everything" way too
much - and actually doesn't spend much effort on the other side trying
to create a  better/more efficient reset mechanisms in their technology and
software.  They think it's a training problem not a technology one.

Regards,

Mark


Re: Explicitly setting a variable to undefined
Ilya Kalistru wrote:
Quoted text here. Click to load it

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

Re: Explicitly setting a variable to undefined
On 5/31/2016 8:09 AM, Sean Durkin wrote:
Quoted text here. Click to load it

I don't believe Xilinx or any other FPGA vendor makes that claim.  
First, the reset from configuration is done via the global set/reset  
signal (GSR) which covers the entire chip like the clock signals, but  
without the drive tree.  The problem with this is the relatively weak  
drive which results in a slow propagation time.  So there is no  
guarantee that it will meet setup/hold times on any given FF when coming  
*out* of reset.  The result is you must treat this signal as  
asynchronous to the clocks in the chip and each section of clocked logic  
should be designed accordingly.  The good part is that it does not use  
any of the conventional routing resources and so is otherwise "free".

It doesn't matter of a device is being set or reset by the GSR.  The  
programmable inverter is in the FF logic and so is also "free".

--  

Rick C

Re: Explicitly setting a variable to undefined
On Tue, 31 May 2016 08:53:27 -0400, rickman wrote:

Quoted text here. Click to load it


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"


Allan

Re: Explicitly setting a variable to undefined
On 5/31/2016 9:31 AM, Allan Herriman wrote:
Quoted text here. Click to load it

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

Re: Explicitly setting a variable to undefined
Den tirsdag den 31. maj 2016 kl. 15.45.47 UTC+2 skrev rickman:
Quoted text here. Click to load it

should be easy to handle by using a BUFGCE and an SRL16  
to keep the clock stopped until 16 cycles after reset

-Lasse

Re: Explicitly setting a variable to undefined
Quoted text here. Click to load 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


Re: Explicitly setting a variable to undefined
On 5/31/2016 1:58 PM, Mark Curry wrote:
Quoted text here. Click to load it

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.


Quoted text here. Click to load it


--  

Rick C

Re: Explicitly setting a variable to undefined
On Tue, 31 May 2016 09:45:42 -0400, rickman wrote:

Quoted text here. Click to load it

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.

Quoted text here. Click to load 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

Re: Explicitly setting a variable to undefined
rickman wrote:
Quoted text here. Click to load 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.id13%4602#M2035
(see Gabors answer)

Re: Explicitly setting a variable to undefined
On 6/1/2016 2:08 AM, Sean Durkin wrote:
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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


Quoted text here. Click to load it

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.


Quoted text here. Click to load it


--  

Rick C

Site Timeline