Hi Itsik. As explained in the article, using the unique keyword can change the behaviour of a design. I have personally seen a bug in a manufactured ASIC, because the designer used the unique keyword in their code without knowing fully what it meant. Like any syntax, it can be used correctly to improve the design, or used incorrectly and break the design. I believe the coding guideline at my office currently discourages using the unique and priority keywords because they are prone to misunderstanding.

Thanks for the interesting article.

Are there any reasons for not using the Unique keyword ?

Any possible pitfalls of using the Unique keyword ?

Regards,

Itsik

Hi Darshan. You’re correct, the simulator should throw a warning/error when one of the inputs become X, whether that is after reset, or during reset.

At time 0, there is actually not a problem if “in” and “en” are assigned proper values inside an initial block or an always block (e.g. if they are reset to non-X values at time 0). The SV LRM states always_comb “…is automatically triggered once at time zero, after all initial and always procedures have been started so that the outputs of the procedure are consistent with the inputs”. So the warning at time 0 can be avoided as long as proper values are assigned.

If “in” and “en” are not assigned proper values at time 0, then yes you will get a warning/error from the unique case statement (at time 0 due to evaluation of always_comb). In this case I don’t think you can avoid the warning/error… Perhaps you can filter out the warning/error message at time 0 or during reset in your log? You should only get 1 warning/error message every time “in” or “en” changes (each evaluation of the always_comb).

I love your articles.

I have a question about how unique and priority run-time (simulation) checks work before reset is released. Suppose I have a case statement that isn’t fully specified:

wire [1:0] in;
wire en;
logic Y;

always_comb
begin
unique case({in[1:0], en})
3’b010: Y = 1;
3’b101: Y = 0;
endcase
end

Since case statement above does not specify what should happen if one of the inputs to it should go to X, I expect the simulator to throw an error if an input is X.

But I’m only interested in such errors (inputs going to X) after reset is released, since I know that several inputs will be X before reset is released.

How should one manage this or how does unique or priority checks know not to check this (before reset release) and also at time 0 (since always_comb runs at time zero when input variables could be initialized to X)?

Hi Yuchao. You’re right! I was thinking and writing about “unique casez”, but drew a diagram of of just “casez”. I think it’s best if I just removed that diagram. Thanks for catching the error!

Thanks for posting a great article on SV “unique”/”priority”.

One question I have is, in your first unique case example here, you drew the resulted synthesized logic as the same as a priority decoder logic (shown in previous post for priority decoder). So this “unique” semantic doesn’t generate a parallel logic then? or I’m missing some points?

Thanks,
Yuchao