Re: [sv-bc] Case Statement Enhancement Proposal Idea

Clifford E. Cummings wrote:

>> > Shalom correctly points out that when the default assignment is
>> > placed in front of the unique case, even with an empty default,
>> > multiple tools isolate the unique case to the case statement and
>> > throw away the preceding assignment and thus generate incorrect
>> > results.
>>
>> Do you really mean incorrect logic, or are you saying that
>> they don't find the best optimizations?
> 
> I do mean incorrect logic. If you remove the null-default (which would
> be a warning using unique) or replace the null-default with an output
> assignment of all X's (helps trap X's in the simulation and treated as
> don't-cares by synthesis tools) you will find that the enable input is
> optimized away. I use this example in a lab to show why full_case is so
> dangerous. This fails the same way with all synthesis tools that I have
> ever used (I have used this example in synthesis training for almost 12
> years to show the follies of full_case).

Cliff,

   You make a good point, but have fingered the wrong villain.
The tools are not synthesizing incorrect logic.  Back when "full case"
was a directive inside a comment, arguably the comment was authorizing
a violation of case statement's behavioral semantics.

"UNIQUE CASE" is a first-class language construct, differently defined:
it has "full case" semantics, and a requirement to warn when static
circumstances show that it is a non-trivial use of those semantics.

If you remove the null-default (of a unique), or fill a default
with output assignments of all X's, you intend to reach at least
one of those branches.  They all write to the output lines with
no further consideration given to the enable line.  So, finding
"that the enable input is optimized away" is a Good Thing.  It
means that your tool understood the LRM accurately and "made hay"
with the extra information you encoded into that "unique" keyword.

Of course, if the logic is still "wrong" there is only the
designer to blame for specifying the wrong RTL.   As you admit,
the designer had to physically add the assignments to X in order
to lose the enable logic with no warning whatsoever.
Since those assignments kill the default values, it's hard
to argue that the designer intended them to preserve exactly
those values.

If one teaches RTL as a compounding of "coding styles" - regarded
only as idiomatic, magical incantations - it is like teaching the
now-discredited "whole language" method of reading.
It turns out that behavioral semantics has the equivalent of a
"phonics", which can account for how any coded idiom actually works.
The moral of your lab lesson is that this scientific model
for capturing design intent won out over tool-specific intonations.
The SV language is powerful enough for the designer to hang himself,
but thanks to the required warnings, this seldom happens silently
anymore.

Greg Jaxon


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.