Verilog problem: default case to set signal xxxx

[Davy]

Hi all,

I always found people like to add default branch like below:
case(branch)
... ...
[all the possible branch]
... ...
default: signal = 8'bx;

And my friend told me it's for simulation cause. When branch not hit
all the possible case, the branch must have something like xxxx. So we
set signal to xxxx to let xxxx pass go on and help us to find the bug.

If I set default: signal = 0; the xxxx problem will be hidden and hard
to find the bug.

But as we know, there is no xxxx signal in real digital world. So is
there any better method to solve the problem?

Best regards,
Davy

 

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Davy wrote:

Hi all,

I always found people like to add default branch like below:
case(branch)
... ...
[all the possible branch]
... ...
default: signal = 8'bx;

And my friend told me it's for simulation cause. When branch not hit
all the possible case, the branch must have something like xxxx. So we
set signal to xxxx to let xxxx pass go on and help us to find the bug.

Your friend talks sense.

If I set default: signal = 0; the xxxx problem will be hidden and hard
to find the bug.

Yes.

But as we know, there is no xxxx signal in real digital world. So is
there any better method to solve the problem?

That es exactly the point. If your simulation starts showing
xxx values for signals, that should be a clue that your design
has a problem that should be fixed even before you try to synthesize
it. That xxxx does not show up in real logic is exactly the point!
It's saying "Hey look here! Something happened that you don't
want in your real hardware!"

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFZyYrrPt1Sc2b3ikRAvqUAKCm4njVxE4S8R2godBfpwIyCfui+ACeJyQY
o7U37cy4P+PUIbDWQvIkgKo=
=9sa1
-----END PGP SIGNATURE-----

 

[Jon Beniston]

Davy wrote:

Hi all,

I always found people like to add default branch like below:
case(branch)
... ...
[all the possible branch]
... ...
default: signal = 8'bx;

And my friend told me it's for simulation cause. When branch not hit
all the possible case, the branch must have something like xxxx. So we
set signal to xxxx to let xxxx pass go on and help us to find the bug.

If I set default: signal = 0; the xxxx problem will be hidden and hard
to find the bug.

But as we know, there is no xxxx signal in real digital world. So is
there any better method to solve the problem?

What is the problem with this? It does not matter that this doesn't
correspond to a real world value. The synthesis tool will see that it
is a don't care, and hopefully should optimise the logic accordingly,
giving you the smallest / fastest circuit.

Cheers,
Jon

 

[Petter Gustad]

"Davy" <zhushenli@gmail.com> writes:

But as we know, there is no xxxx signal in real digital world. So is
there any better method to solve the problem?

Maybe:

case(branch)
... ...
[all the possible branch]
... ...
// synthesis translate_off
default: signal = 8'bx;
// synthesis translate_on
endcase

I wish simulators could have a switch or similar to make sure that if
you had something like:

somesel = 1'bx;

if (somesel)
somevar = something;
else
someelsevar = somethingelse;

would case ALL assigned vars in BOTH if branches to become x. Same
thing for the ? operator. Of course one can write the above as if
statement as case(somesel).


Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Alex]

Davy wrote:

Hi all,

I always found people like to add default branch like below:
case(branch)
... ...
[all the possible branch]
... ...
default: signal = 8'bx;

And my friend told me it's for simulation cause. When branch not hit
all the possible case, the branch must have something like xxxx. So we
set signal to xxxx to let xxxx pass go on and help us to find the bug.

If I set default: signal = 0; the xxxx problem will be hidden and hard
to find the bug.

But as we know, there is no xxxx signal in real digital world. So is
there any better method to solve the problem?

Best regards,
Davy

In addition to "xxxxx" there may be some other choices.
1. (simulation debug) Use $display instead of signal assignment, for
example:

default: $display ($time,"<%m> ERROR: non-speicified branch is
taken");

Synthesis tools drop all $display statements, while simulators report
about an error in a runtime. It eliminates the need to observe "x" on
selected signals in the waveform viewer. Also, in some cases "x" may
propagate to "signal" from the previos logic (such as unitialized
memory arrays). Use of "$display" will isolate bugs better.

2. (emulation debug) Create observable error status register, associate
each one of register's bit with different "case" statements and set
them to "1" when corresponding default branch is taken:

default: uncomplete_case_reg[0] <= 1'b1;

Finally, some synthesis tools (such as Synopsys DC) produce warnings
for case statements in which not all possible cases are covered. To get
this reporting, you have to use pragma "// synopsys full case" with the
case statement.

Regards,
-Alex

 

Petter Gustad wrote:

I wish simulators could have a switch or similar to make sure that if
you had something like:
....
would case ALL assigned vars in BOTH if branches to become x. Same
thing for the ? operator.

The ?: operator does that already. In fact, it is significantly
smarter than that. If the condition is x, it only produces an x at the
outputs for bits that don't match between the two selected values.
That keeps the result from being overly pessimistic.

This cannot be generalized to if-statements, because you can do
arbitrarily complex things in an if-statement, not just assign to
variables. How do you maybe-display something? How do you maybe-call
a task? How do you maybe-disable a block? How do you maybe-execute
more nested conditionals that would only assign to some variables but
not others? If you assume the worst, the result could be far too
pessimistic.

It could be so pessimistic that you cannot make any progress in
simulation. If an outer condition is X, but a nested condition is
false, you would be Xing out a variable that could not actually have
been assigned. Or the design might only assign to some bits of a vector
or array, but you end up Xing out the whole thing because it was
potentially assigned. It might be impossible to simulate your design
being initialized. You could waste a lot of time tracking down
problems that turned out not to be real problems on closer examination,
eventually giving up and turning off this special switch.

The over-optimism of Verilog if-statements with X conditions is a
problem in the language, but I don't think that this frequently heard
suggestion would provide a viable solution.

Another possible approach would be to add an optional elsex to the
if-statement syntax, to allow the user to specify the behavior to take
on an X (similar to using a default in a case). Then the user could
use their better understanding of the situation to decide what to do,
and avoid over-pessimism.. The problem with this is that it is not
automatic. The user has to remember to do it for each if-statement,
and correctly figure out what result they want.

Note that switching if-statements containing assignments into
assignment statements containing ?: where possible would give better
results, but at the cost of making the code harder to read.

I have yet to hear a good solution to this if-statement problem, which
is probably why it works the way it does, even though it is flawed.

 

[Jon Beniston]

In addition to "xxxxx" there may be some other choices.
1. (simulation debug) Use $display instead of signal assignment, for
example:

default: $display ($time,"<%m> ERROR: non-speicified branch is
taken");

Synthesis tools drop all $display statements, while simulators report
about an error in a runtime. It eliminates the need to observe "x" on
selected signals in the waveform viewer. Also, in some cases "x" may
propagate to "signal" from the previos logic (such as unitialized
memory arrays). Use of "$display" will isolate bugs better.

This sort of thing can end up with lots of false positives though, that
can obscure the real bugs. (i.e. you'll get lots of these printed
before reset, etc)

Cheers,
Jon

 

[Utku Özcan]

I agree with Jon. Most of the comments in this thread are related to
simulation, but finally we design the circuits with HDL languages to
synthesize them. Setting x to the default case also lets the synthesis
tool produce faster/smaller circuits, because the synthesis tool has in
that case the freedom to optimize the circuit according to internal
optimization algorithms.

It also can make the design more robust, because the verification
engineer will try to remedy the case and thus design bugs can be
localised better (probably at the expense of time to debug, which is
worth having it).

Utku.

Jon Beniston schrieb:

Davy wrote:
Hi all,

I always found people like to add default branch like below:
case(branch)
... ...
[all the possible branch]
... ...
default: signal = 8'bx;

And my friend told me it's for simulation cause. When branch not hit
all the possible case, the branch must have something like xxxx. So we
set signal to xxxx to let xxxx pass go on and help us to find the bug.

If I set default: signal = 0; the xxxx problem will be hidden and hard
to find the bug.

But as we know, there is no xxxx signal in real digital world. So is
there any better method to solve the problem?

What is the problem with this? It does not matter that this doesn't
correspond to a real world value. The synthesis tool will see that it
is a don't care, and hopefully should optimise the logic accordingly,
giving you the smallest / fastest circuit.

Cheers,
Jon

 

[Rob Dekker]

"Petter Gustad" <newsmailcomp6@gustad.com> wrote in message news:7dr6vsptly.fsf@www.gratismegler.no...

"Davy" <zhushenli@gmail.com> writes:

But as we know, there is no xxxx signal in real digital world. So is
there any better method to solve the problem?

Maybe:

case(branch)
... ...
[all the possible branch]
... ...
// synthesis translate_off
default: signal = 8'bx;
// synthesis translate_on
endcase

This (the synthesis pragma's) is a very, very bad idea.

Synthesis tools will not see the x assignment, so they will have to hold the value of 'signal' under the default condition.
That can lead to spurious latches, or at least to excess logic...
The x assignments are very important to synthesis tools, since then they know that in that state, the value of 'signal'
is not important (don't care). Then they can use that to minimize the logic needed to implement the values that ARE important.

So, x-assignments are good for simulation (so you can see when your design is in an invalid state), AND
they are good for synthesis, because synthesis tools now know that that state is irrelevant (and can thus minimize they logic
accordingly).

Rob

 

[Petter Gustad]

"Rob Dekker" <rob@verific.com> writes:

This (the synthesis pragma's) is a very, very bad idea.

It depends on your synthesis tool. Some older tools (I think it might
have been older versions of DC) would give an error when it observed
x's in the code. If all your target synthesis tool interpretate x's as
don't care then it's fine to use it.

Synthesis tools will not see the x assignment, so they will have to
hold the value of 'signal' under the default condition.

There are pragmas to like "full_case" and "parallel_case" to control
the logic generation of case statements for many synthesis tools.


Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Petter Gustad]

sharp@cadence.com writes:

The ?: operator does that already. In fact, it is significantly

That's true.

This cannot be generalized to if-statements, because you can do
arbitrarily complex things in an if-statement, not just assign to
variables. How do you maybe-display something? How do you maybe-call

I did not mean to execute all statements in both branches. The
behavior would be the same as it is today, except that it would
propagate x's for assigned variables in both branches.


Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Davy]

Hi all,

Thanks a lot for all the comments!

I always think is there any methodology to find the first meanful
"xxxx".
And I conclude the methods recommended in previous posts. Please add
the list if I miss the idea you write or you think there are some
methods else, thanks!

By tool feature:
I don't know the feature.

Or by language feature:
[1] default: signal = 8b'x; (maybe adopted by most people)
[2] default: $display Error; (Alex)
[2] default: set a debug register; (Alex)
[4] elsex: do something; (Sharp)

Best regards,
Davy

sharp@cadence.com wrote:

Petter Gustad wrote:

I wish simulators could have a switch or similar to make sure that if
you had something like:
...
would case ALL assigned vars in BOTH if branches to become x. Same
thing for the ? operator.

The ?: operator does that already. In fact, it is significantly
smarter than that. If the condition is x, it only produces an x at the
outputs for bits that don't match between the two selected values.
That keeps the result from being overly pessimistic.

This cannot be generalized to if-statements, because you can do
arbitrarily complex things in an if-statement, not just assign to
variables. How do you maybe-display something? How do you maybe-call
a task? How do you maybe-disable a block? How do you maybe-execute
more nested conditionals that would only assign to some variables but
not others? If you assume the worst, the result could be far too
pessimistic.

It could be so pessimistic that you cannot make any progress in
simulation. If an outer condition is X, but a nested condition is
false, you would be Xing out a variable that could not actually have
been assigned. Or the design might only assign to some bits of a vector
or array, but you end up Xing out the whole thing because it was
potentially assigned. It might be impossible to simulate your design
being initialized. You could waste a lot of time tracking down
problems that turned out not to be real problems on closer examination,
eventually giving up and turning off this special switch.

The over-optimism of Verilog if-statements with X conditions is a
problem in the language, but I don't think that this frequently heard
suggestion would provide a viable solution.

Another possible approach would be to add an optional elsex to the
if-statement syntax, to allow the user to specify the behavior to take
on an X (similar to using a default in a case). Then the user could
use their better understanding of the situation to decide what to do,
and avoid over-pessimism.. The problem with this is that it is not
automatic. The user has to remember to do it for each if-statement,
and correctly figure out what result they want.

Note that switching if-statements containing assignments into
assignment statements containing ?: where possible would give better
results, but at the cost of making the code harder to read.

I have yet to hear a good solution to this if-statement problem, which
is probably why it works the way it does, even though it is flawed.