Phone Conference P1450

Phone Conference P1450.1 Working Doc Subgroup

Agenda
Review the following changes made in D15:
1. ScanStructures->ScanChainGroups added to draft (clause 15). Pattern->ActiveScanChains added to draft (clause 17).
2. The keyword ScanModule has been totally removed from the document (clause 15 and Annex L3).
3. The ScanCells block in clause 15 has been modified to specify semi-colon separators when a block is used. This resolves GM-1, GM-2, and GM-5.
4. Clause 6.3 has been eliminated and the scan-cell-list capabilities are defined in clause 15.
5. Table 3 has been updated. See question re: variables and signals.
6. Added example to clause 6.2.
7. Added Greg's new LockStep stuff (clause 13.4 + Patern clause)

ScanStructures & ScanChainGroups

Started with a review of the changes to ScanStructures, starting at pg

37. Tony briefly covered the changed syntax.

Peter had an issue: Pg 39 15.2: duplicated intro paragraph. Tony will

fix - AI[1].

Discussion about the application of the ScanChainGroups, and the

ActiveScanChain statement. Discussion highlighted the need for an

example in the document. Tony took AI[2] on this.

Douglas identified some concerns between .6 constructs (and

references) and these constructs. He will tag some .6 members to

validate that there is concensus between these two areas.

'Scan Module' and hierarchical scan descriptions

Previously the document had used the term "scan module". This has been

removed, and examples of 'hierarchical scan application' cleaned

up. Tony started with a review of example on page 85/Annex L.3.

Douglas was confused that the bubbles in Figure 10 (without driving

triangles) were meant to represent inverters. Tony AI[3] to add

footnote to Figure 10 about the use of bubbles to represent inverters

in this diagram.

It was identified that the example in L.3 used single periods between

the chainname and instance name reference, yet the description under

bullet 5, pg 38 would indicate that single-colons should be present

here. Change example in L.3 to use SINGLE COLONS instead of

periods. Tony AI[4].

Move information from bullet item 5, pg 38, up to a new section under

clause 6 (re-insert 6.3), to define 'scancell names' or

something. Also add optional braces around (SCANSTRUCT ::) Tony AI[5].

Namespace table

Table 3: Discussed briefly the generality of the signals/variables

namespace, and the encompassing of many different constructs

here. Also discussed the last entry in this table at this time,

apparently to support a ScanCellGroup concept, which is associated

with some concerns that Douglas previously identified. Tony will add

this to the issues list as well so it doesn't get lost from this

review; AI[6]

section 6.2: boolean expressions

Clarifications look good; no questions from group. Tony identified

that currently we don't support '==' operations on wfc-list constructs

because there are too many forms of wfc-lists and Greg doesn't want to

define the words around what a canonical form of a wfc-expression

would be. Also by *not* supporting wfc-lists we enforce using

enumerated values for this purpose which makes the code more

clear/readable/dare-i-say-self-documenting...

LockStep

In 5 short minutes. Due to lack of time, Tony overviewed the additions

on LockStep. Jim made a request to align the text in the examples on

pg 32 (code lines 380-388 and 394-399); interpreting these constructs

(there are supposed to be 3 parallel definitions here) is complicated

unless the examples are in the right columns (yes, Tony AI[7]).

Jim asked about why the scan-data-padding/length-alignment process

here uses the ScanIn/ScanOut attribute value on signals instead of the

data length as used with dot-zero. It was fortunate that this was a

phone conference because Greg would have knocked someone out with his

hand-waving response. Response from Greg: it is perceived that the

attributes across all LockStep'ed signals will be easily available

during pattern processing, while having the data inside each of the

LockStep'ed patterns, available all at the same time, may not be

possible (consider an environment that uses a pass-per-pattern to

'interleave' all the LockStep'ed data together). By supporting

specification of the data length at the attribute level, each pattern

can be resolved independently of the other data present, (but still

dependent on the attribute values across all LockStep'ed

patterns). Greg is sitting down again.

Jim asked for perhaps some large, bold, bright red or possibly yellow

with a green background, wording here to indicate that in LockStep

there is a different data alignment process (Jim actually asked for a

parenthetical expression. The minute taker added the emphasis).

Ended this meeting on LockStep discussions. Again.

next phone meeting Nov 21.

Meeting adjourned at 11:00 PST.

[AI1] Tony - remove one of the first paragraphs of 15.2

[AI2] Tony - add example of ActiveScanChain usage

[AI3] Tony - footnote on fig 10 about use of bubbles

[AI4] Tony - correct example L.3 to use single-colons.

[AI5] Tony - move item 5, pg 38 to a new subclause under 6.

[AI6] Tony - add ScanCellGroups questions to the dot1 issues list

[AI7] Tony - align the 3-parallel LockStep code examples