Subject: Deprecating assign/deassign - response to Kevin's comments
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Tue Apr 16 2002 - 15:12:21 PDT
At 02:10 PM 4/16/02 -0700, Kevin Cameron x3251 wrote:
> > From owner-vlog-pp@eda.org Tue Apr 16 12:44:45 2002
> >
> > I vote YES to #1, deprecating defparam
> >
> > I vote NO to #2, deprecating procedural assign/deassign. I feel there are
> > rare circumstances where this construct models functionality that is
> > needed. ...
> > Stu
>
>I think the Verilog procedural assign/deassign could be deprecated if the
>continuous assign was extended to include a guard (as per VHDL) so that
>you can select which of a set of assigns is active e.g.:
>
> BNF:
> assign <reg_data_type> [ ? <guard_expression> ] = <expression>
>
>
> bool slct; // control variable
>
> assign x ? (slct) = a; // active if slct is true, otherwise has no effect
> assign x ? (!slct) = b;
>
> always @(clk) slct = f(y); // procedural control
The above is easily replaced with:
assign x = slct ? a : b;
I know this is an easy example. I find engineers using (abusing) procedural
assign two different ways.
(1) They implement the lazy mux. Disjoint control signals used to drive an
input onto a common output. The point is, the engineer does not understand
what really controls the driver on the output signal. Common inputs to a
single output form a mux and an understanding of the select logic is
critical. The above simple example can easily degenerate into 10's of
assign statements to a common x-output with diverse control mechanisms
spread throughout the design. This has been the problem (and the nightmare).
(2) Engineers want certain signals to have priority drive-control on a
common variable. This should be done with priority encoders that are either
combinational logic, or in the case of flip-flops, assigned priority using
if-else for such signals as reset, set, inc, load, etc.
>I think that may make (some) design intent more obvious to synthesis tools
>and is not hard to optimize in simulation.
If multiple guarded assign statements are spread throughout the design, the
intent will not be clear at all. I know! I had to reverse engineer that
type of design.
What would this simple design be if the above example used slcta and slctb
as the guarded control signals where slcta turned off 1ns after slctb was
asserted and turned back on 1ns before slctb turned off?
This can happen with high-speed onehot muxes. In Verilog, the continuous
assign statement models this correctly (possible contention for 1ns overlap
periods). I'm not sure what guarded assign statements would do in this case.
>Just a thought.
>
>Kev.
I tell students in every Verilog class I teach that "if I ever catch you
using the procedural assign-deassign statements, I will disavow any
knowledge of you as ever having been one of my students!" (For some reason
they just seem to laugh when I say that ;-)
I still hail the decision to remove the problematic procedural assign &
deassign commands.
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 - 15:13:49 PDT