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.