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

Cliff,

I don't think you understood my point.

You wrote,

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

You are saying that if I have a parallel_case equivalent, I don't need a
pre-default.

I am saying something different.

I am saying that I want a pre-default even in NON-parallel-case
situations.

Regards,
Shalom 

> -----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 1:47 PM
> 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.
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.