Subject: Re: VOTE - Deprecating assign (use force)
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Tue Apr 16 2002 - 15:09:33 PDT
> From owner-vlog-pp@eda.org Tue Apr 16 14:19:23 2002
>
> Stuart Sutherland writes:
> >
> > 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
>
> Just a comment: I implemented the force/release and assign/deassign
> features in VCS, and they use the exact same mechanism, and the same
> speed.
>
> There is nothing you can do with assign/deassign that you can't do
> with force/release; but there is much you can do with force/release
> that can not be done with assign/deassign.
Stu pointed out that force/release is more often used for debugging than
design, so you might run into a problem if you try and use it for both.
Also (correct me if I'm wrong) an assign only applies to one driver (reg)
and will be resolved, but the driver from a force isn't resolved at all.
If you want to use force/release to replace assign/deassign I would
suggest adding a strength level and changing the semantics to allow
resolution within a strength level. E.g.:
BNF:
force [(<strength expression>)] <net_or_reg> = <expression>
force x = y; // replaces assign
force (Strong + 0.1) x = y;
// overrides any drivers of normal strength.
This is useful functionality if you want to resolve different types
on a net since you can automatically discard the results of lower strength
types in user-defined resolution functions. Strength being real makes
it easier create new strength levels if you assign fixed numbers to
the standard ones:
Supply = 7.0
Strong = 6.0
...
Z = 0.0
Debug = 8.0 ?
The resolution function for the standard strength values 0.0,..,7.0
would be pre-defined (as is) other levels would require a user-defined
resolution function.
Note: this is (to some extent) required functionality for AMS, but is
still not well defined in the AMS LRM.
Kev.
This archive was generated by hypermail 2b28 : Tue Apr 16 2002 - 15:11:38 PDT