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

Cliff, on that other side note we had with this proposal...

We were still bantering around on whether we extend this proposal to
modulex, functionx, taskx, etc.. rather than just limiting ourselves to
always*x.  

The more I think about this, as I am laying in my bed at night (yes, my
thoughts do turn to these topics, I admit it's pretty sad:'), I like the
idea of sticking with just using the always*x versions.  Definitely not
intialx.  While modulex is more inclusive, it doesn't allow any
granularity.  

Now personally, I wouldn't use this x debug functionality except to turn
it either completely on or off (i.e. for the entire model).  However, I
can think of cases where I may in time want to limit my x debug to one
procedural block.  

For example, One of the x validation limitations that I train our
engineers about is to code your design to a state where _most_ of the
functionality it done and _then_ turn on x debug.  In this way you are
not debugging x's related to incomplete logic.  With the always*x
granularity, we may now be able to turn on (i.e. make them always*x) the
procedural blocks that are "done" or complete while leaving the other
incomplete blocks as normal non-x procedural blocks.

Given these thoughts, I would prefer to add functionx and taskx along
with the always*x additions, but leave modulex and initialx out.  I am
also open to modulex as long as it includes always*x, functionx, and
taskx.

Thanks,
-Tom 


>-----Original Message-----
>From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
>Behalf Of Clifford E. Cummings
>Sent: Sunday, November 18, 2007 10:47 AM
>To: sv-bc@server.eda.org
>Subject: RE: [sv-bc] Pre-Proposal to handle X-problems in RTL coding
>
>Hi, Shalom and Jonathan -
>
>BTW - Jonathan's example is correct and one of the reasons for the
proposal.
>
>I think my original proposal may have been a bit misleading. A couple
>of engineers (including Shalom in the last paragraph) have expressed
>that having both a pre-default AND a regular default would be
>desirable (and I agree). The proposal to allow unique0 was never
>intended to remove the ability to add a case-default. It just so
>happens that all the examples that I previously sent did not include
>the case-defaults because they were unnecessary for those examples.
>
>More below.
>
>At 01:16 AM 11/7/2007, Bresticker, Shalom wrote:
>>Cliff,
>>
>>I have not yet had time to review the proposal and the following
>>discussions, but I have a question:
>>
>>You have proposed unique0 (parallel_case) as obviating the need for
>>pre-defaults. I don't see the necessary connection. Pre-defaults are
>>useful regardless of a case being parallel. You yourself wrote:
>>
>> > 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.
>>
>>I agree. I have long advocated and taught the use of pre-defaults
(even
>>using the same term). I don't see that latch prevention is necessary
>>related to parallel_case.
>>
>>And pre-defaults have additional benefits. First, they can be used
even
>>in the code describing a flip-flop where I want to specify an output
>>value for every case, even though latch prevention is not relevant
>>there.
>>
>>They also have the benefit that I only need to specify output values
>>when they are different from the pre-default. This can save an
enormous
>>amount of code, make it much more readable, and reduce the number of
>>bugs.
>
>We are still in absolute agreement concerning the value of the
>pre-default assignments for all of the reasons you have shared above.
>
>The reason I backed off of the pre-default is because it was largely
>discouraged by the EDA vendors on the conference call when we
>discussed it in favor of a parallel_case equivalent.
>
>Second, I think a parallel_case equivalent will achieve the same
>goal. Allow me to expound.
>
>unique - is equivalent to full_case parallel_case. The problem with
>unique is the full_case portion. full_case reports errors whenever we
>make the pre-defaults before the case statement and then only make
>the relevant updates inside of the case statement, unless you add the
>empty case-default (as shown in Jonathan's example).
>
>Remember that a case-default always kills full_case checking, because
>you have now said that "under all other conditions, do the default
>assignments." full_case is only active when you specify an incomplete
>case statement, in which case you are telling the synthesis tool, "I
>have defined all legal cases (my case statement is full) and for all
>other cases, the output assignments are don't cares"
>
>
>>There are also cases where I might use both a pre-default and a
regular
>>default. For example, in a state machine, I might use the regular
>>default to specify the next state when the state machine enters an
>>illegal state. Typically, that next state would be the initial state
of
>>the machine, typically an IDLE state. On the other hand, I would
>>typically specify the pre-default of the next state as being the same
as
>>the current state. In that case, I would need to specify the next
state
>>in the code only when it is different from the current state. Staying
in
>>the current state is frequent in state machines.
>>
>>What have I missed?
>
>As noted above, I was not very clear on the unique0 restrictions.
>Adding unique0 would be the simulation equivalent of parallel case
>and as such, you could still make a pre-default assignment before the
>case statement and you could still include a case-default in the case
>statement (but none of my previous examples included this example - I
>would need to include such an example in the text to avoid the
>confusion I obviously introduced in my earlier email message).
>
>>Sorry if you already explained this and I just have not read it yet.
>>
>>Regards,
>>Shalom
>
>Hope this helps.
>
>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.