Phone Conference P1450.1 Working Doc Subgroup

Thurs Jan 29, 10:00 am PST

 

Attendees:

Tony Taylor (chair)
John Cosley
Peter Wohl

Jason Doege

Tom Bartenstein

Doug Sprague

Bruce Kaufman

 

Documents

Agenda

Review the pre-ballot issues outlined in the D19-ballot-resolution document.

 


Meeting discussion

 

IEEE meeting clearances
Nothing under discussion or presentation for this meeting was identified as being proprietary or restricted.

JC-2 - Padding rules for LoopData

As currently defined in P1450.1-D19, the padding rules for a LoopData block are the same as for a Shift block. For a Shift block, padding is done on either the beginning or end of the chain based on ScanIn/ScanOut designation. This information is not know for other types of signals (i.e., InOut). The wg decided that the loop count should be determined by the longest parameter, and all shorter ones should replicate the last wfc.

 

A follow on question is whether ScanIn/ScanOut signals should be allowed in a LoopData block and whether non ScanIn/ScanOut signals should be allowed in a Shift block. The thinking is to not allow these cases. If anyone has a concern or application that requires this, then we will re-consider.

 

DM-1 - improvement to ScanCellGroups

a) The proposal is to move the ScanCellGroups block inside the ScanStructures block. The complete motivation for this is unclear, but it is believed that it is to minimize the number of top level blocks. There are two problems with this idea - The first problem is that this construct gets confused with the concept of partial scan chains which are defined using the ScanChain statement. The second problem is that the ScanCellGroups was intended to allow any arbitrary list of cells to be identified, regardless of the chain that loads them. Unfortunately, neither Rohit (who originated this requirement) nor Denis (who suggested  the change) were present. Tony has the action to resolve this with Rohit and Denis.

 

b) During discussion several problems with the description arose (see clause 16):

- states that a cell-group of one is a re-name. This implies that the group names exist in the same name space as scan-cells and scan-chains which leads to the mis-interpretation above.

- states that a group-name may be used anywhere that a scan-cell-name may be used. Again, leads to the above mis-interpretation.

- if there are named domains for cell-groups, how are they referenced? Scan-chains are identified by the active-scan-chain pattern statement. It is not appropriate to specify the domain name in euther the pattern or the pattern-burst, as groups don't change based on patterns and, in fact, are never referenced in any pattern syntax. The only usage to date is in P1450.6.

 

c) Also suggested is to move the ScanCellType block up one level so that it applies to all chains in a ScanStructures block. After discussion, everyone was comfortable that this is a better place for the block.

 

JC-1 - use of Integer Expressions
The concern was that with the removal of single quotes in expressions that when used in pattern data, the interpretation is ambiguous. After some discussion, wg concluded that there is no ambiguity (there would be if wfc data allowed +, -, etc.). John Cosley agreed to take a closer look at his parse rules. Single quotes are always optional. It may be desirable for clarity to require them in pattern data, but wg was not prepared to make that a requirement at this time.


Meeting adjourned at 11:00 AM PST.


Next meeting

Thursday, Feb 12, 2004, 10:00 to 11:30AM, PST

 

AIs

[AI1] Tony - Communicate the wg concerns about DM-1 (see discussion above).

[AI2] John Cosley - Re-think issue JC-1 and recommend whether to require single quotes in pattern data expressions.