Re: Fwd: Verilog Races in Combinatorial Logic

From: James A. Markevitch (jam@magic.com)
Date: Thu Sep 21 2000 - 07:22:55 PDT


Let me take the position of Devil's advocate here:

Shalom's example shows a common programming practice which will work in
a single-threaded environment. However, even with standard programming
languages, if each of the "initial" blocks were a separate thread, then
that "standard programming language" would have the same issues as Verilog.
Namely, there would be a potential races with the variable "i".

If the "initial" blocks were replaced by "always" blocks, then the example
wouldn't be synthesizable; one could argue that the "basic programming
style" is already broken, it's just not as obvious when "initial" statements
are used. [By the way, when I was first using Verilog, re-using a loop index
in an always block was one of the non-obvious mistakes I made].

Note that there are (at least) two mechanisms available to make the example
work: use different loop index variables for the two loops, or put both
loops into a single "initial" block. These mechanisms are consistent with
programming in a multi-threaded environment.

In summary: the Verilog language describes each "initial" (and "always")
block to be the equivalent of a separate thread; therefore, multi-threaded
programming style should apply, not single-threaded.

James Markevitch

> We must not limit ourselves to hardware descriptions.
>
> I like to use the following example (one of several which emphasize the point):
>
> initial begin
> for (i = 0; i < 100; i = i + 1) array1[i] = i ; // initialize array1
>
> initial begin
> for (i = 0; i < 527; i = i + 1) array2[i] = 2*i + 4 ; // initialize array2
>
> This is a very common programming practice.
> "i" is used as a loop index, a general purpose variable.
>
> The programmer will assume that one of the array initializations will be perform
> ed,
> then the other. It does not matter what order.
>
> What is important is that the execution not be interleaved, because then the val
> ue of "i"
> will not be preserved within the loop.
>
> We cannot declare such basic programming styles non-deterministic,
> but that is what the standard indeed says today.
>
> Shalom



This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:54:13 PDT and
sponsored by Boyd Technology, Inc.