wire assign vs continous assign
Author Message
wire assign vs continous assign

Without experimenting this I can say that it is yes. Both of them should
behave the same. There may be a little inconsitency factor between
different simulators about how they implement these structures.

cheers,
Sreekanth

Quote:

> Here is a \$2000 question:

> Will these two examples always give the same result?

> Example A:

> assign a=b;

> initial begin
> b=1;
> c=a;
> \$display("c=%b",c);
> end

> Example B:

> wire a=b;

> initial begin
> b=1;
> c=a;
> \$display("c=%b",c);
> end

> Per Edstrom

Tue, 27 Aug 2002 03:00:00 GMT
wire assign vs continous assign
Here is a \$2000 question:

Will these two examples always give the same result?

Example A:

assign a=b;

initial begin
b=1;
c=a;
\$display("c=%b",c);
end

Example B:

wire a=b;

initial begin
b=1;
c=a;
\$display("c=%b",c);
end

Per Edstrom

Wed, 28 Aug 2002 03:00:00 GMT
wire assign vs continous assign
Before I tell you the answer, what have you
arranged to make payment for the \$2,000.00?

Quote:
> Here is a \$2000 question:

> Will these two examples always give the same result?

Wed, 28 Aug 2002 03:00:00 GMT
wire assign vs continous assign
No, most simulators will NOT give the same result for this example.
This is one of the funny Verilog XL interpretations that most simulators
will follow if they want to be XL compliant. XL evaluates wire assign
immediately whereas continuos assign is evaluated after the initial
statement is completed.

So Example A displays 'x' and Example B displays '1' for most simulators.

Per Edstrom

Quote:

> Without experimenting this I can say that it is yes. Both of them should
> behave the same. There may be a little inconsitency factor between
> different simulators about how they implement these structures.

> cheers,
> Sreekanth

> > Here is a \$2000 question:

> > Will these two examples always give the same result?

> > Example A:

> > assign a=b;

> > initial begin
> > b=1;
> > c=a;
> > \$display("c=%b",c);
> > end

> > Example B:

> > wire a=b;

> > initial begin
> > b=1;
> > c=a;
> > \$display("c=%b",c);
> > end

> > Per Edstrom

Thu, 29 Aug 2002 03:00:00 GMT
wire assign vs continous assign

Quote:

> Before I tell you the answer, what have you
> arranged to make payment for the \$2,000.00?

Probably same thing I've arranged for somewhat related post ;).

Cheers and happy UseNet browsing,

Anatoly Gelman

Thu, 29 Aug 2002 03:00:00 GMT
wire assign vs continous assign

Quote:

> No, most simulators will NOT give the same result for this example.
> This is one of the funny Verilog XL interpretations that most simulators
> will follow if they want to be XL compliant. XL evaluates wire assign
> immediately whereas continuos assign is evaluated after the initial
> statement is completed.

> So Example A displays 'x' and Example B displays '1' for most simulators.

This it truly amazing. What does IEEE-1364 say in this case?
Verilog keeps amazing me with mountains of non-intuitive behavior.

Cheers!!!

Anatoly Gelman

Quote:
> Per Edstrom

> > Without experimenting this I can say that it is yes. Both of them should
> > behave the same. There may be a little inconsitency factor between
> > different simulators about how they implement these structures.

> > cheers,
> > Sreekanth

> > > Here is a \$2000 question:

> > > Will these two examples always give the same result?

> > > Example A:

> > > assign a=b;

> > > initial begin
> > > b=1;
> > > c=a;
> > > \$display("c=%b",c);
> > > end

> > > Example B:

> > > wire a=b;

> > > initial begin
> > > b=1;
> > > c=a;
> > > \$display("c=%b",c);
> > > end

> > > Per Edstrom

Thu, 29 Aug 2002 03:00:00 GMT
wire assign vs continous assign
I agree!

It might boil down to what is considered the "gate domain" in
Verilog XL. I believe that wire assign is part of their gate domain
but continuos assign is not.

Since Verilog XL always evaluates the gate domain first and
then the rtl domain, they have to update the wire assign immediately.

Also beware of races between flip-flops that is described in udp form
and flip flops described in rtl form. If there is no timing involved the
udp flip-flop evaluates first and then the rtl flop-flop. This can cause
the rtl flip-flop to latch the new value.

So mixing rtl and gate-level can sometimes have unexpected side effects
such as these.

Per Edstrom

Quote:
> This it truly amazing. What does IEEE-1364 say in this case?
> Verilog keeps amazing me with mountains of non-intuitive behavior.

> Cheers!!!

> Anatoly Gelman

Thu, 29 Aug 2002 03:00:00 GMT
wire assign vs continous assign

Quote:
> So mixing rtl and gate-level can sometimes have unexpected side effects
> such as these.

> Per Edstrom

Hi!

Also using zero-delay gates can be funny!
A few weeks ago I have seen 0 ns wide glitch which
was triggering a dflop... :-)
Almost undetectable!

Robert

Fri, 30 Aug 2002 03:00:00 GMT
wire assign vs continous assign

Quote:

> > So mixing rtl and gate-level can sometimes have unexpected side

> Also using zero-delay gates can be funny!
> A few weeks ago I have seen 0 ns wide glitch which
> was triggering a dflop... :-)
> Almost undetectable!

Actually this is a more general problem - not really RTL vs. gates - while verilog appears
to transition all edges together in practice a particular simulator really transitions
each sequentially (in some undefined order) - and all within the same \$time quantum - this

before everything has become stable and it's outputs may wander around for a while - this
is not unlike the glitching the output of a real-world combinatorial net might experience
after it's inputs change.

something like this it will see all the edges
and act on them (unlike the real world where metastability might creep in) - particularly
{*filter*} are 0-time transitions on clocks that do things like 0->x->1 which can cause UDPs to
glitch to Xs if they are not written correctly (although one might argue that this is a
good thing because a clock shouldn't be glitching ....)

Paul Campbell

Fri, 30 Aug 2002 03:00:00 GMT

 Page 1 of 1 [ 9 post ]

Relevant Pages