Subject: Re: [sv-bc] Re: SV31A LRM interpretation for: unique case
From: Greg Jaxon (Greg.Jaxon@synopsys.com)
Date: Sun Feb 22 2004 - 20:14:48 PST
The intent is that when static analysis cannot decide, runtime checks
will be inserted. Whether these signal an error, or warn and then simulate
"something" is apparently in flux.
Shalom.Bresticker@motorola.com wrote:
> Thanks.
>
> I did say that I would probably have more comments after getting answers...
>
> I believe that the wording for the "if" and "case" should be almost identical,
> differing only where required by the differences between "if" and "case".
> Differing wording invites the reader to ask himself why you used different
> wording, it must be because there is a difference.
>
> Here you have changed the errors to warnings, which I believe is the correct thing to do,
> but for "if", it still says "error".
>
> Note that often a static check is unable to determine absolutely whether a certain
> condition can occur or not, especially when it depends on the possible input combinations.
> In that case, it warns, saying that as far as it is concerned, the condition is
> "possible", but in fact, it may that the condition may not actually be possible in practice.
>
> Thanks,
> Shalom
>
>
> On Fri, 20 Feb 2004, Dave Rich wrote:
>
>
>>
>>In Verilog, there are three types of case statements, introduced by case, casez and casex. With SystemVerilog, each of these can
>>be qualified by priority or unique. A priority case shall act on the first match only. A unique case shall check for
>>overlapping case items, allowing the case items to be evaluated in parallel. A unique case shall issue an warning message
>>if more than one case item matches the case expression. If the case is qualified as priority or unique, the simulator shall issue
>>an warning message if no case value item matches. These warnings can be issued at either compile time
>>or run time, as soon as it is possible to determine the illegal condition.
>>
>>Shalom.Bresticker@motorola.com wrote:
>>
>>I still have some problems with the wording.
>>
>>The LRM says,
>>"A unique case shall guarantee no overlapping case values".
>>(Read "items" for "values".)
>>
>>This is incorrect. It does not "guarantee" anything.
>>It does not go and change the code I have typed in.
>>At most, it checks whether there are overlaps and warns me about it.
>>
>>
>>Right.
>>
>>
>>Second, the wording for "unique if" is,
>>"A software tool shall issue an error if it determines that more than one
>>condition is, or can be, true. A software tool shall also issue an error
>>if it determines that no condition is true, or it is possible that no
>>condition is true, and the final if does not have a corresponding else."
>>
>>This wording implies that the check is a static one, performed at
>>compilation time, whereas the discussion in the last mails about
>>'unique case' talks about run-time errors.
>>
>>
>>Yes, they can be checked statically, if the tool can do it, but not required. Note that your linting tool is being conservative. A
>>static check for simulation means that there would be an error each time the statement executed. A formal tool would check for an
>>error over all the possible legal inputs..
>>
>>
>>Third, regarding "overlapping case items":
>>In the given example,
>>
>>unique casex (value)
>> 'b111x, `b11x1: $display( "case item 1 executed" ); //1st case item - has multiple true case expressions
>> 'b1101: $display( "case item 2 executed" ); //2nd case item - has no true case expression
>>endcase
>>
>>in actual fact, the case items DO overlap. 'b11x1 overlaps 'b1101.
>>'b11x1 is a superset of 'b1101. This has nothing to do with the whether or
>>not the value 'b1101 actually occurs during simulation. If you give this
>>to a lint tool, it WILL tell you that the case items overlap.
>>
>>
>>
>>Changed to say that multiple case items must match the case expression.
>>
>>
>>Finally, the LRM also says,
>>"If the case is qualified as priority or unique, the simulator shall issue
>>an error message if an unexpected case value is found."
>>
>>The word "unexpected" is out-of-place.
>>The simulator has no idea what is expected or unexpected,
>>only whether values are specified or not, or fulfill one or more of the
>>case items or not.
>>
>>An unspecified value can be expected, and a specified value can be
>>unexpected.
>>
>>
>>Changed to say that no items match
>>
>>
>>I suspect that after getting answers to these questions,
>>I will have further problems with the current or corrected language.
>>
>>
>>
>>
>>
>>
>
>
This archive was generated by hypermail 2b28 : Sun Feb 22 2004 - 20:21:50 PST