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

Shalom,

>Cliff is pointing out, I believe, that you can still get a
simulation-synthesis
>mismatch. This effectively means that the simulation semantics are
different
>from the synthesis semantics.

The LRM says that if a puported 'unique' case statement will be
presented with test vectors that violate uniqueness, then the case
statement is ILLEGAL.

  "A unique case shall be illegal if, for any such interleaving of
evaluations and comparisons, more than one case item matches the case
expression.  For an illegal unique case, an implementation shall be
required to issue a warning message, unless it can demonstrate a legal
interleaving of evaluations and comparisons so that no more than one
case item matches the case expression."

If a simulator is disobeying the standard by failing to issue a warning
message when encountering a test vector that makes a unique case
statement illegal, then please file a bug report against the simulator.
It does not constitute a "simulator-synthesis" mismatch for a synthesis
tool to assume that simulators obey the standard.

If a simulator is obeying the standard and is reporting that the unique
case statement is illegal for some test vector, yet the user is
synthesizing the illegal code anyway despite the simulator warning,
then, yes, the user "deserves whatever happens to him".  Likewise if the
user has not invested in sufficient functional coverage to discover such
a test vector.

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Tuesday, July 10, 2007 4:18 AM
To: Greg Jaxon; Clifford E. Cummings
Cc: sv-bc@eda.org
Subject: RE: [sv-bc] Case Statement Enhancement Proposal Idea

Greg,

I respectfully disagree with a lot of what you say.

First, the standard defines only the simulation semantics of 'unique
case'. It says nothing about synthesis semantics. 

Cliff is pointing out, I believe, that you can still get a
simulation-synthesis mismatch. This effectively means that the
simulation semantics are different from the synthesis semantics.

More importantly, it is a critical error to ignore the fact that we are
human beings and sometimes make errors when we write code. It is wrong
to say that we will define whatever we want and if a coder makes an
error, he deserves whatever happens to him.

The purpose of this language is to serve its users. One of the biggest
considerations should always be the best interest of the user.
Occasionally, other interests make take precedence (such as difficultly
of implementation), but the user interest should never be ignored.

Regards,
Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On Behalf Of Greg Jaxon
> Sent: Monday, July 09, 2007 8:16 PM
> To: Clifford E. Cummings
> Cc: sv-bc@server.eda.org
> Subject: 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.



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