Subject: Re: Assign-Deassign Notes & Two iff typos in Draft 5
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Tue Apr 16 2002 - 21:05:17 PDT
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. Your
second flip-flop example, with no reset, correctly uses force/release--to
control the simulation tests, not to model the flip-flop behavior.
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. 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. Perhaps that is why you
have the impression Synergy required using assign/deassign. 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.
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
At 01:57 PM 4/16/2002, Clifford E. Cummings wrote:
>I have a very different opinion of assign-deassign gained from very
>painful experience.
>
>I will not shed a tear at the deprecation of assign-deassign.
>
>At 01:40 PM 4/16/02 -0700, Stuart Sutherland wrote:
>
>>I vote NO to #2, deprecating procedural assign/deassign. I feel there
>>are rare circumstances where this construct models functionality that is
>>needed.
>
>I always issue this challenge. Show me an example where this is needed. I
>claim I can do it better another way.
>
>>I feel force/release is not a suitable substitute, as it is solely
>>intended as a verification and debug construct.
>
>Not entirely true. I have used force/release in code for flip-flops with
>both asynchronous set and reset and also for flip-flops with NO set or reset:
>
>// Clock divider with no reset - starts and stays unknown
>always @(posedge clk)
> q <= ~q;
>
>// Put the flip-flop into a known state for simulation
>initial begin
> force q = 0;
> @(posedge clk) release q;
>end
>
>>I have done benchmarks (albeit a long time ago) that show assign/deassign
>>provide significantly better simulation performance than can be obtained
>>using procedural assignments.
>
>In modern simulators, the difference is much smaller. Consider the
>following example:
>
>always @(rst_n)
> if (!rst_n) assign q = 0;
> else deassign q;
>
>always @(posedge clk)
> q = d;
>
>The performance improvement usually comes from the fact that during the
>active-assign, the second always block can be ignored (ignoring all of
>those clk edges during a reset).
>
>SystemVerilog added a similar capability, as shown on page 40 of Draft 5
>(model slightly modified):
>
>always_ff @(posedge clk iff rst_n or negedge rst_n)
> if (!rst_n) q <= 0;
> else q <= d;
>
>An intelligent simulator will similarly ignore the posedge clk during
>active rst_n and achieve better simulator performance.
>
>TYPO (Draft 5, page 29, paragraph after the latch example)
>WAS: "in this case when rst ==0"
>PROPOSED: "in this case when enable == 1"
>
>TYPO?? (Draft 5, page 40, last paragraph of section 10.4)
>WAS: "The always_ff block imposes the restriction that only one event
>control is allowed."
>I see two event controls in the always_ff example above this paragraph.
>
>>I think that as we push to higher levels of abstracts--the aim of
>>SystemVerilog--there may be new and appropriate and not yet thought of
>>uses for assign/deassign. The only reason assign/deassign are not used
>>at the RTL level is because Synopsys chose not to support the deassign
>>portion in synthesis.At least one other synthesis tool, Synergy, did
>>support assign/deassign, but alas, that tool never gained enough market
>>share to set the de facto synthesizable subset. Still, Synergy proved
>>that assign/deassign can be realized in logic.
>
>Synopsys chose not to support either procedural assign or deassign, and
>for good reason.
>
>Synergy required assign and deassign because if I remember correctly, the
>reset functionality had to be modeled in one always block with assign and
>deassign, separate from the clock assignment in a second always block. I
>believe the Synopsys flip-flop coding style was illegal in Synergy (I
>could look up my old Synergy notes if anybody is really that interested).
>This violates my guideline to not make RTL assignments to the same
>variable from more than one always block.
>
>It did work in Synergy and as long as it was confined to just two always
>blocks located next to each other, it was not too bad.
>
>I had to help one customer change their old Synergy RTL model to a
>Synopsys RTL model. The model was big and the assigns and deassigns where
>numerous and spread throughout the design. In the end, I found it
>impossible to tell which assign had priority over the other assigns
>(required a more complex analysis of the control signals to determine
>which control signals had priority over others). It was a mess and I am
>not convinced that Synergy was really implementing the correct functionality.
>
>I applaud Synopsys for never supporting procedural assign/deassign.
>
>>Stu
>
>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 //
>//*****************************************************************//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Tue Apr 16 2002 - 20:06:35 PDT