Phone Conference P1450

Phone Conference P1450.1 Working Doc Subgroup
Thurs August 29, 10:00 am PDT

Attendees:
Peter Wohl
Greg Maston
Tony Taylor
Jim Teisher
Doug Sprague

Documents
p1450.1 D14 draft 8/1.
D14 review-resolution document 8/6.
Greg - writeup on additional parallel handling, distributed in email
and enclosed below.

Agenda
Starting with the agenda mailed by Tony:

- ITC breakfast meeting on Thur
- LockStep definition
- comments on current writeup
- greg to prepare new info on BreakPoint and signal sharing
- pattern merging
- move to D15? (and reset change bars)

ITC meetings
Two meetings:
- Working Group on Monday
- General STIL status meeting Thurs morn breakfast

Draft 14->15
Working Group approves to clear the changes and start a new Draft 15.

BreakPoint and Shared Signals
Greg started to review the parallel additions document he distributed
just before the meeting started (see attachment at end of these minutes)..

Using BreakPoints for procedure/macro synchronization was understood
with little additional discussion.

One typo was identified in the original distribution of the additional
parallel pattern handling document; Greg did not change one of the
example references from "Release" to "AllowInterLeave". This has been
corrected in the document below.

The AllowInterLeave option raised more disccusion. Peter identified a
functional discontinuity between non-parallel procedure definitions
and parallel procedure definitions, requiring (in general) a different
type of procedure to be defined for the two contexts. There is a
discontinuity in these constructs - the very identification of a
shared signal, when that signal is owned exclusively in a standalone
environment - is fundamental to this disconnect. Peter also identified
that the existing 3 procedures presented in the "cooperative handling"
context could be expressed as an equivalent single procedure across
all 3 contexts. Jim proposed an alternate approach of separating
shared signals into a 4th procedure (and corresponding pattern set to
invoke this procedure), rather than mixing them into the original
procedures, as an alternate strategy of supporting the shared signals
without requiring an interleaving behavior. This methodology works
when the shared signals are being created as part of the integration
process (i.e., the signals do not exist in the original tests but are
part of the infrastructure to support the integration of the two
cores). Greg identified one context of this situation, where an output
of two separate cores is muxed together and the control of the mux is
a new signal that is shared between these two cores to allow each core
the access to that signal as necessary to test it's outputs. Doug
identified that perhaps a set of rules (or a usage model) might be
sufficient to address these issues as well.

Due to time, the discussion did not proceed into the non-cooperative
handling section of this document, that requires both interleave and
breakpoint operations (as presented here) to address. This was left
for individual review and consideration, as well as contemplation of
the additional points raised above, with additional discussion at the
next meeting.

Meeting adjourned at 11:00 am PDT.

Greg's additional parallel pattern handing proposal

Intro/Background -

LockStepped parallel patterns allow a CERTAIN level of flexibility
in pattern execution, however they have problems if a signal is
"shared" between multiple parallel contexts... if the signal is
driven to the same state in all contexts, then there is no
problem. But if the signal needs to be driven from one context, and
then driven from the other context, there are problems with STIL
semantics to allow this. The following extensions are defined to
support this behavior.

Here's the fundamental behavior that I would like to enforce:

- A Signal can only be specified once in a Vector. There is no specified
resolution if a Signal is driven multiple times, but there is no resolution
needed if all references to that Signal specify the same WFC (redundancy is
OK, but if the signal is driven to different values in the Vector there is no
specified resolution; "last" doesn't win because I can't tell you what "last"
is, especially in parallel contexts (next point).

Here's the extended definition of a vector in parallel operation:

- A Vector is the sum-total of previous states and current assignments to all
signals in a STIL file running a common WaveformTable. In a parallel LockStep
context, this means that all Vectors in parallel are essentially treated as a
single, larger Vector (it does not mean that the implementation needs to be
done this way, just that the "view" of the data can be as a single Vector).
This concept is critical to allow test environments without parallelism to
support LockStep behavior -- and that is the ultimate goal of LockStep
constraints.

So here goes:

LockStep handling of Shared Signals - Proposal

Add to the appropriate sections:

under Pattern Additions, add:

BreakPoint -
The BreakPoint functionality is as defined in STIL0, with additional
behaviors to support parallel operation of Patterns under a
ParallelPatList block. See "LockStep Pattern/Macro Alignment" and
"LockStep handling of Shared Signals" for definition of these
extensions.

AllowInterLeave SigRef; **new statement**
This statement identifies a set of Signals that may be used in the
following context (Pattern, Procedure, or Macro) but which may not
be referenced by the first Vector of that context. Any signal
identified as an "interleaved" signal shall not maintain the last
defined WFC on that signal (no implicit persistence), but each
resolved Vector shall define a WFC for that signal. The
AllowInterLeave statement is used only in contexts that are being
executed under a ParallelPatList block with LockStep, and the
"interleaved" signal is being shared between multiple parallel
executions. This statement, when present, shall appear before the
first Vector of the context. See "LockStep handling of Shared
Signals" for definition of this behavior.

under the LockStep elaborations, add:

LockStep Pattern/Macro Alignment
--------------------------------
LockStepped parallel patterns enter Procedure and Macro calls at the
same time, as stated above. To facilitate the alignment of entering
procedure and macro calls, the BreakPoint statement may be applied in
parallel lockstepped contexts, to enforce a common exit of procedures
and macros across parallel patterns. The BreakPoint statement is
placed at the end of a Procedure to allow synchronization across
parallel procedures when the Vector count in each Procedure
differs. Take for example:

Proc A { Proc B { Proc C {
V { sA=1; } V { sB=1; } V { sC=1; } (1)
V { sA=0; } V { sB=0; } V { sC=0; } (2)
V { sA=1; } V { sB=1; } V { sC=1; } (3)
V { sA=0; } BreakPoint { BreakPoint { (4)
V { sA=1; } V { sB=0; }} V { sC=0; }} (5)
BreakPoint { } }
V {sA=1; }}
}

This generates:

V ( sA=1; sB=1; sC=1; } // (1)
V ( sA=0; sB=0; sC=0; } // (2)
V ( sA=1; sB=1; sC=1; } // (3)
V ( sA=0; sB=0; sC=0; } // (4) - (B,C) in Break
V ( sA=1; sB=0; sC=0; } // (5) - (B,C) in Break

When BreakPoints are applied in this context, they shall define a
single Vector in the BreakPoint block, with the Signal values
necessary to maintain the current state of the portion of the design
affected by this procedure.

LockStep handling of Shared Signals
-----------------------------------
Shared signals require no special handling if the signal is driven
uniquely or to the same value across multiple parallel contexts AND
the contexts do not rely on individual BreakPoint operations to
synchronize exit. This is called "cooperative handling" of shared
signals. For example:

Proc A { Proc B { Proc C {
AllowInterLeave sigA; AllowInterLeave sigA; AllowInterLeave sigA;
V { sigA=1; sA=1; } V { sB=1; } V { sC=1; }
V { sA=0; } V { sigA=0; sB=0; } V { sC=0; }
V { sA=1; } V { sB=1; } V { sigA=1; sC=1; }
} } }

This generates the composite Vectors when these three are run in parallel:

V ( sigA=1; sA=1; sB=1; sC=1; } // sigA from Proc A
V ( sigA=0; sA=0; sB=0; sC=0; } // sigA from Proc B
V ( sigA=1; sA=1; sB=1; sC=1; } // sigA from Proc C

Signals being driven from multiple parallel contexts require special
handling if the parallel contexts drive those Signals to different
values. The mechanism to enforce "single ownership" of a shared Signal
is an interleaving process of the parallel blocks, that relies on
specific BreakPoint statements before and after the shared Signal is
accessed. Also, shared Signals shall be identified in each context
that may assert a value on that shared Signal during the procedure
execution.

Consider the situation where two procedures need to take a shared
signal to different states:

Proc A { Proc B {
AllowInterLeave sigA; AllowInterLeave sigA;
V { sigA=1; sA=1; } V { sigA=0; sB=1; }
} }

As defined, this is an error if these procedures execute in
parallel. However, if the procedures defined a "stable state" AROUND
driving a shared signal:

Proc A { Proc B {
AllowInterLeave sigA; AllowInterLeave sigA;
BreakPoint { V { sA=0; }} BreakPoint { V { sB=0; }}
V { sigA=1; sA=1; } V { sigA=0; sB=1; }
BreakPoint { V { sA=0; }} BreakPoint { V { sB=0; }}
} }

Then these sets of BreakPoints can be applied. Let's assume Proc A gets
evaluated first, then the Vector sequence is:

V { sigA=1; sA=1; sB=0; } // sB=0 from initial BreakPoint in B
V { sigA=0; sA=0; sB=1; } // sA=0 from second BreakPoint in A

If Proc B gets evaluated first, then the Vectors would be:

V { sigA=0; sA=0; sB=1; } // sA=0 from initial BreakPoint in A
V { sigA=1; sA=1; sB=0; } // sB=0 from second BreakPoint in B

There is no defined order of evaluation across procedures, so a
"pre-condition BreakPoint" and a "post-condition BreakPoint" are necessary
for each procedure, depending on whether that procedure has executed it's
block of statements or not.

The basic construct is:
- for procedures with AllowInterLeave signals,
- either it is known that ALL parallel procedures are written to cooperate
with each other,
- or:
- each time an InterLeaved signal is assigned in that procedure, the block of
vectors necessary to support that operation are enclosed in a "pre-condition"
BreakPoint and a "post-condition" BreakPoint. This block of Vectors will be
executed with all other procedures executing a BreakPoint condition.

It is manditory that any procedure executed in a parallel context with
another procedure that has a AllowInterLeave statement, contain at least one
BreakPoint at the end of the procedure to allow other procedures driving
shared signals to execute.

If all procedures that execute in parallel are not written to cooperatively
handle a shared signal, then the block of Vectors where the shared signals
are driven in each procedure must be sandwiched between 2 BreakPoint
statements. The first BreakPoint establishes a quiscent state for this
procedure BEFORE this set of Vectors executes; the second BreakPoint
establishes a quiscent state for this procedure AFTER this set of Vectors
executes.