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

Actually, Cliff's proposal is not specific to unique and/or priority. It
would work well with other case statements as well.

What it does do is localize all the assignments to the output variables
within a single statement, the case. I have often had trouble with tools
that treated the case statement separately from the statements that
preceded it.

And although the examples discussed indeed were not real unique ones,
there are plenty of real-life examples of unique cases which still
benefit from the pre-assignments. But as I said, the proposal is not
closely tied to unique and priority. It only needs to define their
behavior in its presence.

Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On Behalf Of Jonathan Bromley
> Sent: Sunday, July 08, 2007 11:29 AM
> To: sv-bc@server.eda.org
> Subject: RE: [sv-bc] Case Statement Enhancement Proposal Idea
> 
> > IMHO, it appears you may have missed the point of the request.
> 
> I respectfully submit that I haven't... and I suspect
> Arturo was gently and justifiably poking fun at my
> let's-design-a-decoder-competition.
> 
> > The general code case is like this:
> [set defaults on a bunch of signals and then, in
> various branches of a possibly incomplete case
> statement, adjust various subsets of those signals]
> 
> In your/Cliff's examples, the case statement is
> neither 'unique' nor 'priority' because it is both
> possible and reasonable for no branch to be taken.
> As others have pointed out, synthesis optimizations
> can be encouraged - whilst retaining sane semantics -
> simply by adding an empty default branch to the
> unique case.
> 
> With hindsight, it might have been preferable to make
> 'unique' assert "at most one branch" rather than
> "exactly one branch".  The present effect of 'unique'
> could then be had by applying BOTH modifiers.  But now
> we are stuck with it, and we can get "at most one branch"
> easily by using unique and an empty default.  We don't
> need new syntax for something that many designers have
> been comfortably doing for years anyway.

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