Subject: RE: Assign-Deassign Notes & Two iff typos in Draft 5
From: David Smith (david_smith@avanticorp.com)
Date: Wed Apr 17 2002 - 10:57:22 PDT
This is truly entertaining and enlightening but perhaps enough is enough (as you have both indicated).
It is truly wonderful to see two intelligent and forceful individuals able to hold a discussion without resorting to personal and inappropriate comments. Gives me hope for the rest of the world (or at least the standards efforts).
Regards
David
David W. Smith
Architect
Avant! Corporation
9205 SW Gemini Drive
Beaverton, OR 97008
Voice: 503.520.2715
FAX: 503.643.3361
Email: david_smith@avanticorp.com
http://www.avanticorp.com
-----Original Message-----
From: Clifford E. Cummings [mailto:cliffc@sunburst-design.com]
Sent: Wednesday, April 17, 2002 10:45 AM
To: vlog-pp@eda.org
Subject: Re: Assign-Deassign Notes & Two iff typos in Draft 5
At 09:05 PM 4/16/02 -0700, Stuart Sutherland wrote:
>Cliff,
>
>Thank you for proving my point so well. Your first flip-flop example
>is
>using force/release, which are verification/debug constructs. The example
>should use assign/deassign, which are behavioral modeling constructs.
"should use" ??
If the example "should use" assign-deassign, then we should not deprecate
the constructs.
>Your second flip-flop example, with no reset, correctly uses
>force/release--to control the simulation tests, not to model the flip-flop
>behavior.
"correctly uses" ??
I see no reason to have engineers think <debug or behavioral> to support a
reason for choosing assign-deassign vs force-release. To me this is
methodology overkill. As Mac has pointed out, in modern simulators, they
are implemented the same (with different priorities). I claim that
force-release can do anything that assign-deassign can do and more (can
force nets too). I claim that assign-deassign has been over-emphasized,
poorly taught and incorrectly used (largely credit the Cadence training
that you note below). Also note that the assign keyword means something
different outside of a procedural block and that new users gravitate
towards putting it incorrectly into procedural blocks and most of they time
they get lucky and their simulation still works as expected (I'm sure you
that you too have also seen this in training).
IMO, the arguments to deprecate assign-deassign were numerous and
compelling. I do not believe I was making your point at all.
>As an AE for Cadence supporting Synergy in its early days, I could go
>into
>a lot more detail on where and why the product preferred
>assign/deassign--it least as it was explained to me by the R&D engineers.
>Suffice it to say that Synergy did support the Synopsys style of
>flip-flop
>resets, but could do some things with assign/deassign that Synopsys did
>not do nearly as well at that time (and in some cases still doesn't do
>well). Your asynchronous reset/preset example is just one of those
>circumstances.
One thing that Don & I neglected to emphasize in our paper that showed the
extra self-correcting code for a flip-flop with both asynchronous set and
asynchronous reset is that the extra code is very rarely required. The
extra code is only required under the existence of all three of the
following conditions: (1) the design includes flip-flops with both
asynchronous sets and asynchronous resets (which practically makes the
design asynchronous), (2) both reset and set can be asserted at the same
time (rare), (3) reset can be removed before set is removed (even more
rare). I estimate that fewer than 0.1% of all designs would require the
extra code. We do point this out in our training classes.
>Cadence training courses and support AE's were also very good at
>getting
>Synergy users to not use the Synopsys reset style so that they could lock
>customers into their product.
Yeouch! Those customers took this style to new highs (lows ;-) creating
behavioral models that are logically incomprehensible (again, based on my
experience of trying to help a customer back-out all of the assigns and
deassigns in their code.
>Perhaps that is why you have the impression Synergy required using
>assign/deassign.
Actually, I had a customer tell me the Synopsys style did not work. Perhaps
the customer was wrong.
>Enough said. Let's agree to disagree on the value of assign/deassign.
>At
>this point, neither of our opinions will change the outcome of the vote to
>deprecate them, and there are much more important things to be working on.
Agreed.
>Thanks for pointing out the typo's. I'll correct them for draft 6
>right
>now. Finding them is a good thing that came out of the discussion on the
>value of assign/deassign. It was worthwhile after all.
>
>Stu
Also true.
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 17 2002 - 10:59:11 PDT