Subject: Re: VOTE - Deprecating assign (use force)
From: John Sanguinetti (JSanguinetti@ForteDS.com)
Date: Tue Apr 16 2002 - 17:05:28 PDT
I have to admit, this thread has been fun.
see below
At 4:25 PM -0700 4/16/02, Michael McNamara wrote:
>Kevin Cameron x3251 writes:
> > > 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.
>
> 1) Assigns are not resolved. The assign can only target a register.
> There is no resolution of 'drivers' of registers, as there can only
> be one driver. (a subsequent assign is treated as an implicit
> deassign of the the previous assign).
>
> 2) You are right the force is not resloved. What this means is you
> can force a wire to have a value of 'z', and despite their being 100
> other drivers that are driving the wire to strong 0, the wire will
> have the value of 'HiZ'.
>
> In truth this is exactly like assign, as despite what other value the
> register might have, the existance of an assign targeting the
> register supersedes any other value with the one supplied by the
> assign.
>
> So, force and assign are exactly alike; with the one exception that
> one can preempt an assign with a force; and that releasing a force
> allows the assign to again have effect.
>
> Saddly, it is apparent that deassign'ing the assign (or releasing the
> last force) does not restore the value previously written to the
> register: it stays with the last value assigned (or forced). The
> only really effect of the release & deassign statements is that
> subsequent simple assignments again take effect.
>
> I've tested this with Verilog-XL and VCS; the code:
>
>module foo;
> wire a;
> reg r;
>
> assign a = 1'b1;
> assign a = 1'b1;
> assign a = 1'b1;
> assign a = 1'b1;
>
> initial begin
> #10 $display ($time," Just drivers: a is %b (%v)",a,a);
> $showvars(a);
> #10 force a = 1'bz;
> #10 $display ($time," Plus a force: a is %b (%v)",a,a);
> $showvars(a);
> r = 1;
> #10 $display ($time," simple store of 1: r is %b (%v)",r,r);
> $showvars(r);
> assign r = 1'bz;
> #10 $display ($time," plus assign of z : r is %b (%v)",r,r);
> assign r = 1'b0;
> #10 $display ($time," plus assign of 0 : r is %b (%v)",r,r);
> $showvars(r);
> force r = 1'bz;
> #10 $display ($time," plus force of z : r is %b (%v)",r,r);
> $showvars(r);
> release r ;
> #10 $display ($time," release frc of z : r is %b (%v)",r,r);
> $showvars(r);
> deassign r ;
> #10 $display ($time," deassign as of 0 : r is %b (%v)",r,r);
> $showvars(r);
> end
>endmodule
>
>gives:
>
> 10 Just drivers: a is 1 (St1)
>a (foo) wire = St1
> St1 <- (foo): assign a = 1'b1;
> St1 <- (foo): assign a = 1'b1;
> St1 <- (foo): assign a = 1'b1;
> St1 <- (foo): assign a = 1'b1;
> 30 Plus a force: a is z (HiZ)
>a (foo) wire = HiZ
> Node is in forced state from: L13 (foo)
> St1 <- (foo): assign a = 1'b1;
> St1 <- (foo): assign a = 1'b1;
> St1 <- (foo): assign a = 1'b1;
> St1 <- (foo): assign a = 1'b1;
> 40 simple store of 1: r is 1 (St1)
>r (foo) reg = 1'h1, 1
> 50 plus assign of z : r is z (HiZ)
> 60 plus assign of 0 : r is 0 (St0)
>r (foo) reg = 1'h0, 0
> 70 plus force of z : r is z (HiZ)
>r (foo) reg = 1'hz, z
> Node is in forced state from: L24 (foo)
> 80 release frc of z : r is 0 (St0)
>r (foo) reg = 1'h0, 0
> 90 deassign as of 0 : r is 0 (St0)
>r (foo) reg = 1'h0, 0
>
>[I'd have expected the final value to be 1, after we unpeel all the
>other forces and assigns; but both VCS and Verilog-XL disagree with me!
>:-/]
The reason it works like this is that there is a separate, single
driver for all forces on a reg, but there is no separate driver for
assigns. Assign can be implemented by simply storing the new value in
the reg and then ignoring all succeeding assignments until a deassign
has occurred. No matter how many assigns you do, the deassign doesn't
change the value, it simply allows the next procedural assignment to
occur.
The force, on the other hand, overrides the reg's normal value. So,
when you you do the release, it reverts to the value which is in the
variable's storage location. If that value was set by an assign, it
doesn't know the difference.
As a point of historical interest, I (vaguely) remember this was the
way we implemented it in VCS the first time (who knows if it's still
implemented that way?), after carefully experimenting with
Verilog-XL. Maybe Phil can give us the reason he did it that way in
XL.
Even though I'm not eligible to vote, I would vote yes on deprecating
both these features (especially defparam).
>
>
> > 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.
>
> 1) One can already specify the strength of the force driver; but as I
> stated, the wire (or reg) takes precisely the forced value; it is not
> resolved with any other active drivers of that wire.
>
> 2) A different point: making drive strength a floating point number
> is a major change that will greating increase the size of storage
> required, and will make resolution functions a floating point
> calculation, rather than a table lookup (signifcantly slowing down
> simulation). Right now, the strength type fits precisly into an 8
> bit wide storage location, which overlaps with the representation for
> logic type. This allows the presence of a single strength driver in
> a design to have little or no impact on the speed of simulating the
> design.
>
> Allowing floating point strength would require 64 bits to represent a
> bit, as one needs to track the highest strength 0 and 1 driver
> currently on a bit; this assumes we use C's 32 bit 'float' instead of
> the 64 bit 'double'. If we do the later, then it will require 128
> bits to hold the value of a bit. Memory is cheap, but not that
> cheap.
>
> > 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 ?
>
> Force strength actually does exist, and is stronger than anything
> else; This come into consideration when a net that is driven without
> a strength specifier (hence becomes strength FORCE) is input to
> another net.
>
> > 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
> >
> > 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 - 17:07:29 PDT