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

Brad,

Mantis 1345 is open on the use of 'illegal' there.

I also strongly disagree with the statement that

> Likewise [the user "deserves whatever happens to him"] if the
> user has not invested in sufficient functional coverage to discover
> such a test vector.

Verification engineers know that reaching these conditions is often one
of the hardest tasks there is. To say that it is 'non-trivial' is often
an extreme understatement.

Regardless, simulation-synthesis mismatches can occur because synthesis
tools translate 'unique' and 'priority' into full_case and parallel_case
synthesis directives that allow them to perform various logic
optimizations. Those optimizations include, for example, treating an
output as don't care in certain cases where the user has not specified a
value. The synthesis tool will assign the output whatever value it finds
convenient, whereas the simulator will simply do nothing, i.e., preserve
the old value, because the user did not specify a value.

Or think of the case where the user explicitly coded an x value. The
synthesis tool will treat it as a 2-value don't care, assigning either 0
or 1, as convenient, whereas the simulator will put a real 1'bx there.

Both tools are performing correctly, as defined. But because the
simulation and synthesis semantics are not identical, the results are
not either. Both tools are correct, but the synthesis tool is doing what
the coder wrote, but not what he intended.

In an ideal world, the coder would understand perfectly what the
synthesis tool will do with his code and would always understand
correctly whether it is ok or not.

But in the real world, coders are human beings and sometimes make
mistakes. This is one area where mistakes too frequently occur. Cliff's
goal (and I agree with him on this one) is to slightly modify the
language so as to allow a convenient coding style which could
significantly reduce the frequency of this type of mistake.

Regards,
Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On Behalf Of Brad Pierce
> Sent: Tuesday, July 10, 2007 5:28 PM
> To: sv-bc@server.eda.org
> Subject: 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.

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