Phone Conference P1450.1 Working Doc Subgroup
Thurs Sep 12, 10:00 am PDT

Attendees:
Peter Wohl
Greg Maston
Jim Teisher
Doug Sprague

Documents
Primary sources:

Greg - writeup on additional parallel handling, distributed in email
and enclosed in prior meeting's minutes (with minor corrections).
Peter - email on ScanStructure-Ref statement, enclosed in the minutes
below.

Secondary sources (current rev working docs):

p1450.1 D14 draft 8/1.
D14 review-resolution document 8/6.

Agenda
Incoming agenda was:
(a) Start-time of WG meeting at ITC.
(b) Continue discussion of parallel/shared signal handling (Greg's
email).
(c) Peter sent email on the ScanStructuresRef statement, which is a
pending issue that needs resolution, to all participants in this
meeting.

The agenda order was decided to be (a),(c), and any time left for (b).
 



(a) Dot1 WG meeting at ITC
There is a working proposal to move the STIL status meeting,
attempted to be scheduled for Thurs breakfast (but conflicts with ITC
activities), to Monday around 3-5 pm. In order to get something
accomplished in the Dot1 WG, Tony would like to start this meeting at
8 am.

Doug will not be at ITC. Peter is currently scheduled to arrive around
4 pm. Jim and Greg accepted starting the Dot1 WG meeting to 8 am. Room
is reserved but Tony doesn't know what it is yet.

The goal of this face-to-face meeting is to close on a set of open
issues in the current document. One open issue recently identified is
concern raised by Don Organ as part of the dot4 effort, about
'expression' confusion. Tony is working some changes to address these
issues and hopefully will be reviewed at this meeting.

(c) Scanstructure/chain Referencing from Patterns
Peter presented the background and his current proposal:

Background: the Dot0 "ScanChain" statement in the Patterns section
(clause 22.12 of 1450-1999) is ambiguous as currently defined,
in several ways: (1) typically multiple chains are active
for one shift; how are multiple chains indicated? (2) what is the
scoping of activity for this statement (the spec defines "for the next
set of pattern operations" - what are the next set of pattern
operations?)

This is not an issue for applying STIL data at test. This is
information used to correlate ScanStructures with pattern
"operations", which is intended to be used by STIL
generators/simulators. But it is NOT needed to execute this test and
must be treated as extra information in any STIL flow.

We are attempting to redress the dot0 limitations in dot1, with a
cleaner, simpler, and unambiguous statement or set of statements as
necessary.

Peter's proposal: Peter discussed his proposal to address this issue,
enclosed below these minutes.

Greg presented the alternate proposal, which may be summarized as:

(.) ScanStructures to be USED in a context are referenced from the
PatternBurst level, as are SignalGroups, Macros, Procedures, etc.

(.) referencing ScanStructures again in the Pattern block could be
seen as inconsistent with referencing other STIL constructs, which
tend to reference the ELEMENTS of these blocks from the Patterns. This
would tend to lead one to use the elements of this block in the
Patterns, specifically the scanchain names themselves (as currently
defined in the dot0 spec).

One alternate proposal is to just define a new ScanChain statement,
for example to add an 's' (ScanChains), and to unambiguously identify
that ALL active scanchains shall be defined in ONE statement and the
NEXT ScanChains statement removes these as active (and defines the
next set of active chains). One issue with this construct is
verbosity; a design may contain hundreds of active chains.

Which led to extending the scanchains notion to encompass a
scanchaingroups notion as well. This is presented (under >) at the end
of Peter's proposal below. While this does address most issues it
opens up additional language complexity and definition
reqiurements. These issues would need to be resolved and specified if
this set of constructs was to be supported.

Greg identified that the primary restriction of Peter's proposal is
the need to group or collect the active scanchains under separate
ScanStructure blocks, in order to reference "just the active"
scanchains using the ScanStructures. Referencing scanchains directly
allows one to "pick-and-choose" the active chains inside a
ScanStructures block. This is really a usage model/requirement in
order to support the use of this statement, which IS optional in the
flow.

Doug was most comfortable with Peter's proposal, with the change to
call the statement "ActiveScanStructures". Greg stated a preference
for this statement because it unambiguously (or less ambiguously)
identifies the INTENT of this construct, whereas most other statements
indicate a reference to a chain but don't indicate the purpose for the
reference. Doug was also very comfortable with the usage restrictions on
blocking ScanStructures into active groups.

Jim reserves comment pending a more complete review and
understanding of this issue.

Greg is also comfortable with referencing scanstructures as "active"
in the patterns, because it addresses the requirement with a minimal
amount of additional language constructs and also sees the
scanstructures-blocks requirement as not restrictive to the behavior.

(b) shared signal discussion
Due to lack of time, this topic was left to be broached in the next
meeting. Doug asked if the minutes of the last meeting featured the
document with the corrections identified in the last meeting; Greg
identified that it does. It is requested that the WG review this
document and be prepared to identify issues with this proposal at the
next meeting.

Next meeting Sept 26, 10am PDT.

Meeting adjourned at 10:55 am PDT.



Peter's active-scan-referencing proposal

Tony, Greg:

We still had a lot of activity on this issue after Tony's email and an
agreement does not seem close. As I discussed with Tony, I am proposing
below a simplified version with the goal of minimizing the need to explain
and defend the constructs.

The simplified version I am proposing has the advantage of introducing only
a single new statement, the reference statement (no new statement in
ScanStructures). Therefore, it removes the name space discussion and the
forward-reference objections. It has the disadvantage of lesser flexibility
in "grouping" scan chains, but I don't see that as a practical limitation.

Pattern|Macro|Procedure {
ScanStructuresRef (struct_name)* ; <=== new
}

The ScanStructuresRef defines the ScanStructures active from that point on
(no accumulation).
The struct_name listed shall be from the ones linked by the PatternBurst.

Please give me your comments.

-Peter


At 08:02 AM 09/06/2002 -0700, Tony Taylor wrote:
>I would like to try to bring to closure the 1-on-1 discussions that have
>taken place over the last week with regard to ScanStructures and groups of
>scan chains. If we can all agree, I will bring it to the dot1-wg next week.
>Of all the proposals discussed, I believe the following satisfies all the
>needs:
>
>ScanStructures (struct_name) {
> ScanChainGroups { <=== new
> ( group_name { (chain_name;)+ } )* <=== new
> }
> ScanChain chain_name { ... }
> }
>}
>Pattern|Macro|Procedure {
> ScanChainGroups (group_name)* ; <=== new
>}
>
>Motivation:
>1) To treat the ScanStructures as a Domain that is referenced by the
>PatternExec in a manner similar to procs and macro domains.
>2) To remove the ugly semantics that are required by dot0 (see below).
>3) To allow identification of multiple scan chains that are in effect
>simultaneously on a given vector or set of vectors.
>
>STIL.0 Clarification:
>The equivalent functionality is already accomplished in dot0 using a clever
>set of semantics. They need to be explained in the clarification document
>(Greg, you may have already documented this, but it is not on the web), and
>they go like this -
>
>- ScanChain statements can appear in a Pattern, Procedure, or Macro.
>- Subsequent ScanChain statements accumulate to form a group that is active
>on all Vectors that follow.
>- The first ScanChain statement after a Shift block establishes the
>beginning of a new group and all chains accumulated to that point are
>removed from the active group.
>- Groups carry over to/from macro invokations, however a new group is
>established upon procedure invokations.
>
>Please let me know what you think of this. If you still have problems with
>this proposal then I will set up a group call so the four of us can discuss
>it together.
>
>Thanks, Tony