RE: [sv-bc] Pre-Proposal to handle X-problems in RTL coding

Hi, Tom -

Good questions. See below.

At 10:46 PM 11/5/2007, Alsop, Thomas R wrote:
>Hi Cliff,
>
>I like this proposal.
>
>I have a few questions which I am sure you have thought about, I just
>want to hear them addressed by you.
>
>1. unique0 could potentially create scenarios where the designer forgets
>to place his default assignment before the case statement.  This results
>in a latching element and no indication of such until synthesis.  I like
>how it is used in conjunction with always*x blocks, I just worry that we
>won't catch these issues sooner now.

This is true, but latch detection was never assured even when using 
unique. The problem shows up most often in designs where multiple 
outputs are assigned in the same case statement. Consider the trivial example:

always_comb
   unique case (sel)
     1'b0: begin
             a = '0;
             b = '1;
           end
     1'b1: a = '1
     default: begin
                a = '0;
                b = '0;
              end
   endcase

unique did not prevent latches and no warning will be issued in this 
simulation because the case statement is "full" and the default is 
never even synthesized (assuming a 1-bit sel).

A good linting tool could find that b is a latch in an always_comb 
block, but most simulators will not find this.

The problem with unique was that it reported warnings on good RTL code like:

always_comb begin
   y = '0;
   unique case ({en,a})
     3'b100: y[a]='1;
     3'b101: y[a]='1;
     3'b110: y[a]='1;
     3'b111: y[a]='1;
   endcase
end

Without the unique statement, this model simulates and synthesizes to 
a 2-to-4 decoder rather nicely. I could add the unique0 keyword to 
this design and it would work fine.

>2. I think we all agree that removing optimism is always good even at
>the expense of pessimism, but how much pessimism are we introducing now
>and do you see this as an issue we'll have to address later?

I don't think this is a problem. If we really leave variables 
uninitialized, I believe engineers want to know if their design is 
sufficiently robust to handles the propagation of unknowns in the design.

Again, this proposal assigns X's when a variable is tested, not when 
it is used in a Boolean equation. For example:

always_comb
   y = a & b & c;

Is still identical to:

always_combx
   y = a & b & c;

And as far as synthesis tools are concerned, there is no difference 
between always* procedures and always*x procedures.

>The more I
>think about this, and I have done plenty of x debug, I don't think it's
>going to be that bad.  Our debug tools today are much better at tracing
>x's back in simulation, whether through automation or manually.  This
>may be the motivation to fine tune those tools.

I think we are in agreement. I think those tools will quickly trace 
back to the RTL test that forced the X-assignments, which will help 
to quickly identify the offending X-signal.

>3. If designers move to always_*x it will require rewritting existing
>legacy code, beyond just tacking on the x suffix. The case statement
>examples require that the default be removed and placed as a
>pre-assignment.

Actually, I don't think the defaults need to change at all. You can 
still have a default and it now turns into the default for all 
unlisted binary combinations, plus you now have an implicit defaultx 
that assigns X's for case expressions that contain unintended or 
unexpected X's.

Engineers may or may not retrofit existing designs. That is up to 
them. This enhancement does not change the behavior of any existing 
code. It might be interesting if EDA companies added an optional 
+alwaysx switch that would automatically convert always* blocks in 
existing designs into always*x varieties to allow engineers to 
quickly test the impact of retrofitting existing designs with the 
always*x variety (hint to vendors?? :-) )

>I like the results of doing this, don't get me wrong,
>but what I'd _really_ like is for this to work semantically as you
>describe without moving the default. Is there a way to make this
>enhancement to the proposal?

Again, one can use the default as is. I don't think this was very 
clear in the pre-proposal.

In Advanced Verilog training I always recommend making the 
pre-default assignment, because it synthesizes to very efficient 
logic and the pre-default can prevent latches that an equivalent 
case-default will not fix.

>Thanks, -Tom

Good questions and thoughts.

Regards - Cliff

>-----Original Message-----
>From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
>Behalf Of Clifford E. Cummings
>Sent: Monday, November 05, 2007 6:07 PM
>To: sv-bc@server.eda.org
>Subject: [sv-bc] Pre-Proposal to handle X-problems in RTL coding
>
>Hi, All -
>
>Could you peek at this pre-proposal to handle X-problems in RTL
>coding? I have run this past engineers at ARM and they agree that
>this would solve their RTL coding related X-problems.
>
>In short:
>(1) parallel_case equivalent using a new keyword: unique0
>(2) X-trapping using new keywords: initialx, alwaysx, always_combx,
>always_latchx, always_ffx
>
>Addresses Mantis items: 99, 2115, 2129, 2131, 2132
>
>Regards - Cliff

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