Subject: Re: Section 7.7.9.1 - Initial Blocks - Illegal??
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Wed Apr 10 2002 - 17:39:15 PDT
My apologies -
I meant to send this to the whole group (I must have put it in an ignored
initial block the first time ;-)
- Cliff
>Date: Wed, 10 Apr 2002 17:35:18 -0700
>To: pgraham@cadence.com
>From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
>Subject: Re: Section 7.7.9.1 - Initial Blocks - Illegal??
>
>At 04:13 PM 4/10/02 -0700, you wrote:
>> > Reviewing draft D2.1, I came across the statement in section 7.7.9.1 that
>> > "The initial statement shall be supported only for ROM modeling as
>> > described in 5.6.2. It shall be ignored in all other contexts."
>> >
>> > I thought we made initial block illegal except for ROM usage. Ignored
>> > initial blocks are exceptionally dangerous since this can cause a
>> mismatch
>> > between pre-synthesis and post-synthesis simulations.
>>
>>Initial blocks are not the only things that can cause simulation diffs.
>>Delays are another. Do you recommend erroring out for delays?
>
>Nope! I just recommend not using delays, but some engineers like to add #1
>to the RHS of nonblocking assignments to make waveform displays easier to
>read (a clk-to-q delay in the waveform). Although delays can cause a
>mismatch, they rarely do because most verification is done just before the
>next clock edge when either a 0-delay model or delay-model has settled to
>the correct value (I still discourage using delays in RTL code).
>
>The reverse argument is to ignore any unsupported construct. You have an
>event that triggers other RTL code in a simulation? Just ignore it??
>Ignore assign-deassign in multiple procedural blocks?? My general
>guideline to engineers is to never use an initial block in an RTL model.
>Use them in testbenches only. I see no reason to ignore them in a
>synthesis tool and hope for the best.
>
>>If you error out for initial blocks, then the customer ends up doing:
>>
>> // ambit synthesis off
>> initial ..
>> // ambit synthesis on
>
>At least the customer had to take affirmative action to show that the code
>is non-synthesizable so they are less likely to insert frivolous initial
>blocks or think twice about using the initial block.
>
>There is a book published by Zain Navabi where (if I remember correctly),
>every synthesis example in his book initializes the output variable in an
>initial block (aaarghhhh!!!) because Synplicity let him do it. I consider
>this to be almost malpractice supported by a tool. The synthesis tool
>ignores the initial blocks and every design fails simulation unless you
>are lucky.
>
>Flagging the initial blocks as a mistake removes much of the risk of what
>is surely a way-too-easy mistake to make (especially for self-taught and
>Navabi-read Verilog synthesis newbies).
>
>> (supply your favorite vendor's pragmas here)
>>
>>and you still get simulation diffs.
>
>If the engineer is stupid enough to hide functional code from the
>synthesis tool, they will get diffs.
>
>>By this logic we should error out when we see "synthesis on/off" pragmas,
>>since they can lead to simulation diffs as well, depending on where they are
>>placed!
>
>Absolutely not. If you tell the synthesis tool you really, really want to
>do this, then the tool can oblige. Occasionally, putting a $display
>message in an initial block makes sense.
>
>>paul
>
>Stupid stuff should not be blessed by this committee and dangled in front
>of the uninitiated.
>
>My opinion only.
>
>Regards - Cliff
//*****************************************************************//
// Cliff Cummings Phone: 503-641-8446 //
// Sunburst Design, Inc. FAX: 503-641-8486 //
// 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
// PMB 501 Web: www.sunburst-design.com //
// Beaverton, OR 97005 //
// //
// Expert Verilog, Synthesis and Verification Training //
//*****************************************************************//
This archive was generated by hypermail 2b28 : Wed Apr 10 2002 - 17:41:59 PDT