Subject: Assign-Deassign Notes & Two iff typos in Draft 5
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Tue Apr 16 2002 - 13:57:27 PDT
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 //
//*****************************************************************//
This archive was generated by hypermail 2b28 : Tue Apr 16 2002 - 13:59:02 PDT