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

Hi, Adam -

Thanks for the comments.

At 08:40 AM 11/6/2007, Adam Krolnik wrote:
>HI Cliff;
>
>For proposal #3 and #4, (X-detection, X-assignment), I wonder why 
>initialx, alway_ffx and always_latchx
>are needed.
>
>I'm sure initialx is added for consistency, but I don't see a 
>general use for it.

Agreed. I don't know if initialx would be useful in a testbench or 
not. I included it to make the proposal orthogonal. If initialx is a 
sticking point, I could easily delete it and we could add it later if 
there were a compelling reason.

>I don't think always_ffx is useful. If you have an X on a clock, or 
>a reset you will get warnings
>for every block used. This compares with writing an assertion (that 
>reports an error) when the clock
>(or reset) is X. You have one strong error report vs. many weak 
>warnings for the simulation user to review.
>The enable likewise can be verified by a simple assertion.

I think alwasy_ffx and always_latchx are both useful.

I know you have a methodology where flip-flops are instantiated and 
the instantiated code contains all of the assertions and checks for 
the flip-flops (to get the errors that you mentioned), but many 
engineers still like to RTL-code their flip-flops. For those 
engineers, always_ffx and always_latchx are useful.

Note, always_ffx will not trap X's on clocks (clk is not tested in an 
if-statement), but most clocks are cleanly generated from a testbench 
and those clocks that are propagated will typically cause 
catastrophic failures, which are some of the easiest to detect and fix.

Consider the example:

always_ffx @(posedge clk or negedge rst_n)
   if (!rst_n) q <= '0;
   else        q <= d;

clk is never tested so clk-X cannot cause X's to be assigned. On the 
other hand, an uninitialized rst_n signal would fail the if-test and 
cause a clock-assignment to q in an always_ff procedure (very 
undesirable) but would assign q to X in an always_ffx procedure, 
which would help identify the problem.

>I'd much rather have error reports vs. warnings. Too many people 
>ignore warnings
>because there is no way to remove their reporting if determined to 
>be harmless. Most errors include
>a way to suppress their report.  Compiler directives are excellent 
>(though no standard ones exist) at
>doing this.

I agree. I prefer errors to warnings, but most of the vendors on the 
committee are hesitant to require errors in these conditions out of 
fear of false errors being reported and engineers losing confidence 
in the error messages. You may have noticed in my proposal that 
issuing an warning was something that I asked to be considered, but 
it may be enough to drive the X's and skip warnings and errors. The 
driven X's will cause enough damage to help users find the errors.

>Are there other ways of doing this work ? Mike does point out 
>alternatives that are methodology based
>rather than industry tool change based.

Mike emailed me to say he liked this proposal. Mike's original 
proposal included an enhancement request to either add binary 
wildcards called "v" in a case statement, or to add def2val and 
permit multiple defaults in a case statement (def2val followed by 
default). Although the proposals had merit, they did not address the 
issues with X-problems in other conditional and looping constructs. 
After considering: xcase, ifx, repeatx, whilex, forx, (waitx did not 
seem to be needed), etc., and the potential to add multiple x-variety 
tests in the same always blocks, I finally arrived at the conclusion 
that the alwaysx varieties were cleaner and much easier to add to RTL 
code. They also have the advantage that one could swap-out existing 
always blocks with alwaysx to see if any X-optimism or X-pessimism 
code was active in existing designs.

X-optimism and X-pessimism have been 4-state RTL simulation problems 
for such a long time that I thought it was finally time to fix the problem.

Regards - Cliff

>Clifford E. Cummings wrote:
>>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
>--
>     Soli Deo Gloria
>     Adam Krolnik
>     Director of Design Verification
>     VeriSilicon Inc.
>     Plano TX. 75074
>     Co-author "Assertion-Based Design", "Creating Assertion-Based IP"

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