Phone Conference P1450.1 Working Doc Subgroup
Thurs Nov 21, 10:00 am PST
Attendees:
Bruce Kaufman
Tony Taylor
Greg Maston
Doug Sprague
Peter Wohl
Jason Doege
Documents
p1450.1 D15 draft 10/7.
D15 review-resolution document 10/15.
Bruce's email, enclosed below these minutes.
Agenda
Agenda as posted, with addition of Bruce's email.
Meeting
Clause 6.9, scancells definition
Discussed the description added in this new section. Biggest question
about the constructs presented here is how to 'uniquify' names when a
scanchain is referenced with a instance name. Greg identified that at
the moment the actual process used is not required to be defined in
the spec because nothing actually references these
names. Unfortunately that moment did not last even the entire meeting
as this issue was revisited when scancellgroups was discussed later.
Tony raised a concern about referencing 'instances' of chains because
of multiple instances of modules, vs. redefining chains due to
"reconfigurable scan". These are two distinct usage models of this
data and the solutions are different: instantiating chains has a
shorthand reference to the previously-defined chain to be
instantiated; reconfiguring chains requires repeating the scancell
names in all configurations, at this time. There is no shorthand that
'references' a scanchain under a reconfigured definition at this time.
Clause 10.1: new definitions
No concerns raised about the existing definitions added by
Tony. However, Tony identifed a question about whether default
attribute values should be defined, and the Working Group felt this
was appropriate. Tony will add the following proposed defaults:
for integers: - usage test - init 0 - no enum reference
- integer values no bounds
for signalvariables: - defaults as for signal/group attributes
- initial value 'indeterminate'
AI[1] to Tony
LockStep
Reviewed the complete LockStep proposal now that Greg's example has
been partitioned into the intended 3-parallel-executions and everyone
can now understand what's happening there. No issues were raised with
this proposal although it was identified that it's complex, but so is
the issue it's addressing.
Bruce's email
Clarification proposed by Bruce (at end of these minutes) in regards
to highlighting that LockStep pattern synchonization processes padding
and shift-data-alignment differently than defined in dot-zero, was
accepted by the WG.
Jason raised a concern about pre-padding interactions of core
data. Pre-padding scan data (aligning scan data as part of the pattern
data itself) is unnecessary because STIL provides alignement
constructs, and may cause problems if that pattern data is then
re-used in a core environment and integrated into serial chains with
other data. Greg identified that the context of application of a STIL
data does affect the constructs present in that data, and having
constructs present that do not fit the application can invalidate the
usability of that data. Core test does have special requirements
(another one is that all operations in the patterns be performed
through only macro and procedure calls), and it is vital that these
issues be identified by the application contexts.
Tony proposed several grammer/clarifications to this section, all
accepted.
Clause 15.5
Reviewed the example created by Tony to present the need for the
ActiveScanChains statement. WG accepted this example with one request
to add a short comment on the Vector statements between Shifts, to
identify that these vectors are changing the scan-access to various
chains. Tony AI[2].
Review Resolutions Discussions
All outstanding Review Resolutions were reviewed. The following
review resolutions refer to issues/questions about the XRef statement
and failure-feedback mechanisms. These issues are under much
discussion at this point and are listed here to highlight the scope of
this discussion: DS-3, GR-8, GR-14, GR-21. [AI12] to address
fail-feedback and Xref issues.
DM-3: open for Jason to confirm and close.
DS-1:, DS-2: Doug and Greg to review and close, AI[5,6]
DS-3: WG to review section 17.4, in particular the second part which
is how to reference hierarchy of calls through the X statement. Tied
to [AI12].
DS-4: To close, recommended usage doc avaiable. Tony to put on web
(AI[3]).
GM-3: Greg to review and close, AI[7].
GM-9: Request was to move the Variables clause to the back of the
document. Discussion in the Working Group proposed to move the
Enviroment clause forward, and Greg accepted this as resolution. Tony
to reorder clauses, AI[4].
GR-8: Jason has been tagged to orchestrate some fail feedback
discussions. This is not happening at the moment due to real
work. This is related to XRef issues as well, [AI12].
GR-9: Expect that this issue has been clarified in the current doc,
close.
GR-11: LockStep has been clarified in the new doc; issue closed.
GR-12: WG feels that the definitions are sufficient, and requires
concrete issues if there are problems here. Close.
GR-13: Tony to review and identify disconnects, [AI9]
GR-14: X STMT - open issue [AI12]
GR-16: TONY to finish and close, [AI8]
GR-18: TONY to finish and close, [AI8]
GR-21: X STMT - open issue [AI12]
GR-22: Tony took [AI10] to review the issues here.
GR-23: See email in Appendix 1. Response: no, we do not need to
reserve all 'keywords', just those that start statements.
RK-1: done, close
RK-2: done, close
RK-3: scancell-groups concept. Working Group agrees to pull p1450.6
proposed syntax into .1. However this opens the issue of requiring a
definition for hierarchical scan cells referenced through the
instancing mechanism, in order to support referencing these cells in a
scangroup. Tony [AI11] to pull syntax in, ALL [AI13] to identify
instanced-scancell naming constructs.
TT-2: closed
WG-2: \e Greg [AI14] to complete.
Next meeting
next phone meeting Dec 5.
Meeting adjourned at 11:31 PST.
AIs
[AI1] Tony - define defaults for Integer and SignalVariables
[AI2] Tony - add comments to vectors in ex. in 15.5.
[AI3] Tony - put dot1 recommended usage doc on web.
[AI4] Tony - pull the Environment clause forward in the doc.
[AI5] Greg - review reference in DS-1 and fix if necc.
[AI6] Doug - review reference in DS-2 and fix if necc.
[AI7] Greg - review new words and accept or identify fix.
[AI8] Tony - finish and close GR-16,18.
[AI9] Tony - review the two contexts of the Fix statement.
[AI10]Tony - review issues in GR-22 and identify concerns.
[AI11]Tony - pull scangroup constructs from p1450.6 to here.
[AI12] ALL - Fail Feedback and Xref closure.
[AI13] ALL - consider proposals for hierarchical scancell naming.
[AI14]Greg - describe \e.
>From: "bruce_kaufman" <bruce_kaufman@teseda.com>
>To: "Tony Taylor" <Tony.Taylor@synopsys.COM>
>Subject: My Action Item
>Date: Thu, 07 Nov 2002 11:24:33 -0800
>
>Hi Tony,
>Here's my suggestion for a clarification. I added a parenthetical remark
>at the end of the 3rd paragraph in Section 13.3
>Feel free to modify.
>Bruce
>(3rd para with addition)
>-- For all shift blocks in parallel, the length of the scan data is
>defined as the longest data length of all signals with a "#" across all
>shift blocks. To facilitate this determination, it is required of the
>integration process that the signal/group definitions be adjusted such
>that the ScanIn/ScanOut-integer attribute defines the length to which each
>signal/group is to be padded, and this value shall be used rather than
>padding to the longest scan chain length of an individual pattern. (Note
>that determination of padding for LockStep is slightly different from the
>calculation of padding for Procedure and Macro Substitution (see IEEE Std
>1450-1999 Section 24.5 "Procedure and Macro Data substitution") which
>states that padding is based on the length of the longest chain.)