From: sjmeyer@pragmatic-c.com
Date: Wed Sep 20 2000 - 08:57:32 PDT
Quoting Joseph P. Skudlarek (jskud@cypress.com):
> 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
It seems to me that your example makes my point that time token movement
requires no stopping once started (a kind of digital modeling time flow
movement), i.e. users and various tools need to know that when x event control
"wakes up", y has value 1'b0. Otherwise, the number of alternative states
becomes in my view too large and too hard to understand.
/Steve
>
> 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 ------
-- 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
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:13 PDT
and
sponsored by Boyd Technology, Inc.