Subject: Re: VOTE - Deprecating assign (use force)
From: Michael McNamara (mac@verisity.com)
Date: Tue Apr 16 2002 - 16:25:42 PDT
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!
:-/]
> 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 - 16:26:45 PDT