Newbie: blocking/non-blocking assignments

T

Taras_96

Guest
Hi all,

I was going through this verilog example, and I was wondering if
anyone could explain it to me. It concerns the varying types of
assignments that can be done in verilog:

module delay; //1
reg a,b,c,d,e,f,g,bds,bsd; //2
initial begin //3
a = 1; b = 0; // No delay control. //4
#1 b = 1; // Delayed assignment. //5
c = #1 1; // Intra-assignment delay. //6
#1; // Delay control. //7
d = 1; // //8
e <= #1 1; // Intra-assignment delay, nonblocking assignment //9
#1 f <= 1; // Delayed nonblocking assignment. //10
g <= 1; // Nonblocking assignment. //11
end //12
initial begin
#1 bds = b;
end // Delay then sample (ds). //13
initial begin
bsd = #1 b;
end // Sample then delay (sd). //14

initial begin
$display("t a b c d e f g bds bsd"); //15
$monitor("%g",$time,,a,,b,,c,,d,,e,,f,,g,,bds,,,,bsd);
end //16
endmodule //17

OUTPUT:
t a b c d e f g bds bsd
0 1 0 x x x x x x x
1 1 1 x x x x x 1 0
2 1 1 1 x x x x 1 0
3 1 1 1 1 x x x 1 0
4 1 1 1 1 1 1 1 1 0

I tried explaining the results by myself:

t = 0.

Events:

1 assigned to a
0 assigned to b

Scheduled:

b is scheduled to be assigned to 1
bds is scheduled to be assigned the value of b
bsd is scheduled to be assigned the value of current b (0)

t = 1.

Execution of scheduled events:
b is assigned one
bds is assigned one (isn't this a race condition??) *
bsd is assigned 0

Events:

Scheduled:
c is scheduled to be assigned 1

t = 2:

Execution of sheduled events:
c is assigned one

Event:
encounters #1

t = 3:

Events:
d is assigned one
don't know about the rest of the statements **

QUESTION ONE (*)

wouldn't the statements on lines 5 and 13 create a race condition? IE:
for t = 1, b must be assigned one and also bsd = b. Now if bsd = b is
executed first, then bsd = 0 (since b = 1 hasn't been executed yet).
Alternatively, if b = 1 is executed first, wouldn't bsd = b result in
bsd = 1?

QUESTION TWO (**)

I'm not exactly sure what happens at t = 3. During this time, d is
assigned one. Why does the change forced by g <= 1 not show up until
t = 4? What is the difference between the three non-blocking
assignments (lines 9,10,11)? They all seem to have the same result...
How does the scheduler 'read' the three statements?

Any help would be greatly appreciated.

Cheers

Taras
 
Verilog code and questions snipped...

Q1: Yes lines 5 and 13 imply a race condition. The simulator may
resolve the race to give the results shown or giving the results with
bsd = 1. It is not even required to be consistent and may sometimes
give one result and other times the other in an unpredictable fashion.

Q2: Line 10 is the key here. It imposes a delay on the execution of
not only line 10, but all following lines including line 11. If you
reorder lines 10 and 11, f and g will transition at different times.
Reordering 9 and 10, will delay the assignment to e until a time-step
later.

Of course, your example shows a big flaw in verilog as a hardware
design language. You don't really want complicated scheduling
behaviors affecting the execution of your chip, especially as there
aren't circuit elements that can model each and every permutation you
can write in verilog. It is really hard to build a circuit where one
signal trails another by a precise period of time (that isn't
represented by a clock signal) unless you are playing analog games.

On the other hand, as a simulation language delays make sense. You
may find that one signal follows another by a precise period of time
(perhaps due to the analog properties) and wish to model that. That's
not the same thing as expecting to be able to design that (and have
the synthesizer generate it for you).

This is why some people suggest that one shouldn't attempt to
"program" in verilog when designing a chip, but instead think in
hardware terms. You can write verilog which simulates perfectly and
solves some problem, but which cannot be synthesized into a chip that
has the same behavior. However, there are dialects of verilog than
one can restrict oneself to where one knows what kind of hardware the
synthesizer will create, and using one of them one is assured that the
hardware will produce a chip that can be synthesized. Most of the
synthesizable dialects do not have arbitrary mixtures of delays,
blocking, and non-blocking assignments.

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
19 Bronte Way #33M voice : (508) 435-5016
Marlboro, MA 01752 USA fax : (508) 251-2347 (24 hours)
------------------------------------------------------------------------------
 
Q2: Line 10 is the key here. It imposes a delay on the execution of
not only line 10, but all following lines including line 11. If you
reorder lines 10 and 11, f and g will transition at different times.
Reordering 9 and 10, will delay the assignment to e until a time-step
later.
Click to expand...
So, continuing on with the format of my previous analysis, it would go
something like this:

t = 3:

Events:
d is assigned one
enounters #1 on line 10

Scheduled:
e is scheduled to be assigned one
f is scheduled to be assigned the RH value

t = 4
Execution of scheduled events

e is assigned one
f is assigned the RH value (one)

Events:
g is assigned one

FINISH

I guess it would be equivalent to writing:

#1;
f <= 1;
g <= 1;

Thanks for your help!

Taras
 
I guess it would be equivalent to writing:

#1;
f <= 1;
g <= 1;
Click to expand...
Yes, as far as I know. The non-blocking operator does not prevent
future statements in the same block from executing, but the
(left-hand-side) delay does.

-Chri
 
Please read the excellent paper by Cliff Cummings on this suject:
http://www.sunburst-design.com/papers/
Verilog Nonblocking Assignments With Delays, Myths & Mysteries

----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Using PSL/SUGAR with Verilog and VHDL
Guide to Property Specification Language for ABV, 2003 isbn 0-9705394-4-4
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top