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.Received on Sun Jul 8 17:40:33 2007
This archive was generated by hypermail 2.1.8 : Sun Jul 08 2007 - 17:40:51 PDT