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

Cliff, forwarding some comments on this proposal from Wayne Clift,
Principal Engineer at Intel. -Tom

-----Original Message-----
From: Clift, Wayne 
Sent: Wednesday, November 07, 2007 9:20 AM
To: Alsop, Thomas R
Subject: RE: [sv-bc] Pre-Proposal to handle X-problems in RTL coding

The whole conversation does beg an important question.  We are trying to
fix x-propagation problems in verilog, and the first attempts thus far
poke at each individual offending assignment, then begin poking at the
always blocks that surround this code, then progress to wondering why
not just declare the behavior of the module as a whole.

What we WANT out of this is for verilog 4-value simulation to "just
work" in the most accurate way possible with the smallest impact to RTL
coders, RTL code, and simulation tools.  Each successive iteration
raised the coding level of these x-propagation clues higher and higher.


So, I ponder the question, why would anyone doing 4-val sumulation WANT
behaviors in their design that weren't uniformly accurate.  Cliff
wonders the same thing when thinking that designers wouldn't mix
always_* and always_*x.  If the designer is to the point of TRYING to be
accurate, it seems like the best option to provide is a new consistent
interpretation of who X's propagate on all existing code.

To vendors, this DOES mean they may need to analyze the semantics of
each problematic assignment/conditional where x-pessimism/optimism
exists and behave differently according to a strict new definition.  It
seems like "modulex" gets to that point where the designer, by saying
"modulex" is just saying, "Vendor, please just simulate X's correctly in
this module."  One last step up...ExeX.  "Vendor, everything that you
are executing...please just propagate X's correctly!"

I'm sure Cliff can list off several realities that make this complex.
I'll add a few.
	a) Exceptions - whatever is done, someone will want an
exception.  Do we ask for control of how this is applied.
	b) IP Sharing - When we use external IP that we can't modify,
will we still have control to simulate x's correctly
	c) Not all knowing....we'll realize later why global-only
control is wrong for some situation.  Lower level block control would
help recovery.

Another issue that perhaps is getting addressed in a different forum is
POWERDOWN x-propagation: modeling of multiple VCC's that turn on and
off, what happens to internal logic and when when power is disabled and
enabled, granularity of power control (module level, statement level),
etc.  Are these issues also being worked in concert with x-propagation?

You are welcome to send this on to Cliff.

Thanks,
Wayne


-----Original Message-----
From: Alsop, Thomas R 
Sent: Tuesday, November 06, 2007 9:29 PM
To: Clift, Wayne
Subject: FW: [sv-bc] Pre-Proposal to handle X-problems in RTL coding

This just keeps getting more interesting.... It would be really cool to
see your feedback on this issue hit the reflector.

I could stomach the procedural blocks "x" varieties, but I'm not giddy
about the modulex or functionx/taskx flavors.  Need to think through
those. 

-Tom

-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Clifford E. Cummings
Sent: Tuesday, November 06, 2007 5:42 PM
To: sv-bc@server.eda.org
Cc: Mike Turpin
Subject: Re: [sv-bc] Pre-Proposal to handle X-problems in RTL coding

Hi, Randy -

Good point and excellent question. I will address them below.

At 05:15 PM 11/6/2007, Randy Misustin wrote:
>Hi Cliff,
>
>As a matter of understandability of the resulting code, I'm not sure 
>I like the meaning of conditional statements changing depending on 
>whether they're located within an alwaysx or an always. One loses 
>the ability to reason locally about the meaning of a sequence of 
>statements for all but the shortest of always constructs. Of course, 
>you may argue that 1000 line always constructs are an abomination, 
>but I've seen plenty of them in active use. From this perspective, I 
>would have preferred that the statement syntax or the way an 
>expression or case label is expressed be the discriminating selector 
>of behavior.

I understand the sentiment, but as a matter of practice, an engineer 
doing RTL coding will likely use the always*x coding style throughout 
the model. I doubt if engineers would do much mixing of always_comb 
and always_combx in the same module, so the 1,000-line always blocks 
would be better encompassed by a single always_combx block as opposed 
to adding 10's of ifx and xcase type statements.

Your question does raise the interesting question of whether we 
should just invent a modulex and skip all the always*X varieties. I 
don't know if it is safe to assume (as I have done above) that an RTL 
coder would want to use all of the X-varieties in the same RTL module 
or not (I believe the answer is yes, but let's see what others 
think). It might also be a reasonable approach to the problem and 
then add the always*x varieties in a later version of the standard if 
modulex were deemed to be insufficient to meet the needs.

Note that:

if (^data === 1'bx) $display("data=%b", data);

Should still do the $display (the test resolves to true, not X). Even 
though this code is not synthesizable, it might be included in a 
block to be ignored during synthesis, so the ability to test and 
display X's has not been removed.

>Also, you didn't specify the behavior of conditionals within tasks 
>and functions. Were you thinking that their behavior would change 
>depending on the context from which they're called? Perhaps 
>something more in line with the rest or your proposal would be the 
>introduction of taskx and functionx?

This is an excellent question. I believe it would be undesirable to 
have a local task or function behave differently when called from 
both always_combx and always_comb. Seems like it could get messy.

I am not opposed to functionx and taskx.

Again, going to modulex could simplify this and we could add the 
requirement that no hierarchical references are allowed from modulex 
so that tasks and functions would have to be local to the modulex. 
This might be a bit harsh since some engineers like Matt Maidment 
have shown that they put some void functions in the $root scope for 
calling from multiple modules (per Matt's DAC 2006 presentation), and 
other engineers again might want to hierarchically reference 
variables from outside of the modulex for display purposes. There is 
also the question of a task inside of a modulex being hierarchically 
referenced from a plain module. taskx and functionx might be cleaner 
in these regards.

These are great questions and the types of questions that I was 
hoping for when I put out the pre-proposal.

A couple of additional thoughts. It would be nice to permit vendors 
to add two optional switches:
(1) One to turn off the X-testing and assignments (Why: because once 
a design is proven, simulations might run faster with the X-testing 
turned off).
(2) One to turn on the X-testing for all blocks (Why: to quickly test 
the impact of adding the always*x  code to existing or new models)
The switches would be entirely optional but I could see them being very
useful.

Regards - Cliff

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