Verilog problem: default case to set signal xxxx

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

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

In addition to "xxxxx" there may be some other choices.

1. (simulation debug) Use $display instead of signal assignment, for example:

default: $display ($time," 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.

1. (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]

...

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.

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

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:

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

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.

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

Petter

That's true.

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

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

snipped-for-privacy@cadence.com wrote: