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.