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

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.

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?

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