From: Joseph P. Skudlarek (jskud@cypress.com)
Date: Thu Sep 21 2000 - 08:07:43 PDT
Bottom line: The meaning of a Verilog description is a real issue; the
current overly-inclusive specification does not ensure current practice
behaves as intended, nor does it support a useful modeling style. If
the standard is to meet the goals of being clear, complete, and correct,
then these issues must be addressed.
Given the importance (after all, simulation semantics are essential to
using Verilog) and the uncertainty (experts disagree on what's specified
-- how can we expect the user community to embrace the standard?), I
agree that it's worth delaying the standard to resolve these issues.
Specific comments follow. /Jskud
------------------------------------------------------------------------
Joseph P. SKUDLAREK Jskud@cypress.com direct 503/526-1874
Data Communications Division 9125 SW Gemini Dr #200 FAX 503/626-6688
Cypress Semiconductor Corp Beaverton Oregon 97008 www.cypress.com
------------------------------------------------------------------------
You're absolutely right, Shalom, the example you provide
> 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
hould be totally deterministic regarding the resulting values in array1
and array2 after initialization. The essential point which the standard
does not address is whether or not i is a "shared variable".
To support the natural interpretation, i must not be a shared variable
if i is declared integer. But if i is declared reg, there is a problem,
since given the scoping rules, i is a shared register, making it a
shared variable, making it possible for the loops to interact.
I make the distinction between reg and integer, because (1364-1995)
A register is an abstraction of a data storage element. (p. 3-2)
An integer is a general purpose register used for manipulating
quantities that are not regarded as hardware
registers. (p. 3-12)
but this may be splitting hairs that don't really exist (yet).
/Jskud
>------ Begin Included Message ------
> Date: Thu, 21 Sep 2000 14:44:43 +0300
> From: "Shalom Bresticker (r50386)" <r50386@email.sps.mot.com>
> Organization: Motorola Semiconductor Israel, Ltd.
> To: Jskud@cypress.com
> CC: sjmeyer@pragmatic-c.com, stuart@sutherland-hdl.com, sharp@cadence.com,
> btf@boyd.com
> Subject: Re: Fwd: Verilog Races in Combinatorial Logic
>
>
> --------------1989CA4BC870A91F2616C01D
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> 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 performed,
> then the other. It does not matter what order.
>
> What is important is that the execution not be interleaved, because then the value 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
>
>
> "Joseph P. Skudlarek" wrote:
>
> > Hi, Steve. Good point, but I see another side of things too.
> >
> > I agree that reasoning is easier if we
> >
> > know that when x event control "wakes up", y has value 1'b0
> >
> > but that's not what hardware does, so that's not the meaning that
> > Verilog should have.
> >
> > A real world example which shows this uncertain behavior is when using
> > Verilog to model at a higher level of abstraction. Let z be a memory
> > location which is shared between two independent subsystems. Each
> > always block represents a subsystem. It is certainly possible for the
> > execution history (where x/y/z is the after value) to be either
> >
> > Fred Ginger x y z
> > -------------------------------------------------
> > z = 0 x0 y0 0
> > x = y y0 y0 0
> > y = z y0 0 0
> > z = 1 y0 0 1
> > -------------------------------------------------
> >
> > -or-
> >
> > Fred Ginger x y z
> > -------------------------------------------------
> > z = 0 x0 y0 0
> > x = y y0 y0 0
> > z = 1 y0 y0 1
> > y = z y0 1 1
> > -------------------------------------------------
> >
> > Both are legal outcomes. In once case, y has the value 0; in the other,
> > y has the value 1.
> >
> > This situation occurs because z is shared between the two processes, and
> > the accesses can interleave. It's this interleaving that is an
> > essential aspect of what (concurrent) hardware does, and what Verilog
> > must model. It's why VHDL had to specify shared variable semantics.
> > It's the nature of the beast.
> >
> > I still hold that the primary objective of the 1364 standard is to be a
> > clear, complete, and correct specification of a useful Verilog. It
> > needs to specify enough that an implementor could create a valid (and
> > useful) Verilog implementation just from the standard. It also needs to
> > describe useful guaranteed behavior well enough that users can model
> > effectively.
> >
> > I hope this helps. /Jskud
>
> --
>
> ************************************************************************
> Shalom Bresticker email: shalom@msil.sps.mot.com
> Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268
> P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890
> http://www.motorola-semi.co.il/
> ************************************************************************
>
> [[omit redundent html version]]
>
>------ End Included Message ------
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:13 PDT
and
sponsored by Boyd Technology, Inc.