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

> (1) It looks pretty silly to add an empty default to a case 
> statement. I like the following code better:
> 
> always_comb begin
>    unique case ({en,a})
>      initial y = '0; // pre-default assignment
>      3'b100: y[a]='1; // updates
>      3'b101: y[a]='1;
>      3'b110: y[a]='1;
>      3'b111: y[a]='1;
>    endcase
> end

Interesting.  I'm sure Cliff has a specific reason for
the chosen coding style, but I find it pretty opaque.
What's wrong with:

 always_comb begin
   y = '0;
   unique case (a)
     2'b00, 2'b01, 2'b10, 2'b11: y[a] = en;
   endcase
 end

or even (far clearer, to me):

  always_comb begin
    assert (!$isunknown({a, en}));
    y = '0;
    y[a] = en;
  end

"unique" is, for all practical purposes, an assertion
that exactly one branch of the conditional can be taken.
Synthesis tools are free to exploit that assertion to
do certain optimizations.  So far, so good. 

However, "unique" is NOT a silver bullet to create
optimal logic whilst assuring freedom from latches.
(Designers occasionally think of "parallel_case" as
just such a silver bullet, and Cliff has done a fine
job of setting their understanding straight!)

For sure, some useful common idioms will emerge;
I am inclined to resist adding a language feature
simply in order to reflect a specific coding idiom,
especially when it can trivially be written without
any new language support (in this example, by the 
addition of an empty default branch).

The idea of setting a default on a bunch of signals,
and then changing your mind about that default when
you're deep in  some complicated conditional, is 
(to me at least) such a natural, easy and standard 
approach that I don't really want to mess it up with 
some obscure special-purpose new syntax.  The 
unique/priority syntax provides a convenient way 
of asserting a common and useful design intent 
that is often quite hard to express any other way, 
but it should not get inflated ideas about its 
own importance.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

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