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

Just to add my $0.02 worth...  I like Cliff's idea of adding a construct
that allows case statements to be fully self-contained, instead of having
part of the decode logic before the case statement and part of the logic
inside the case statement.  It makes code more self-documenting, and
prevents the possible different interpretations of coding intent that
currently exists in tools.  This is a simple change that has a lot of value.

However, I do not like reusing the "initial" keyword in this context.
Visually, it looks like a nested initial procedural block, and verbally it
reads like a one-time initialization.  I have not had the time to look over
the existing keyword list for a better existing keyword, or to come up with
a new keyword (a last resort).  Is any keyword needed?  Why not just allow
zero or more blocking assignment statements to be made after the case
expression and before the first case item expression (blocking assignments
so that they must take effect before the case select expressions are
evaluated).

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898
 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Clifford E. Cummings
> Sent: Sunday, July 08, 2007 5:40 PM
> To: sv-bc@server.eda.org
> Subject: RE: [sv-bc] Case Statement Enhancement Proposal Idea
> 
> Hi, All -
> 
> At 02:09 PM 7/8/2007, Jonathan Bromley wrote:
> >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.
> 
> Acknowledged.
> 
> > > 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).
> 
> >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.
> 
> If you have used the null-default you are fine because default 
> cancels the full_case optimization. I believe your example below will 
> also work fine because you use null-defaults in both case statements.
> 
> If you remove the null-defaults or change the null-defaults to 
> X-output assignments or other partial-output assignments I believe 
> your example might fail (but you would at least get a warning from a 
> compliant simulator about the non-matching condition during run-time 
> if you just remove the default - not for the other cases).
> 
> > > 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.
> 
> Perhaps, but all of the tools that I have tested with this coding 
> style make the same interpretation, which is why I show it in 
> training. I don't know how much success I would have convincing all 
> the vendors that they should change the way their tools work and 
> suffer the complaints from users who have take advantage of 
> this "feature."
> 
> I had not done the null-default before because a default 
> automatically disables full_case testing. Since I sometimes like 
> making all X's assignments in a default, I could not count on the 
> null default being universally available.
> 
> >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.
> 
> Perhaps. I am just reporting the observed facts.
> 
> >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
> 
> Again, I think this will work because of the two null-defaults. 
> Change the null-defaults to {y1, y2, y3} = 'x; and I think you might 
> see some problems (I have not tested this).
> 
> I don't think you were looking for a re-write of your example (but a 
> re-write follows), but just as you are showing an interesting coding 
> condition, I am trying to show that a reasonable approach to this 
> type of coding condition is readily apparent. I think most users 
> would find the null-defaults to be confusing (I could be wrong) 
> because most users will not realize that null-defaults are full_case 
> disable statements.
> 
> The re-write for this model might be:
> 
> always_comb begin
>      unique casez (a) // casez #2
>        initial unique casez (a)    // initial execute for casez #2
>          initial {y1, y2, y3} = '0;    // initial execute for casez #1
>          3'b01?: y1 = '1;  // casez #1 case items
>          3'b1?1: y2 = '1;
>          3'b1?0: y3 = '1;
>        endcase
>        3'b1??: y1 = '1;  // casez #2 case items
>        3'b?1?: y2 = '1;
>        3'b??1: {y1, y3} = '1;
>      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 agree with all of this. Again your null-defaults save the day.
> 
> >I simply don't see what I would
> >gain here from an "initial" branch in unique-case.
> 
> Besides fixing known problems, if one does not use a null-default, I 
> believe the coding style is easy to explain and to understand. In the 
> absence of the case-initial, I might be inclined to recommend 
> null-defaults everywhere and avoid actual default assignments. To me 
> that is not friendly.
> 
> > > [...] 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.
> 
> True.
> 
> > > 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 :-)
> 
> Perhaps. We certainly agree that "priority" is an awful keyword that 
> really does not describe its true intent. I had not thought of 
> "complete," but if you look at my Israel SNUG 2005 paper, I believe I 
> mentioned better keywords would have been "all_cases" or "fullcase." 
> Geeze! A case statement is already priority, how does "priority" 
> help? :-) Sadly, I also agree with your hindsight and "too 
> late" comments.
> 
> I have had almost 12 years to stew over this problem and it still 
> took me 4 years to document the problem in the 1999 Evil Twins paper. 
> It is a relatively easy no-new-keyword and small-semantics-change fix 
> to an age-old problem. It makes the RTL coder's life just a 
> wee-bit easier.
> 
> Regards - Cliff
> 
> >--
> >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.
> 
> ----------------------------------------------------
> 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.
> 
> 
> 



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