Have the errors in “HDL Chip Design” by Douglas Smith ever

[Jan Decaluwe]

My copy of "HDL Chip Design" by Douglas Smith is
the ninth printing, July 2001.

The book systematically makes the error of using
blocking assignments for synchronous communication,
which results in nondeterministic code.
Non-blocking assignments should be used in this case.

Has this ever been fixed in a later printing, if any?

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

 

[Jan Decaluwe]

On 02/08/2011 04:42 PM, rickman wrote:

On Feb 8, 10:33 am, Jan Decaluwe<j...@jandecaluwe.com> wrote:
My copy of "HDL Chip Design" by Douglas Smith is
the ninth printing, July 2001.

The book systematically makes the error of using
blocking assignments for synchronous communication,
which results in nondeterministic code.
Non-blocking assignments should be used in this case.

Has this ever been fixed in a later printing, if any?

Jan


Can you explain? I've never heard that blocking assignments create
non-deterministic code. I thought that blocking assignments in
synchronous processes (or always blocks as they are called in Verilog)
produce the same result as variables in VHDL, which is perfectly
legit!

Blocking assignments *for synchronous communication*
are like shared variables in VHDL.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

 

[rickman]

On Feb 8, 10:33 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:

My copy of "HDL Chip Design" by Douglas Smith is
the ninth printing, July 2001.

The book systematically makes the error of using
blocking assignments for synchronous communication,
which results in nondeterministic code.
Non-blocking assignments should be used in this case.

Has this ever been fixed in a later printing, if any?

Jan

Can you explain? I've never heard that blocking assignments create
non-deterministic code. I thought that blocking assignments in
synchronous processes (or always blocks as they are called in Verilog)
produce the same result as variables in VHDL, which is perfectly
legit!

Rick

 

[Paul Uiterlinden]

rickman wrote:

On Feb 8, 10:33 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
My copy of "HDL Chip Design" by Douglas Smith is
the ninth printing, July 2001.

The book systematically makes the error of using
blocking assignments for synchronous communication,
which results in nondeterministic code.
Non-blocking assignments should be used in this case.

Has this ever been fixed in a later printing, if any?

Jan


Can you explain? I've never heard that blocking assignments create
non-deterministic code. I thought that blocking assignments in
synchronous processes (or always blocks as they are called in Verilog)
produce the same result as variables in VHDL, which is perfectly
legit!

Except that in VHDL variables are not used for communication between
processes. Unless you use a shared variable, which leaves the door open for
race conditions (undeterministic behaviour).

The same goes for blocking assignments in Verilog when used on a register
that is assigned in one always block and read in another always block. The
value that the receiving block sees depends on the execution order of the
two always blocks. In other words: a race condition. In other words:
undeterministic behaviour.

Non blocking assignments avoids this situation because updating the register
is postponed after the always block have run. That is like the delta delay
in a signal assignment in VHDL.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

[Jan Decaluwe]

On 02/08/2011 11:30 PM, glen herrmannsfeldt wrote:

rickman<gnuarm@gmail.com> wrote:
On Feb 8, 10:33 am, Jan Decaluwe<j...@jandecaluwe.com> wrote:
My copy of "HDL Chip Design" by Douglas Smith is
the ninth printing, July 2001.

The book systematically makes the error of using
blocking assignments for synchronous communication,
which results in nondeterministic code.
Non-blocking assignments should be used in this case.

(snip)
Can you explain? I've never heard that blocking assignments create
non-deterministic code. I thought that blocking assignments in
synchronous processes (or always blocks as they are called in Verilog)
produce the same result as variables in VHDL, which is perfectly
legit!

As I understand it, they synthesize correctly, but for simulation
the results can vary.

The purpose of synthesis is to generate a gate level that
matches the RTL behavior. When the RTL is nondeterministic,
that is impossible, which makes it meaningless to talk about
"correct" synthesis.

When I was first learning verilog, and

even though the book included non-blocking assignment, the usual
solution was to put a #1 delay on each signal.

Consider what happens in real logic: A clock edge causes a FF
to latch its input and change its output. Even more, consider
zero hold time, such that the input can change right at the clock
edge. Propagation delay internal to, and between, FFs allows
real circuits to work with zero hold time, and even clock skew from
imperfect clock trees. So adding delay seems to be more physical.

However, with blocking assignment it matters what order the
assignments are done within a block. Personally, I like to put
FF's in their own module, and not worry about such, except for
state machines. Otherwise, I write the assignment is the
reverse order of data propagation, such that even with blocking
assignment the results are correct. That makes more sense when
reading the code sequentially, especially if one is used to reading
a sequential programming language.

Here you are mixing different issues. As long as the blocking
assignments are *local*, there is no problem with determinism
nor synthesis, irrespective of the order of the assignments.

Does the book mentioned have the #1 delay on signals?

No.

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

On Feb 8, 10:33 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
My copy of "HDL Chip Design" by Douglas Smith is
the ninth printing, July 2001.

The book systematically makes the error of using
blocking assignments for synchronous communication,
which results in nondeterministic code.
Non-blocking assignments should be used in this case.

(snip)

Can you explain? I've never heard that blocking assignments create
non-deterministic code. I thought that blocking assignments in
synchronous processes (or always blocks as they are called in Verilog)
produce the same result as variables in VHDL, which is perfectly
legit!

As I understand it, they synthesize correctly, but for simulation
the results can vary. When I was first learning verilog, and
even though the book included non-blocking assignment, the usual
solution was to put a #1 delay on each signal.

Consider what happens in real logic: A clock edge causes a FF
to latch its input and change its output. Even more, consider
zero hold time, such that the input can change right at the clock
edge. Propagation delay internal to, and between, FFs allows
real circuits to work with zero hold time, and even clock skew from
imperfect clock trees. So adding delay seems to be more physical.

However, with blocking assignment it matters what order the
assignments are done within a block. Personally, I like to put
FF's in their own module, and not worry about such, except for
state machines. Otherwise, I write the assignment is the
reverse order of data propagation, such that even with blocking
assignment the results are correct. That makes more sense when
reading the code sequentially, especially if one is used to reading
a sequential programming language.

Does the book mentioned have the #1 delay on signals?

-- glen

 

[Stephen Williams]

On 02/08/2011 04:34 PM, rickman wrote:

Actually, this is "stimulating the little grey cells" as Poirot would
say. This problem still exists with non-blocking assignments. VHDL
deals with this by using delta delays, delays that postpone events,
but use no time. So when a process runs the outputs of non-blocking
signal assignments in process A are scheduled for time t+delta. Since
process B is guaranteed to run and look at the inputs at time t,
before time t+delta, it will always see the same data. I recall that
Verilog has nothing like the delta delay to deal with this.

The non-blocking assignments to exactly this. Non-blocking assign
events are placed into a queue AFTER the current set of events, so
all active code will see the BEFORE-assignment values.

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

 

[rickman]

On Feb 8, 12:54 pm, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:

rickman wrote:
On Feb 8, 10:33 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:
My copy of "HDL Chip Design" by Douglas Smith is
the ninth printing, July 2001.

The book systematically makes the error of using
blocking assignments for synchronous communication,
which results in nondeterministic code.
Non-blocking assignments should be used in this case.

Has this ever been fixed in a later printing, if any?

Jan

Can you explain?  I've never heard that blocking assignments create
non-deterministic code.  I thought that blocking assignments in
synchronous processes (or always blocks as they are called in Verilog)
produce the same result as variables in VHDL, which is perfectly
legit!

Except that in VHDL variables are not used for communication between
processes. Unless you use a shared variable, which leaves the door open for
race conditions (undeterministic behaviour).

The same goes for blocking assignments in Verilog when used on a register
that is assigned in one always block and read in another always block. The
value that the receiving block sees depends on the execution order of the
two always blocks. In other words: a race condition. In other words:
undeterministic behaviour.

Non blocking assignments avoids this situation because updating the register
is postponed after the always block have run. That is like the delta delay
in a signal assignment in VHDL.

Actually, this is "stimulating the little grey cells" as Poirot would
say. This problem still exists with non-blocking assignments. VHDL
deals with this by using delta delays, delays that postpone events,
but use no time. So when a process runs the outputs of non-blocking
signal assignments in process A are scheduled for time t+delta. Since
process B is guaranteed to run and look at the inputs at time t,
before time t+delta, it will always see the same data. I recall that
Verilog has nothing like the delta delay to deal with this. But I
have to assume that the simulation engines implement something like
this anyway. No?

Rick

 

[Jan Decaluwe]

On 02/09/2011 01:34 AM, rickman wrote:

On Feb 8, 12:54 pm, Paul Uiterlinden<puit...@notaimvalley.nl> wrote:
rickman wrote:
On Feb 8, 10:33 am, Jan Decaluwe<j...@jandecaluwe.com> wrote:
My copy of "HDL Chip Design" by Douglas Smith is
the ninth printing, July 2001.

The book systematically makes the error of using
blocking assignments for synchronous communication,
which results in nondeterministic code.
Non-blocking assignments should be used in this case.

Has this ever been fixed in a later printing, if any?

Jan

Can you explain? I've never heard that blocking assignments create
non-deterministic code. I thought that blocking assignments in
synchronous processes (or always blocks as they are called in Verilog)
produce the same result as variables in VHDL, which is perfectly
legit!

Except that in VHDL variables are not used for communication between
processes. Unless you use a shared variable, which leaves the door open for
race conditions (undeterministic behaviour).

The same goes for blocking assignments in Verilog when used on a register
that is assigned in one always block and read in another always block. The
value that the receiving block sees depends on the execution order of the
two always blocks. In other words: a race condition. In other words:
undeterministic behaviour.

Non blocking assignments avoids this situation because updating the register
is postponed after the always block have run. That is like the delta delay
in a signal assignment in VHDL.

Actually, this is "stimulating the little grey cells" as Poirot would
say. This problem still exists with non-blocking assignments. VHDL
deals with this by using delta delays, delays that postpone events,
but use no time. So when a process runs the outputs of non-blocking
signal assignments in process A are scheduled for time t+delta. Since
process B is guaranteed to run and look at the inputs at time t,
before time t+delta, it will always see the same data. I recall that
Verilog has nothing like the delta delay to deal with this. But I
have to assume that the simulation engines implement something like
this anyway. No?

It is true that non-blocking assignments do not solve the
problem in general. The reason is that, unlike VHDL, there
is no separate queue for value update events and process evaluations.
(Thanks to Jonathan Bromley for helping me to understand this
recently).

However, non-blocking assignments do add a delta cycle delay,
and therefore solve the problem for the special but all-important
case of synchronous communication.

Now, coming back to my question ...

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

 

[rickman]

On Feb 9, 3:24 am, Jan Decaluwe <j...@jandecaluwe.com> wrote:

On 02/09/2011 01:34 AM, rickman wrote:



On Feb 8, 12:54 pm, Paul Uiterlinden<puit...@notaimvalley.nl>  wrote:
rickman wrote:
On Feb 8, 10:33 am, Jan Decaluwe<j...@jandecaluwe.com>  wrote:
My copy of "HDL Chip Design" by Douglas Smith is
the ninth printing, July 2001.

The book systematically makes the error of using
blocking assignments for synchronous communication,
which results in nondeterministic code.
Non-blocking assignments should be used in this case.

Has this ever been fixed in a later printing, if any?

Jan

Can you explain?  I've never heard that blocking assignments create
non-deterministic code.  I thought that blocking assignments in
synchronous processes (or always blocks as they are called in Verilog)
produce the same result as variables in VHDL, which is perfectly
legit!

Except that in VHDL variables are not used for communication between
processes. Unless you use a shared variable, which leaves the door open for
race conditions (undeterministic behaviour).

The same goes for blocking assignments in Verilog when used on a register
that is assigned in one always block and read in another always block. The
value that the receiving block sees depends on the execution order of the
two always blocks. In other words: a race condition. In other words:
undeterministic behaviour.

Non blocking assignments avoids this situation because updating the register
is postponed after the always block have run. That is like the delta delay
in a signal assignment in VHDL.

Actually, this is "stimulating the little grey cells" as Poirot would
say.  This problem still exists with non-blocking assignments.  VHDL
deals with this by using delta delays, delays that postpone events,
but use no time.  So when a process runs the outputs of non-blocking
signal assignments in process A are scheduled for time t+delta.  Since
process B is guaranteed to run and look at the inputs at time t,
before time t+delta, it will always see the same data.  I recall that
Verilog has nothing like the delta delay to deal with this.  But I
have to assume that the simulation engines implement something like
this anyway.  No?

It is true that non-blocking assignments do not solve the
problem in general. The reason is that, unlike VHDL, there
is no separate queue for value update events and process evaluations.
(Thanks to Jonathan Bromley for helping me to understand this
recently).

However, non-blocking assignments do add a delta cycle delay,
and therefore solve the problem for the special but all-important
case of synchronous communication.

Now, coming back to my question ...

I thought you got the answer to your question, it is "no".

I can't say I understand what you describe above. I've been told
there are no good texts on Verilog, so the Douglas Smith book is the
only one I have. I suppose I can wade through the Verilog spec, but
that has got to be a painful exercise, at least if it is written
anything like the VHDL spec.

What do you mean by "It is true that non-blocking assignments do not
solve the problem in general." What part of the problem is not solved
by non-blocking assignments?

I am actually surprised by your statement of Verilog having delta
delay steps. I had read, mostly likely here or in one of the related
newsgroups that this is a major difference between VHDL and Verilog.
Is this part of the spec or just how the vendors implement it?

Rick

 

[Jan Decaluwe]

On 02/10/2011 06:03 AM, rickman wrote:

On Feb 9, 3:24 am, Jan Decaluwe<j...@jandecaluwe.com> wrote:
On 02/09/2011 01:34 AM, rickman wrote:



On Feb 8, 12:54 pm, Paul Uiterlinden<puit...@notaimvalley.nl> wrote:
rickman wrote:
On Feb 8, 10:33 am, Jan Decaluwe<j...@jandecaluwe.com> wrote:
My copy of "HDL Chip Design" by Douglas Smith is
the ninth printing, July 2001.

The book systematically makes the error of using
blocking assignments for synchronous communication,
which results in nondeterministic code.
Non-blocking assignments should be used in this case.

Has this ever been fixed in a later printing, if any?

Jan

Can you explain? I've never heard that blocking assignments create
non-deterministic code. I thought that blocking assignments in
synchronous processes (or always blocks as they are called in Verilog)
produce the same result as variables in VHDL, which is perfectly
legit!

Except that in VHDL variables are not used for communication between
processes. Unless you use a shared variable, which leaves the door open for
race conditions (undeterministic behaviour).

The same goes for blocking assignments in Verilog when used on a register
that is assigned in one always block and read in another always block. The
value that the receiving block sees depends on the execution order of the
two always blocks. In other words: a race condition. In other words:
undeterministic behaviour.

Non blocking assignments avoids this situation because updating the register
is postponed after the always block have run. That is like the delta delay
in a signal assignment in VHDL.

Actually, this is "stimulating the little grey cells" as Poirot would
say. This problem still exists with non-blocking assignments. VHDL
deals with this by using delta delays, delays that postpone events,
but use no time. So when a process runs the outputs of non-blocking
signal assignments in process A are scheduled for time t+delta. Since
process B is guaranteed to run and look at the inputs at time t,
before time t+delta, it will always see the same data. I recall that
Verilog has nothing like the delta delay to deal with this. But I
have to assume that the simulation engines implement something like
this anyway. No?

It is true that non-blocking assignments do not solve the
problem in general. The reason is that, unlike VHDL, there
is no separate queue for value update events and process evaluations.
(Thanks to Jonathan Bromley for helping me to understand this
recently).

However, non-blocking assignments do add a delta cycle delay,
and therefore solve the problem for the special but all-important
case of synchronous communication.

Now, coming back to my question ...

I thought you got the answer to your question, it is "no".

I can't say I understand what you describe above. I've been told
there are no good texts on Verilog, so the Douglas Smith book is the
only one I have. I suppose I can wade through the Verilog spec, but
that has got to be a painful exercise, at least if it is written
anything like the VHDL spec.

What do you mean by "It is true that non-blocking assignments do not
solve the problem in general." What part of the problem is not solved
by non-blocking assignments?

I am actually surprised by your statement of Verilog having delta
delay steps. I had read, mostly likely here or in one of the related
newsgroups that this is a major difference between VHDL and Verilog.
Is this part of the spec or just how the vendors implement it?

I have tried to explain these matters as well as I can here:

http://www.sigasi.com/content/verilogs-major-flaw

and here:

http://www.sigasi.com/content/vhdls-crown-jewel

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com