1. Ballot list formation; start of ballot process; you should have received your invite already
2. Any more hot spots in the document?
3. Some new issues spurred by cursory review of 1450.6. See items a through c below:

---

a) Consider the following signal variables case:
 

Variables {
    SignalVariable SV[0..1]; }
}
Pattern {
    Macro M { SV = XX; }
}
Macro M {
    C { SV = #; }
    V { SIG1 = SV[0]; SIG2 = SV[1]; }
}
Issue: SV is used in both the bracked and unbracked mode. This may not be
clear in the document, but it is needed.
===============
b) Now the same issue with regard to SignalGroups:
 

SignalGroups {
    SG = 'A+B';
}
Pattern P
    Macro M { SG = XX; }
}
Macro M {
    V { SIG1 = SG[0]; SIG2 = SG[1]; }
}
Issue1: STIL.0 does not specifically allow bracket indexing into a signal group; needed by dot6
Issue2: Should we allow signal group definition as SG[0..1] = 'A+B'; which is specifically disallowed in dot 0 (p60)
===============
c) Following the logic a bit further:
 

Signals {
    BUS[0..7] InOut;
}
Pattern P {
    V { BUS = XXXX XXXX; }

}
Issue1: Should defining BUS[0..7] in Signals block imply a name BUS as a signal group; this is not the case in dot0
Issue2: If BUS is actually defined in the SignalGroups block the new definition overrides; consistent with the current re-definition rules in dot0. This maintains, I think, compatibility with dot0.
===============
d) Add to ScanStructures a predefined scan-cell-type for identifying lockup
latches. Here's how it would look, where A, B, C, D, F are of the default
type; E is of type LockUp; and G is of type FOO.

ScanStructures {
    ScanChain CHAIN1 {
        ScanLength 6; // Note that the lockup does not have scan data
        ScanCellType { ...} // default type definition
        ScanCellType FOO { ... } // a named type definition
        ScanCells { A; B; C; D; E LockUp; F; G FOO; }
    }
}
Lockup: This is a pre-defined cell type that is used to identify "lockup latches" which are placed in the scan chain typically for the purpose of
timing synchronization. In serial scan shift operation, the scan data goes directly to the next scan cell in the chain. In parallel scan cell load, no scan data is loaded.

 

1: Balloting initiation
Tony opened the meeting identifying that the request to form a balloting group has been sent out by the IEEE, and balloting group
formation is starting. All people interested in participating with the balloting process need to submit their intent to the IEEE Standards Association before Dec 9, 2003.

 

2: items a-c
Discussion about the context when the same name is declared over multiple ranges:
Signals {
    BUS[0..7] InOut;
    BUS[8..15] In;
}
- What is the range of the implicit declaration of BUS?

Discussion about discontinuous ranges -
Signals {
    BUS[0..7] InOut;
    BUS[9..15] In;
}
Does the 9th value exist in BUS?

Further complications include bit-indexing order (low-high on one declaration and high-low in another)...

Proposal by Greg to avoid these issues:
- if the bracketed name is declared ONLY ONCE then there is an implicit declaration of this name as an "implicit group" without the
brackets. If the bracketed same name is declared with multiple (different) ranges, then there is no implicit group-name defined.

Motion to accept a-c, with the additional proposal above - all in favor, John hesitant about the uncertainty of the implicit
existence but accepted this. [AI1] to Tony to add these behaviors to the document.

3: item d
Peter presented a review of this capability and identified his concern: why did we isolate lockup-latches over all the other types of
latches or scan constructs that might be present?

As the discussion continued, other aspects of scan-cell behavior were raised. Jason noted the lack of identification of clocks at the cell
level; Peter indicated that the scan CHAIN clocks were part of the load_unload/shift operation information but a per-cell clock reference
was not part of the current ScanStructure information. This data IS available as part of the CTL information, however, and it is
anticipated that full characteristics of the cells would be part of the CTL information.

Peter's alternate proposal is to place the lockup latch representation folded into the cell-type data, as part of the CellIn references. The
current proposed constructs support representing this cell without an additional attribute or pre-defined cell-type to be declared.

Additional discussion around the issue that the scan-cell list is really clock-behavior-specific; different clocking strategies will
result in different definitions of scan-cells. This is an expected behavior and not a defect in the spec.

Peter took [AI2] to extend Annex L with an example containing a lockup latch representation.

Tony raised a question about the opportunity for multiple ScanOut statements to be present, and what does that really mean? Greg
indicated that the expected context of multiple ScanOuts would be such that there would be separate, non-overlapping If conditions on each
statement. Tony took [AI3] to add explanation that there is only one active/true scan-out statement if multiple ScanOut statements are
present and it is an error if more than one ScanOut statement is true at a time.

A question was raised during this discussion about names, and name relationships. Several contexts were presented - STIL scan-cell names
and Verilog netlists, verilog and def names, and verilog and vhdl. It was indicated that the NameMap construct could be used in
general to correlate these different names as necessary. questions were raised about the responsibility of generating these namemaps.

Doug - STIL0 question
Doug had a 1450-1999 question: for included STIL files, the STIL statement is obviously expected to be present in each file. But can
the Header block be (optionally) present as well? Greg indicated that the intent of the Header block is as a per-file construct, and
therefore could be present in each separate, included, STIL file.

 

Next Actions
Tony will complete these changes, get a review of this draft, and move for acceptance of this draft for balloting. Depending on other
requests for changes to the document, we may do this by email or if not complete, then have another meeting in two weeks - Nov 20, 10:00 PST.

 

Meeting adjourned at 11:20 pm PST.