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

hi all,

I hear Cliff's frustration and I think I understand what
he's aiming for, but I'm really uncomfortable with the
supporting arguments.

> 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.

No dispute.

> 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 use this style 
all the time and I've never yet seen a synth tool create
functionally incorrect logic from it.  I can't say for 
sure whether the optimizations have been ideal, though.

> 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

This is the part I'm uncomfortable with.  If it's a problem
about tool shortcomings, the way to fix it is to beat on the 
tool vendors rather than to introduce some new syntax.
In RTL it is absurd to assume that any single procedural 
statement captures the whole of the logic associated with 
a signal.  Synthesis has no right to make any such assumption.

I'm really disturbed by the idea of introducing syntax 
crafted solely to simplify a specific kind of "set-piece"
design.  Suppose, for a moment, that we didn't have
an explicit enable, but instead we had a somewhat more
complicated instruction-decode to decide what to do...

always_comb begin
  y1 = 0;
  y2 = 0;
  y3 = 0;
  unique casez (a)
    // we generate these outputs whatever the opcode...
    3'b01?: y1 = 1;
    3'b1?1: y2 = 1;
    3'b1?0: y3 = 1;
    default: ;
  endcase
  if (opcode == MODE_1)
    // then we OR-in some more assignments to y1,y2,y3
    unique casez (a)
      3'b1??: y1 = 1;
      3'b?1?: y2 = 1;
      3'b??1: {y1, y3} = 2'b11;
      default: ;
    endcase
end

Here I absolutely must *not* have any defaults 
associated with the second case statement, but
the unique modifier is still meaningful and I must
trust my synthesis tools to respect it.  My 
default assignments at the top of the always_comb
assure freedom from latches, and if I miss one 
then I get synthesis errors (I hope!) because 
it's always_comb.  I simply don't see what I would
gain here from an "initial" branch in unique-case.

> [...] priority and unique complain that 
> I did not execute any case-assignment code

and quite rightly so, too - given the way they're 
defined.  But we've already noted that there is an 
easy workaround: an empty default branch.

> 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.

In my ideal world that would have been "unique priority case"
(and, by-the-by,  "priority" would have been renamed "complete"). 
But it's way too late for any change to that now.  It's easy
to have 20/20 hindsight when you've had a couple of years to
think about it :-)
-- 
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.