Subject: Re: VOTE - Deprecating assign/deassign
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Tue Apr 16 2002 - 14:10:20 PDT
> 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
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:12:11 PDT