Re: Fwd: Verilog Races in Combinatorial Logic

From: Joseph P. Skudlarek (jskud@cypress.com)
Date: Tue Sep 19 2000 - 11:26:05 PDT

Thanks for your comments, Steve. It shows that we should clarify a more
fundamental reason *why* we talk about suspended processes, namely, to
provide parallel semantics with single thread of control (using the
single stratified event queue processing). If we introduce multiple
threads of control into the scheduling semantics, then I think we can
avoid the suspended processing descriptions; but we will have to talk
about process interleaving.

Consider this example (again):

        always @(trigger)
        begin : Fred
                z = 1'b0;
                x = y;
                y = z;
        end

        always @(x)
        begin : Ginger
                z = 1;
        end

Each always block represents a parallel block of logic. It is certainly
possible that the order of execution is interleaved. Therefore, Fred
could execute the first two statements, changing x, and Ginger could
respond, changing z, before Fred updated y with the (new) value of z.
[I know this example is not really synthesizable, but Verilog is for
modeling parallel processes, and this simple example does that.]

/Jskud

>------ Begin Included Message ------
> Date: Mon, 18 Sep 2000 21:29:18 -0700
> From: sjmeyer@pragmatic-c.com
> To: Jskud@cypress.com, stuart@sutherland-hdl.com
> Cc: shalom@msgtel1.sps.mot.com, sharp@cadence.com, btf@boyd.com
> Subject: Re: Fwd: Verilog Races in Combinatorial Logic
>
> I diagree with view that behavior in which a procedural thread can
> be stopped before the time token (maybe I using old language) move either
> to a stopping point or procedural control thread finished. I think
> only stopping points are delay control and events including such
> stopping points in enabled tasks.
>
> My reasoning is that allowed parallel behavior that maybe could improve
> computer program simulation does not match behavior of hardware.
> Procedural threads (including fork join) must become a blob of gates
> or transistors plus wires. This blob, unless explicitly coded in
> Verilog, has no computer program execution suspending semantics.
>
> I would add sentence saying that it is required that time token once
> started continues until stopped by Verilog language construct.
>
> If you remember this discussion started with someone wanting order
> of separate initial always blocks to follow XL behavior. I think
> that should not be specified since groups of gates really are
> asynchonous and order of switching is unknown (unknowable) especically
> when physical and process variations are taken into consideration.
> Just my two cents.
> /Steve
>
> Quoting Joseph P. Skudlarek (jskud@cypress.com):
> > The problem with removing arbitrarily suspended processes is how to
> > allow "follow the change" semantics across blocks, something I was told
> > that (some) Verilogs do. Also, we tried to keep the door open for
> > parallel simulation -- something not in current favor, but something we
> > didn't want to exclude.
> >
> > Consider the following.
> >
> > always @(trigger)
> > begin
> > z = 1'b0;
> > x = y;
> > y = z;
> > end
> >
> > always @(x) z = 1;
> >
> > At the end of the always @(trigger) block, will y always have the value
> > 1'b0? Or can't the assignment of x cause the immediate evaluation of
> > the "always @(x)" block, causing 1 -> z, with resumption causing z -> y?
> >
> > I see ongoing discussion and discovery regarding what is valid Verilog.
> > Obviously, the current standard doesn't define it well. We should
> > hammer out what's allowed, and get it into the standard. While we're at
> > it, it would be nice to define the semantics of bidirectional switches,
> > (ie, tran processing), an outright omission.
> >
> > The scheduling semantics should be updated to be useful. Having no
> > semantics is not useful. Having the wrong semantics is not useful.
> >
> > /Jskud
>
> --
> Steve Meyer Phone: (415) 296-7017
> Pragmatic C Software Corp. Fax: (415) 296-0946
> 220 Montgomery St., Suite 925 email: sjmeyer@pragmatic-c.com
> San Francisco, CA 94104
>
>------ 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.