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.