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

Hi, All -

BTW - I did not mean to touch off the best decoder contest :-) I 
actually knew about all of the decoder styles shown and we even 
compare many of them in the first synthesis labs that we run (for 
coding and synthesis efficiency comparisons). The only coding style 
that I did not know was the en << a style and as Shalom points out, 
en is only one bit so you lose the information rather quickly when 
shifting (you would have to throw in a concatentation with leading zeros).

Adam and Shalom have both actually captured my intent. Adam's rewrite 
of my example is something I point out in class, that decoder outputs 
often have different names; otherwise, we could do all the other 
clever coding styles. Making the default assignment  to all outputs 
and coming back with an update assignment is simple to code and often 
among (or amongst) the most efficient when synthesized.

Jonathan proposes that unique case should have been an at-most-one 
match, but I'm not sure I agree because then we miss the fullcase 
testing portion of unique case, which is occasionally useful.

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. This is the problem I am trying to address. I can already 
make default assignments before the case statement and make updates 
within the case statement for simulation, but too many tools are 
ignoring the pre-assigned values while performing tool operations on 
the isolated case statement and now priority and unique complain that 
I did not execute any case-assignment code (Jonathan's at-most-once 
would have helped here).

Shalom also correctly points out that if you are making assignments 
to multiple outputs but forget to assign to one of the outputs in the 
initial assignment (either default assignment before the case 
statement or in the proposed case-initial statement) and do not 
assign to that variable in all other case items, you will get a 
latch. As a side-note, if I use always_comb I want synthesis tools to 
catch this and flag it as an error, but unfortunately, there is one 
large synthesis tool vendor that currently only gives me warnings 
(gee whiz! I already had warnings about latches with always blocks 
... give me an error and abort the compilation if I requested comb 
but generated latches - the easy work-around if I don't like errors 
is to go back to always blocks!)

Just to be clear on my proposal, for unique case with case-initial:
(1) unique case should not perform fullcase testing (because the 
case-initial code will be executed)
(2) unique case should still perform uniqueness test on all of the 
case items ignoring the face that the case-initial will also be 
executed - at-most-once testing on the case items.

The case-initial statement really is a simple, elegant and useful 
enhancement that will receive widespread adoption by RTL coders.

Regards - Cliff

At 06:30 AM 7/8/2007, Bresticker, Shalom wrote:
>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.

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training


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