Re: [Iverilog-devel] Priority case and default case items.

[Bryan M. <bmu...@gm...>]

The paper I linked to explains that the synthesis tools don't necessarily
evaluate the various cases in the given order, *unless* you use the
priority modifier.  This can matter if foo (in your example) is able to
match multiple cases.

The paper also says that the simulator should issue a runtime warning if in
your Example #4 foo evaluates to something other than 1 or 2.  Personally,
making this only a warning is...stupid (yet strangely consistent with other
less helpful parts of SV :-/).  It really should just be an error.

Bryan

On Wed, Oct 9, 2019 at 8:14 PM Stephen Williams <st...@ic...> wrote:

> Fair point, although the "default:" also has meaning to the synthesizer
> and may render the priority keyword moot in synthesis too. For example:
>
> // Example #1
> case (foo)
> 1: bar = a;
> 2: bar = b;
> default: bar = x;
> endcase
>
> and
>
> // Example #2
> priority case (foo)
> 1: bar = a;
> 2: bar = b;
> default: bar = x;
> endcase
>
> are indistinguishable to a simulator AND to a synthesizer, but:
>
> // Example #3
> case (foo)
> 1: bar = a;
> 2: bar = b;
> endcase
>
> is very different (it is a latch) from:
>
> // Example #4
> priority case (foo)
> 1: bar = a;
> 2: bar = b;
> endcase
>
> which is a combinational mux. Furthermore, #4 is not necessarily the same
> as #1 or #2. If #4 is what is desired, then #2 is probably not a way to
> achieve it, although #1 is the best approximation available without the
> priority keyword. Thus, I suggest that #2 may deserve a gentle warning at
> compile time (but not at run time.)
>
> On Wed, Oct 9, 2019 at 5:54 PM Bryan Murdock <bmu...@gm...> wrote:
>
>> This paper has a lot of explanation about priority (and unique):
>>
>>
>> http://www.sutherland-hdl.com/papers/2005-SNUG-paper_SystemVerilog_unique_and_priority.pdf
>>
>> My quick summary is that they are directives meant mostly for synthesis
>> tools.  If someone provides a default case in their priority case, yes,
>> they are making the priority statement redundant in the simulation, but it
>> might still be a very important directive for synthesis.  So don't nag them
>> about it with a warning 🙂
>>
>> Bryan
>>
>>
>> On Wed, Oct 9, 2019, 10:39 AM Stephen Williams <st...@ic...> wrote:
>>
>>> Here's a question. There is this:
>>>
>>> priority case (foo)
>>>  1: stmt1;
>>>  2: stmt2;
>>>  default: stmt_default;
>>> endcase
>>>
>>> The priority case "shall issue a violation report if no case_item
>>> matches."
>>>
>>> The default: statement makes it so that every possible value of foo
>>> has a case item, if the "default" case is considered a case item, and
>>> by the BNF, it is indeed a case_item. But the "default:" makes the
>>> "priority" moot. So should this print a violation message or not?
>>>
>>> (I'm thinking, it should not, but a compile time warning may make
>>> sense. But I can see logic for the other course too.)
>>>
>>> --
>>> Steve Williams                "The woods are lovely, dark and deep.
>>> st...@ic...              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."
>>>
>>>
>>> _______________________________________________
>>> Iverilog-devel mailing list
>>> Ive...@li...
>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>>
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>
>
> --
> Steve Williams                "The woods are lovely, dark and deep.
> st...@ic... <ste...@gm...>              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."
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>