Subject: Re: VOTE - Deprecating assign/deassign
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Tue Apr 16 2002 - 15:38:40 PDT
> From mac@verisity.com Tue Apr 16 14:51:56 2002
>
> 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 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
True, but the structures in the simulator will be probably be different, and I
can easily construct a more complex example.
I think it is useful because I ran into a chunk of Verilog the other day where
the intent was to pass through one of a selection of clocks - but the code
didn't read that way, and it had the wrong sensitivity list, the "guarded"
assign syntax would have worked better.
Might want to add a default too, e.g.:
assign x ? (*) = 1'b0; // default to 1 not Z when no other drivers
As I said - just a thought, there are plenty of ways to get the same behavior
in simulation.
Kev.
> >
> >
> > 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 - 15:39:53 PDT