Author Message

Back when I used to do this 8 years ago,
assignments like these

begin
y <= x;
end

would be frowned upon in favor of strictly
synchronus designs like

begin
y = x;
end

Has thinking on this changed?

Ari

Tue, 22 Mar 2005 08:57:02 GMT
Both of these constructs ARE strictly synchronous.  The nuance in the
(mis)use of the blocking (=) and non-blocking (<=) operators is subtle.
A general rule is to - for synchronous logic - always use the
non-blocking operator (<=) unless you have an explicit reason to do
otherwise.

Synchronous designs step cleanly from a previous state to a next state
based on the information from the previous state.  The blocking operator
confuses this because the items *within one always block* are built-up
and ready to use for the following lines in that same always block.  In
simulation there is no guarantee of what order items in different always
blocks will be evaluated.  In synthesis it's just plain ugly.

There are a few times where - particularly in "for" loops - it's more
difficult to use the non-blocking operator and the blocking finds a use.

Many synthesizers will warn you when mixed blocking and non-blocking
operators are used in the same block.

Quote:

> Back when I used to do this 8 years ago,
> assignments like these

> begin
>         y <= x;
> end

> would be frowned upon in favor of strictly
> synchronus designs like

> begin
>         y = x;
> end

> Has thinking on this changed?

> Ari

Wed, 23 Mar 2005 00:30:39 GMT

Quote:
> Back when I used to do this 8 years ago,
> assignments like these

> begin
> y <= x;
> end

> would be frowned upon in favor of strictly
> synchronus designs like

> begin
> y = x;
> end

If you designed using blocking operators, you cannot be getting good
simulations
with this code. You would have to do something like

begin
y = #td x;
end

Otherwise , if you had something like

begin
y_s =  y;
y_ss = y_s;
y_sss = y_ss;
end

I am pretty sure your simulator will simulate with no particular order,
resulting in possibly y_sss getting y
in one clock cycle instead of 3. The ONLY way I know of getting the correct
simulation was
by adding a #td delay on each line. The delay off course has no relationship
to the actual gate delay
that will be synthesized.

On the other hand if you use non-blocking operator <= then verilog tools
will do the right thing
and you can be sure of simulating and synthesizing correctly.

Kaustabh

end

Thu, 24 Mar 2005 08:13:30 GMT

Quote:

> > Back when I used to do this 8 years ago,
> > assignments like these

> > begin
> > y <= x;
> > end

> > would be frowned upon in favor of strictly
> > synchronus designs like

> > begin
> > y = x;
> > end

> If you designed using blocking operators, you cannot be getting good
> simulations
> with this code. You would have to do something like

> begin
>   y = #td x;
>  end

> Otherwise , if you had something like

> begin
>   y_s =  y;
>    y_ss = y_s;
>   y_sss = y_ss;
> end

>>>>This design style is bad, you should try to seperate combination logic
from state element.
>>>>The problem with simulator with one flavor(order) and gate level with

other flavor can create a big headache.

- Show quoted text -

Quote:
> I am pretty sure your simulator will simulate with no particular order,
> resulting in possibly y_sss getting y
> in one clock cycle instead of 3. The ONLY way I know of getting the
correct
> simulation was
> by adding a #td delay on each line. The delay off course has no
relationship
> to the actual gate delay
> that will be synthesized.

> On the other hand if you use non-blocking operator <= then verilog tools
> will do the right thing
> and you can be sure of simulating and synthesizing correctly.

> Kaustabh

>  end

Fri, 25 Mar 2005 01:20:00 GMT

<snip>

Quote:
> Otherwise , if you had something like

> begin
>   y_s =  y;
>    y_ss = y_s;
>   y_sss = y_ss;
> end

> I am pretty sure your simulator will simulate with no particular order,
> resulting in possibly y_sss getting y
> in one clock cycle instead of 3. The ONLY way I know of getting the correct
> simulation was
> by adding a #td delay on each line. The delay off course has no relationship
> to the actual gate delay
> that will be synthesized.

</snip>

Both synthesis and simulation should produce explicitly the same result
since this construct is in a single always block.  The blocking operator
says that the first line must be evaluated before the second line.  The
second line must be evaluated and the results available before the third
line.  The result of the above code fragment is the same - in both
synthesis and simulation - as writing:

begin
y_s <= y;
y_ss <= y;
y_sss <= y;
end

That's what the blocking operator is all about.  This easy
misinterpretation is also why it's good to stick to the style with least
confusion - the non-blocking operator - where all the blocks use all the
"previous" values in parallel to evaluate the "next" values independent
of which always block evaluates what element.

Fri, 25 Mar 2005 03:55:12 GMT

 Page 1 of 1 [ 5 post ]

Relevant Pages