Subject: Re: Deprecating assign/deassign - response to Kevin's comments
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Tue Apr 16 2002 - 16:09:02 PDT
I agree with you entirely that people will abuse stuff - that's
not confined to Verilog. However, as someone who occasionally
implements simulators, I can see efficiency benefits in using
the "assign" statement, and that it its use would probably
mirror an aspect of the hardware that will be lost otherwise.
I agree that procedural assign/deassign should probably be
removed from the language, but unless you offer something that
performs the same function better I can't see it happening. So
I just offered the "guarded assign" as a simple language extension
that provides (probably) better efficiency than the procedural
assign, but about the same level of control.
I'm on your side really :-)
Kev.
> From owner-vlog-pp@eda.org Tue Apr 16 15:15:13 2002
>
> 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 - 16:11:12 PDT