Subject: Re: VOTE - Deprecating assign/deassign
From: Michael McNamara (mac@verisity.com)
Date: Tue Apr 16 2002 - 14:52:07 PDT
Kevin Cameron x3251 writes:
> > 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. I feel force/release is not a suitable substitute, as it is solely
> > intended as a verification and debug construct. 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. 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.
> >
> > 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
How about
assign x = slct ? a :
!slct ? b : 'bz;
This has worked in Verilog since 1987
>
>
> I think that may make (some) design intent more obvious to synthesis tools
> and is not hard to optimize in simulation.
>
>
> Just a thought.
>
> Kev.
This archive was generated by hypermail 2b28 : Tue Apr 16 2002 - 14:53:07 PDT