IEEE 1149.1 working group
The meeting was called to order by working group chair Najmi Jarwala on March 4 at 9:08am.
Najmi requested that the minutes record the thanks of the working group to Philips and Math Muris for their hosting of this meeting.
Najmi also requested that the minutes record the thanks of the working group to Michel Parot for his kind assistance in providing travel-related advice and information to the working group and its members.
The attendees were:
1149.1 Working Group members ---------------------------- Gordon Robinson, Chairman GenRad Math Muris, European Vice Chair Philips Adam W. Ley, North-American Vice-Chair Texas Instruments Dilip Bhavsar Digital Equipment Terry Borroz Teradyne CJ Clark Intellitech Grady Giles Motorola Najmi Jarwala AT&T, Bell Labs Colin Maunder British Telecom Kenneth Parker Hewlett-Packard Michel Parot Thompson-CSF Markus Robinson Synopsys Rod Tulloss AT&T, Bell Labs Lee Whetsel Texas Instruments Tom Williams IBM observers --------- Mark Grabosky National Semiconductor Gary O'Donnell National Semiconductor
The following WG members had sent their regrets:
John Andrews National Semiconductor Bernhard Geisberger Texas Instruments Dieter Ohnesorge Alcatel SEL
The following WG members were also absent:
Harry Bleeker JTAG Technologies Peter Hansen Teradyne Pat McHugh U.S.Army Scott Neal Intel Stig Oresjo Hewlett-Packard Bob Russell Bull Dirk van de Lagemaat Philips CS
Chairman Najmi Jarwala presented his proposed agenda.
Tom Williams requested consideration of the addition of an item to propose compilation of papers demonstrating prior art with respect to 1149.1. Math Muris so moved. Terry Borroz seconded. Unanimous approval.
The following agenda was approved:
1. Call to Order
2. Approval of Agenda
3. Approval of Minutes from Previous Meeting
4. Update on Status of P1149.1b
5. Election of New Working Group Chair
***New Chair Presides over WG Meeting ***
6. Election of 1149.1-1995 Technical Editor
7. Use of WWW server (TTTC home page) and SPAsystem
(ref. e-mail CM950202)
8. Requests for Interpretation
8.1. Single Cell Bidirectional - Legal?
(ref. e-mail GR950120) - Gordon Robinson
8.2. Negative Logic and Inversion
(ref. e-mail GR950217) - Gordon Robinson
8.3. BSR Cell Compliance - Dilip Bhavsar
8.4. Procedures for email submission/response - Mary Lynne Nielsen
9. Dot 1 Vision
(ref. e-mail CM950206)
10. Reports on Actions from October 6 Meeting
(not otherwise included in section 11 below)
10.1. Report from Najmi/Adam on Changes to WG Membership
10.2. Report from Najmi on Formal Rules for Membership Qualification
10.3. Report from Rod on Standardization of SVF
10.4. Report from Math and Najmi on Progress toward MCM Support
10.5. Report from Colin on Progress toward 1149.1 Applications Guide
11. 1995 Reaffirmation/Revision
11.1. Chairman's Remarks
11.2. Review of Revision Schedule
11.3. "Preposterous Bidir"
11.4. Pin-Driver Behaviors/Models
11.5. SAMPLE/PRELOAD requirement
11.6. EXTEST Opcode
11.7. Parity (including IR-Scan and DR-Scan Error Detection)
11.8. RUNBIST-like instructions
11.9. Differential I/O
11.10. Compliance Enable
11.11. Shared I/O
11.12. Clock Pins
11.13. Subset of 1149.1 for RAMs
11.14. Provision for Synchronous Entry into States which are Disruptive of
Normal System operation
11.15. Set of Documents to Establish Genesis of 1149.1
12. Time/Place of Next Meeting
13. Other Business
14. Adjourn
Grady Giles pointed out that he had been misquoted in the draft minutes for October 6, 1994 meeting. The phrase "can be determined" in section 6.8 of the draft should be quoted as "can not be determined."
With that change noted, the minutes of the October 6, 1994 meeting were approved by acclamation.
Najmi presented a slide as follows:
1149.1B is History
1149.1B will be available in March. It is a separate publication.
The order number is SH94256.
The ISBN is 1-55937-497-7.
The price is $52. The IEEE member discount price is $31.20. People can call 1-800-678-IEEE or 908-981-1393 outside of the US and Canada.
A printed copy of the document was circulated for example purpose.
Ken Parker credited Mary-Lynne Nielsen for an almost effortless transition from BSDL D11 to IEEE formats. Math Muris moved that the minutes record the thanks of the working group to Mary Lynne for her effort in publication of 1149.1b. Rod Tulloss seconded. Unanimous approval.
Rod Tulloss nominated Gordon Robinson as the next working group chair. Colin Maunder seconded the nomination. Gordon accepted the nomination.
Tom Williams inquired if Gordon's election to 1149.1wg chair would be considered to conflict with his role as Test Technology Standards Committee chair.
Gordon suggested that precedent indicates this is not the case.
Tom asked if we should look to rectify the chair of TTSC in light of Gordon's election to the 1149.1wg chair.
Gordon outlined the following roles/characteristics for TTSC and its members:
Najmi called for other nominations. There were none.
Gordon was unanimously elected to be the next 1149.1 working group chair.
Tom Williams moved that the minutes record the thanks of the working group to Najmi for his efforts as the working group chair and especially for his responsiveness. Gordon Robinson seconded. Approved by acclamation.
Gordon Robinson assumed the chair and control of the further proceedings of this meeting.
Gordon pointed out that the task at hand for the working group is the reaffirmation/revision of the standard for 1995. He pointed out that as reaffirmation without revision implies that no need for changes is indicated during the next 5 year life of the standard, and that since significant changes have been proposed, that a revision seems to be indicated. He suggested further that in this meeting we would select topics on which the revision will be based.
Grady Giles pointed out that one change has, in fact, already been approved.
Gordon Robinson noted that in the light of the forgoing discussion, a new technical editor would be needed.
Najmi Jarwala nominated Adam Ley to be the 1995 Technical Editor. Ken Parker seconded the nomination. Unanimous approval.
Colin Maunder reported that 1149.1-related pages (URL: http://info.computer.org/tab/tttc/standard/s1149-1/home.html) have already been put on the TTTC World-Wide-Web home page (URL: http://info.computer.org/tab/tttc/). He questioned, however, the propriety of placing minutes on WWW. Najmi Jarwala asked why not?
Colin suggested that the WWW pages should be used to communicate proposed changes in the standard to its user community.
Gordon Robinson indicated that WWW seems a very appropriate medium for distribution of information that is desired to be widely available. He committed to publicize the 1149.1 home page through the comp.lsi.testing newsgroup.
Colin reported that he has editorial control and required user access codes for maintenance of pages on the TTTC servers, including those related to 1149.1.
Gordon asked for an explanation of the similarity of HTML to SGML. Colin pointed out that HGML is a specific template for SGML. Adam Ley pointed out that one of the goals purported for the SPAsystem is to be able to translate everything (i.e., any formatted or unformatted text) to SGML. Colin indicated further that TI has already created an SGML mark up of the 1993 version of 1149.1.
Colin reported that the original version of 1149.1a is available in Word. Najmi reported that the original version of 1149.1b is in Framemaker.
Math Muris suggested that he has heard of many requests for WWW distribution of the standard document. Gordon noted that IEEE is formulating their electronic distribution plans and further that this may encourage free distribution of standards.
Tom Williams noted that the working group does not hold the copyright to the standard and so cannot post it unilaterally. However, he suggested that we should make access to minutes easy.
Gordon Robinson noted that minutes actually show little in way of controversy. Markus Robinson suggested that we note that minutes should not be used as a reference for technical issues.
Gordon summarized the discussion noting a general sense that all information related to 1149.1 working group activities should be communicated as freely and clearly as possible. He suggested that WWW be used were possible.
Rod Tulloss suggested that minutes should not be posted prior to their approval by the working group. Gordon stated his agreement.
Tom Williams moved that Gordon, Adam, and Colin be appointed to evaluate best means to communicate WG information. Najmi Jarwala seconded. Unanimous approval.
ACTION -Gordon Robinson, Adam Ley, and Colin Maunder to determine how to best use WWW, SPAsystem, etc. for communications of the working group to its membership and user community.
Math noted that IEEE also has copyright to drafts of the standard. Colin, however, noted that the copyright extends to the working group the right to distribute drafts freely as it sees need to aid standardization activities.
Adam inquired as to the possibility of electronic approval of minutes to speed their delivery onto WWW. Ken Parker suggested that any quoted persons would need to approve explicitly. Colin noted that not all persons quoted in the minutes of the previous meeting are present at this meeting and therefore are at best implicitly approving said minutes. Math concurred to this point.
Gordon suggested that a 3-4 week period be provided for objection to draft minutes and for approvals to be received. He stated that he would prefer to see specific indication of approval as opposed to approval implied by no response. Markus Robinson requested a minimum 30 day approval period.
Gordon Robinson described "Request for Interpretation" as an official procedure of the IEEE. The working group has a responsibility to respond with a clear indication of whether the subject item is in compliance to the CURRENT standard AS WRITTEN (editorial note - my ALL CAPS emphasis corresponds to the spoken emphasis). The working group can record an indication that related changes to the standard may be made in light of a request for interpretation, but that judgment of compliance may not be made of the basis of such proposed changes.
Gordon Robinson stated that he expects a consensus that the so-called "single- cell bidirectional" violates rules for SAMPLE. He noted that he has seen no indication otherwise in email traffic on the subject. Gordon asked if anyone disagreed with this assertion - if not, then we could draft a response so indicating.
Najmi Jarwala inquired as to whom had submitted the request for interpretation. Gordon replied that he had done so such that the working group could make a formal response. Dilip asked if the working group could defend this action. He suggested that the process for requests for interpretation need to be formalized.
Najmi Jarwala moved that the "single-cell bidirectional" be ruled non-compliant and that a formal response to the request for interpretation be drafted as such. Colin Maunder seconded.
Gordon suggested that the formal response should consist of a formal restatement of the request for interpretation followed by the working group response. Although he did not specify the form of this response, he suggested that it should contain detail as to which rules are violated, etc.
Najmi suggested that an interpretation sub-committee be appointed to draft the formal response. Markus Robinson indicated that the original request for interpretation is included in Gordon's Jan 23 email.
Gordon further outlined the response process as follows:
He suggested further that a this point we had motion on table to vote on the conclusion of the informal discussion.
Colin suggested that tables 10-1 and 10-4 should be referenced in order to determine compliance.
Ken Parker pointed out that he considers two rules in the standard to be in conflict (7.6.1d versus 10.6.1g). He stated that this indicates that the standard is not clear on the purpose of SAMPLE. He asked if the working group were sure of the meaning of SAMPLE. Colin suggested that the more recent updates to chapter 10 express the most current intent of the working group. Math further suggested that we may conclude that we have a contradiction in standard while still giving a non-compliant determination.
Gordon suggested the following reordering of agenda items:
Tom Williams requested a drawing of the "single-cell bidirectional." Ken Parker drew such a diagram. A representation of his slide follows:
|\
----*--------------------|\ | \
| | |----|OC>-----[PAD]
| +--|/ | /
| | |/
| ----- ----- |
+--| C |---| U |--+
| | | |
----- -----
|\
>-------------------------|\ | \
| |----|OC>--*--[PAD]
+--|/ | / |
| |/ |
----- ----- | |
+--| C |---| U |--+ |
| | | | | |
| ----- ----- |
| |
<----+---------------------------------+
After some discussion, Gordon suggested that we needed to form a consensus on what values are required to be captured by SAMPLE. Colin volunteered another diagram to get to the heart of this issue. A representation of his slide follows:
------------ |
) __ | |
) | | | |
0 ) -->| |-->|----*
) |__| | | ------------
| | | __ (
------------ | | | | (
*----|-->| 1|--> (
------------ | | |__| (
) __ | | |
) | | | | ------------
Z ) -->| |-->|----*
) |__| | |
| |
------------ |
Colin posed the rhetorical question, where's the fault? He suggested that SAMPLE is meant to serve as an approach to guided probing. He followed with another rhetorical question, what information are we trying to get?
Gordon stated that he sees an issue of how bidirectionals "make their decision" on whether to have input or output function. Dilip countered that the real question is the diagnostic capability of SAMPLE versus EXTEST.
Ken argued against Colin's assertion that it doesn't matter whether the bus is 2-state or 3-state - 3-state outputs must have 2 bits of controlling data. He noted that the oversight of this class of pin drivers can be viewed as a result of the historical "3-state centricity" of the working group.
Colin continued to say that we have failed to establish guiding principles in this area. He noted threshold logic as another example. Tom Williams suggested that the fundamental problem is that there is no universal interpretation of what constitutes a driver.
Ken suggested that further discussion of this topic should follow Grady Giles' taxonomy of drivers.
Gordon noted that with respect to Colin's diagram, to diagnose the fault, one needs to know if a given driver is driving and if so what value is it driving, and, if not (i.e. the pin has input function), what value is present at the input.
Lee Whetsel noted that SAMPLE calls for a fundamental difference for inputs versus outputs. Colin agreed, but again asked as to what we are trying to accomplish - that is, where and in what form are we using SAMPLE. He noted that he has not seen SAMPLE used for post-manufacturing guided probing, but has seen it used for system-design debug.
Najmi suggested that the problem is only presented when we are sampling AT the "pad". However, he suggested further that in many design flows/methodologies, the "pad" is effectively integrated with the driver. He drew a diagram to illustrate. Dilip assisted. A representation of their slide follows:
----<|---/\/\/---+ legend: (=) physical boundary of
"driver"
| (~) pad-to-pin bond wire
===============|========= (editor's note, this legend, which does
| |\ | | not appear on original slide has been
-------|>---| >--*--[PAD]~~~~~~{PIN} added for clarity)
| |/ |
=========================
Najmi stated that with respect to this diagram, there is no means of access to the node between the driver output buffer and its "pad."
Tom noted that the problem is the reference in chapter 7 to sampling the "state of ... pins". Colin suggested that, in fact, the goal of SAMPLE can't be met if section 7.6 is not fixed.
Gordon then asked Grady to proceed with a presentation of his taxonomy of drivers. Grady presented his first slide. A representation of this slide follows:
- Driver characteristics
Logic level 1,0,Z
Strength Active, Passive
VOH, VOL 5V, 3.3V, .....
IOH, IOL Big bufs, Small bufs
Symmetry Symmetric, Asymmetric
Time dependent Drive high then tristate
Polarity Active high, Active low
Disable value Z, pull-up, pull-down
other
- All of the above can be made programmable.
- Some simplifying assumptions are useful.
We are not interested in behaviors which are unobservable in the time
granularity of 1149.1 protocol.
Polarity is defined under 1149.1
Gordon suggested one possibility for other - slew rate.
Grady noted that he is no longer sure that his first simplifying assumption is true for SAMPLE.
Grady then presented his second slide. A representation of this slide follows:
Output_Drivers
|
|
Asymmetric-------+-------Symmetric
/ \ / \
/ \ / \
Active_High Active_Low 2-state 3-state
/ \ / \ |
/ \ / \ Off
Z l Z h /|\
/ | \
Pulled Z Keeper
/ \ / \
/ \ / \
h l last last_
\ /
\ /
x
- "h","l" denotes pull-up of pull-down
- "last" is last driven value.
- "x" corresponds to pull-x.
- Weak strengths as defined in BSDL are meaningless for an IC description
Colin pointed out that the standard does not distinguish between physical vs. logical boundaries of packages. Lee Whetsel emphasized that he thinks the BSC is very properly positioned at output BEFORE buffer/driver and at input AFTER buffer/driver.
Grady then presented his third slide. A representation of this slide follows:
- This is a real world practice. - This may be understood as parallel drivers which are enabled separately by control registers. - The standard could accommodate this practice by accepting multiple parallel drivers.
Rod Tulloss suggested that Grady has presented two groups of organized information. One can group can be thought of as operational/logical and the other as "analog." He asked, what do we care about? Gordon suggested further that Grady has introduced a series of attributes to describe "how" a driver is driving.
Grady then presented his fourth slide. A representation of this slide follows:
-
| -
| -
Drive_high_enable-----------+ -
| | -
| |\ | -
| | \ -
| | \ -
| +---|High \ -
| | |Driver \ -
| | --------------+ -
Data-----------------* |----------------------->-------
| | --------------+ -
| | |Low / -
| +---|Driver/ -
| | / -
| | / -
| |/ | -
| | _
Drive_low_enable------------+ _
| _
| _
|_
- Any output driver can be composed from some combination of high drivers,
& low drivers.
- The high driver and the low driver each have control signals.
- A symmetric driver has Drive_high_enable and Drive_low_enable wired
together.
- The presence of absence of a pull-up or pull-down may be associated with the
pin rather than the driver.
Lee then presented another related diagram. A representation of his slide follows:
^
|
---
---| |---|>---[] out
---
/ ^ \
single | weak
BSC
^
|
---
---| |---|>-+ strong
--- | /
^ | /
| |
--- |
multi ---| |---|>-*-[] out
BSC --- . |
^ . |
. . |
. . |
--- . |
---| |---|>-+
---
^
|
------------
------>| register |--->
------------
: \
- - + - - \
: : programmable weak/strong
^ +--(X)-|>--(-)--+ /
| | : : | /
--- | : : |
multi ---| |--*--(X)-|>--(-)--*-[] out
BSC --- | : . : |
| : . : |
| : . : |
| : . : |
+--(X)-|>--(-)--+
Colin asked again, what is our test objective?
Grady presented his fifth slide. A representation of this slide follows:
5V
output data ----*--------------- |
| | )O---o|[
| +---------- |
| | *----[PIN]
output enable ----|----*--|>O----- |
| ) >O----|[
+--------------- |
GND
output enable ---------+
|
|\ |
| \
output data ------| >------------[PIN]
| /
|/
Grady said that our view of a 2-state asymmetric bidirectional is a contrivance and that in actual implementation it looks mostly like the lower half of the 3- state driver. Grady then presented his sixth slide. A representation of this slide follows:
- Descriptions based on multiple parallel drivers may be more accurate for some real world pin types. - Tests for special behaviors of some pin types are only realizable with descriptions based on multiple parallel drivers. - Arbitrarily jamming one configuration on a multi-configurable buffer type is a disservice to those dependent on a configuration not selected. IC manufacturers regard this as a customer satisfaction issue. - This model preserves and extends the central concept that control cells only control the enabling and disabling of drivers. - Boundary-scan ATPG already handles multiple parallel drivers at the board level. - The added complexity is not likely to run rampant. Use of these modes come at the price of more cells. - Under this model, some "exotic", but real world pin types, would need extra control and...... DATA cells for complete description. (editor's note, ALL CAPS emphasis substituted for bold-italics emphasis used in original)
Rod asked if we can partition between parameters which can be set once based on fixed board design versus others which may need to be varied, (i.e. during EXTEST).
Tom interjected to say that drivers are analog and there are a whole bunch of them. He stated that dot 1 needs to focus on the digital (0/1) values presented to drivers and received by buffers.
Grady presented his seventh slide. A representation of this slide follows:
- 10.6.1.b For a given data input to an output buffer, precisely one of the BSR cells shall be capable of driving that data input. - 10.6.1.c For a given control input to an output buffer, precisely one of the BSR cells shall be capable of driving that control input. - 10.6.1.d The parallel output of a control-and-observe BSR cell that observes a system output from the on-chip shall drive only one of the following: i) a single data input to a system output buffer (2-state or 3-state, or the output signal for a bidirectional pin); or ii) the control inputs to a set of output buffers.
Dilip Bhavsar suggested that perhaps this topic need not be discussed further in this context.
Markus Robinson inquired as to if internal cells could be used to treat these issues. Grady indicated that they could, but that he still needs a formal mechanism in BSDL to describe how it is done.
Rod suggested that specially named registers could be used for such purpose.
Grady presented his eighth slide. A representation of this slide follows:
- B.8.14.2.k Any| element including a | element equal to OUTPUT2 and also containing a element must satisfy the condition that the value of will equal the value of | . - B.8.14.2.s For any element appearing a element of the | , when the in the of that is:.. ii) out, the of the can be OTPUT2 or OUTPUT3 only; furthermore, no other | containing the same | may have the same OUTPUT2 or OUTPUT3. (and similarly for iii and iv) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BSDL SYNTAX is quite amenable to describing multiple parallel drivers. (editor's note, ALL CAPS emphasis on "SYNTAX" above substitutes for italics emphasis in original) |
Gordon stated that BSDL reflects what the standard permits as opposed to what tools should automate.
Najmi suggested that Grady's proposal only addresses specific implementations. Ken concurred suggesting that a totally general model is needed along with as much automation as possible.
Colin claimed that all of Grady's proposals deal with "personalization." He stated further that he doesn't see these cases as any different from other programmable-type devices. Najmi concurred, stating further that these issues map to USERCODE-type activity. Colin concluded this aside bye saying that required elements are ability to observe programming register and possibly to control it.
Gordon stated that the discussion points to a need to deal with a number of separable problems. He presented a slide enumerating these problems. A representation of his slide follows:
1) What test issue is SAMPLE trying to solve? 2) How should attributes of driving be controlled? internal/parallel cells/separate register/ 3) Need attributes be SAMPLE observable?
In the context of this discussion relative to Gordon's first point, Grady stated that he has a problem with disavowing the fact that open drain outputs may have control cells. Adam Ley concurred.
Gordon requested that the question be called. (editor's note, the motion in question is repeated here for convenience: Najmi Jarwala moved that the "single-cell bidirectional" be ruled non-compliant and that a formal response to the request for interpretation be drafted as such. Colin Maunder seconded.) There being no objection, the vote was held - unanimous approval.
ACTION -The Interpretation Response Subcommittee to draft a formal response to the request for interpretation of "single-cell bidirectional." Such response to indicate that the subject boundary-scan cell is not compliant.
Markus Robinson moved that 7.6.1.d and associated descriptions be modified to agree with 10.6.1g. Tom Williams seconded.
Colin Maunder offered a friendly amendment to the effect that the conflict in 7.6.1.d and 10.6.1.g be acknowledged and that a subcommittee be appointed to resolve said conflict. Gordon Robinson modified this further to suggest that the subcommittee will treat the issue of "what test issue is SAMPLE trying to solve?" in the process.
Markus Robinson and Tom Williams accepted the amended motion as follows: That a subcommittee be appointed to address the issue of "what test issue is SAMPLE trying to solve?" and pursuant thereto to suggest changes necessary to resolve the conflict between rules 7.6.1.d and 10.6.1.g. Unanimous approval.
ACTION -A subcommittee (to be named) to address the issue of "what test issue is SAMPLE trying to solve?" and pursuant thereto to suggest changes necessary to resolve the conflict between rules 7.6.1.d and 10.6.1.g.
Colin Maunder moved that the activity of the subcommittee be restricted such as to ensure that the result will not conflict with the working group's decision that 10.6.1 take precedence. Lee Whetsel seconded.
Tom Williams requested that the subcommittee be allowed to decide on its own.
After much more discussion, Colin and Lee agreed to withdraw the motion and hope that sanity prevails.
(editor's note: as noted previously in paragraph 9 of 8.1 above, Gordon Robinson suggested that item 8.2 be treated following item 8.3. Therefore, it has been intentionally skipped at this point, but will occur following item 8.3)
Dilip Bhavsar presented a slide illustrating the cell in question. A representation of his slide follows:
_
( )
( )
( ) +-------------------------------<|----+
( ) | |
( ) +-|\ ^ |
( ) | | ----- | ----- |
( ) | |--| C |---| U |-----|\ |\ |
( ) | | | | | | | | | \ |
( ) +-|/ ----- ----- | |----|OC>--*--[PAD]
( ) | | | | /
( )----------------------------|/ |/
( ) |
( ) |
(_) ^
Objective: support mandatory EXTEST and SAMPLE/PRELOAD operations only.
Dilip made the following points with respect to the illustrated b-s cell:
Gordon stated that he assumes Dilip is willing to work on the subcommittee(s) instituted by approved motions of item 8.1, above. He then called for a motion as to whether "Dilip's cell" is compliant or not.
Najmi Jarwala moved that "Dilip's cell" be ruled non-compliant. Math Muris seconded.
Dilip modified his diagram to illustrate the cell used at a bidirectional pin. He questioned the intent of SAMPLE.
The question was called. Approved with 12 for, 1 against, and 1 abstention.
ACTION -The Interpretation Response Subcommittee to draft a formal response to the request for interpretation of "Dilip's cell." Such response to indicate that the subject boundary-scan cell is not compliant.
Gordon suggested that the formal response to this request for interpretation should specify that the cell in question is non-compliant with respect to the value captured by SAMPLE.
Gordon Robinson opened the discussion by stating that voltage inversion has never been intended. He cited the syntax and semantics of BSDL as evidence. Colin Maunder concurred, citing standard paragraph 2.2.e.
Grady Giles moved that voltage inversion be ruled non-compliant. Najmi Jarwala seconded. Unanimous approval.
ACTION -The Interpretation Response Subcommittee to draft a formal response to the request for interpretation of "voltage inversion." Such response to indicate that the subject is not compliant.
Grady did note however that there may be utility in inversion in some cases.
Gordon Robinson stated that he will support use of electronic submission of requests for interpretation. He added that he would circulate a copy of the procedure to the working group.
ACTION -Gordon Robinson to circulate to the working group a document of procedures relevant to electronic submission and response for/to requests for interpretation.
At this point, it was proposed and agreed upon that agenda items 11.5 (SAMPLE/PRELOAD requirement) and 11.11 (Shared-I/O) should be rescheduled in the agenda to follow other agenda items of section 11. Also, it was agreed that the item 11.5 should begin with a discussion of the purpose of SAMPLE.
Colin Maunder opened this discussion by stating that he sees significant changes having been made and requested to stretch dot 1 to more "system-level" activities. He suggested that perhaps dot 1 should be viewed as changing to support such efforts. He cited as example a proposal to allow flag/error conditions to be signalled back to a test controller. At any rate, he suggested that the working group needs to have a clear idea of how dot 1 fits into a system-level scope.
Grady Giles suggested that a proper role for dot 1 is to facilitate diagnosis and characterization of board-level behavior. He suggested that while dot 1 should avoid "getting in the way" of other missions, he does not think that dot 1 needs to define or constrain particular approaches.
Colin cited parity and extension of SVF for system-level test as other system- level issues which dot 1 might address.
Adam Ley noted that currently, dot 1 focuses exclusively on the chip-level aspects of boundary-scan implementations. He stated further that there are other issues intermediate to chip-level vs system-level (i.e., board-level). He cited a means to describe how chips are serially interconnected at board-level as an example.
Colin stated his opinion that dot 1 should not mandate any implementation details beyond chip-level. However, he went on to say that he would like to see consistency between all 1149.x capabilities - for example, instruction status, flags, interrupts.
Lee Whetsel bemoaned the fact that dot 1 seems not to be introducing any new ideas. He suggested that only fine-tuning is now being done to dot 1. He said that he wants to see if the working group can provide new ideas. He stated a move to support on-line testing as one such avenue.
Rod Tulloss expressed his concern about expanding the purview of 1149.1 too far. He described dot 1 as specifying "tooling." He noted that relevant questions then are "is there adequate tooling?" and "how is the tooling to be used/accessed?" He stated that he would be concerned if dot 1 specified all uses of all tooling. He suggested that it might be more appropriate to leave specification of other uses to other standards. He did suggest however that we may find a need to add more tooling to dot 1.
Terry Borroz indicated that he likes thinking of extending the standard beyond chip and board-level. He stated further that he is basically in agreement with Rod. CJ Clark chimed in to say that he agrees with sentiments of Lee and Terry for extending dot 1 to system-level. He stated further that he likes SVF, the capabilities of which meet customer needs.
Math Muris expressed agreement with Lee's assertion that dot 1 may be no longer exciting. However, he said he does not see new problems that need to be addressed by changing the standard. He said he wants to discuss problems with the standard, but the essence of the standard should be considered sacred.
Dilip Bhavsar said that he would like to challenge the working group to continue to look for amendments which, like CLAMP and HIGHZ, make improvements within a framework consistent with the existing standard. However, he said that any new developments should be left to another standard.
Ken Parker suggested that the working group should solicit companies which are involved in efforts to extend the standard. These companies would present their approaches to the working group, which would then review these and make recommendation. He also worried that a preoccupation with excitement might prevent us from nurturing adoption of dot 1 by the wider industry.
Gordon Robinson presented his view, saying that mistakes in dot 1 implementation are limiting the adoption of the standard. The standard is thereby threatened. He suggested that the scope of the standard should remain unchanged. However, he would encourage development of additional instructions etc. for providing additional capability. He also suggested that there is a basic problem with the structure of the document relative to adding instructions. While he encouraged the writing of application notes, guides, ancillary standards, etc., he said that he strongly favors "heavy stability" of the existing standard.
Markus Robinson stated a concern that the working group needs to be aware of activity to provide HDL entry tools for boundary-scan insertion. He noted that certain types of BSR optimization can only occur following core synthesis. He noted further that the working group has not looked at HDL descriptions of dot 1 implementations. As a designer, he asked, "how do I know my design is compliant?" He stated that his company, Synopsys, cannot verify compliance except by construction. He noted further that compliance verification has historically been dealt with by downstream tools. He cited a need for a mechanism for formal verification.
Markus continued to say that "rabbit" users like a push-button approach to boundary-scan insertion, but fear the above problems. Another problem is how to test the boundary-scan logic, itself. He identified these as fertile areas for providing value and instruction to users. Finally, Markus noted that a large number of Synopsys-based designs (30-40%) use boundary-scan.
Colin stated a desire to see a clear statement of goals for the working group. He said that he would like to see an effort to provide "enabling legislation" to support/coincide with other standards. He concluded by saying that he thinks it appropriate for the new chair to propose a "vision" for the working group.
Najmi Jarwala moved that the subject reports of section 10 (agenda items 10.1- 10.5) be moved to follow the agenda items of section 11 (1995 Reaffirmation/Revision). Math Muris seconded. Unanimous approval.
(editor's note, pursuant to this motion, items 10.1-10.5 of the agenda will appear out of sequence, following section 11)
Gordon Robinson opened the discussion by noting that IEEE rules require reaffirmation and/or revision of Std 1149.1 in 1995. He noted that we will need to file for extension as required if the revision process continues beyond the end of the year.
Najmi Jarwala proposed that we look to go to ballot by the end of the year. Gordon suggested that we set an objective to go to ballot as soon as possible, but that we need first to decide what work needs to be done.
Grady Giles suggested that additional meetings may be required depending on the amount of work involved. Markus Robinson suggested that we want to specify our goal in terms of balloting after a given number of meetings.
Colin Maunder moved that the list of topics to be considered for 1995 revision be closed upon the end of this meeting. Najmi Jarwala seconded. Unanimous approval.
Colin inquired as to whether the entire document must go out for ballot. Najmi Jarwala and Rod Tulloss concurred in their response that opening the document for revision does subject the entire document to ballot. Colin replied then that balloting may open other issues, he asked again if we can present only changes for ballot. Gordon agreed to investigate the matter.
ACTION -Gordon Robinson to inquire the IEEE Standards staff to determine the ballot requirements for 5th-year revision.
Markus wondered if we have a target for ballot. Gordon suggested that we revisit the schedule after identifying the list of topics to be considered.
Gordon Robinson described the characteristic of this cell as such that even if separate in and out cells are specified, the input cell is only required to capture data when the cell is acting as an input. He suggested that changes per his email (dated 941026) be implemented in the revision to specifically rule this cell non-compliant.
Najmi Jarwala moved that the standard technical editor revise the document pursuant to Gordon Robinson's 941026 email such that the "preposterous bidir" cell would be no longer compliant. Math Muris seconded. Unanimous approval.
ACTION -The standard technical editor to revise the document pursuant to Gordon Robinson's 941026 email such that the "preposterous bidir" cell would be no longer compliant.
Markus Robinson, however, pointed out that the prototype changes in the referenced email are ambiguous and need to be fixed. This was noted by the standard technical editor.
Gordon Robinson asked if we want to consider pin-driver models in the 1995 revision.
Colin Maunder moved that a subcommittee be appointed to look at test problems which arise from these issues and proposed solutions. Ken Parker seconded.
Adam Ley suggested that the problem of open-drain driver with output enable needs to be addressed by this activity. He also noted that pin-drivers and SAMPLE are closely related.
Markus Robinson offered a friendly amendment such that if the subcommittee cannot report back to the working group with a solid proposal by the next meeting the issue would be dropped from consideration for 1995 revision.
Rod Tulloss commented that he sees Grady's proposals as indicating that the language of the standard which refers to "a buffer" or "the buffer" is at the core of the problem. He stated concern that we don't have a grip on how far to go with this issue.
Markus noted that the spirit of his amendment was not to kill consideration of the proposal but only to ensure that is does not unnecessarily delay the 1995 revision process.
Colin stated a need to be concerned with how new driver/buffer types are to be handled. Rod commented that he does not see this as a "blue sky" issue. He suggested that it could be very containable and could enable IC vendors to accommodate user needs in a very practical way.
Gordon agreed that we need a clear identification of the problem and a clear solution.
The question was called. Unanimous approval.
The following persons volunteered to work on the subcommittee: Grady Giles, Adam Ley, Colin Maunder, Ken Parker, Gordon Robinson, Rod Tulloss, Lee Whetsel.
ACTION -A "pin buffer/driver" subcommittee to look at test problems which arise from the issues of pin buffer/driver behavior and models and the proposed solutions for addressing these issues.
(editor's note, as noted above in section 8.4, it was agreed that item 11.5 be treated following all other scheduled items of section 11; therefore, this section will appear out of sequence, following section 11.???)
Adam Ley presented a slide to summarize proposed changes to rules related to EXTEST opcode. A representation of this slide follows:
- delete 7.7.1b - recommend all zeros ==> bypass - modify BSDL
Gordon Robinson stated that he is uncomfortable with the position of having a recommendation which goes against something mandated in the existing standard. Rod Tulloss suggested a compromise position of recommending that all-zeros not be used for user-defined instructions.
Colin Maunder moved that rule 7.7.1b be deleted along with any associated description and that BSDL be updated to reflect these changes. Markus Robinson seconded. Approved with 12 for, 2 against.
ACTION -Standard technical editor to delete rule 7.7.1b along with any associated description and to update BSDL to reflect said changes.
Ken Parker moved that the a standard operating procedure be implemented such that BSDL track all changes to the main standard. Rod Tulloss seconded. Unanimous approval.
ACTION -Standard technical editor to make any indicated changes to BSDL in order that BSDL track all editorial and technical changes to the main standard.
Lee Whetsel moved that descriptive text be Dilip Bhavsar seconded. Unanimous approval.
ACTION -Standard technical editor to add descriptive text to section 7.7.2 to explain the deletion of rule 7.7.1b.
Lee Whetsel began the discussion with the first slide of a prepared presentation. A representation of this slide follows:
Instruction Register
- - - - - - - - - - - - - - - -
| |
-----------------------
| | | |
TDI ---------->| Shift Register |----------> TDO
| | | |
-----------------------
| | |
v
| ----------------- |
( )
| ( ) |
( Decode Logic )
| ( ) |
( )
| ----------------- |
|
| v |
-----------------------
| | | |
| Output Latch |
| | | |
-----------------------
| |
- - - - - - - - - - - - - - - -
^
/ \
| |
-----------
| |
| TAP |
| |
-----------
^ ^
| |
TCK TMS
- No added pins, just internal parity checking by decode logic
- If parity error occurs, output from decode logic forces Bypass
- Parity tested by a "Long" DR scan to check path length
- If length is OK, "Long" DR scan loads data, else goto TLRST
Gordon Robinson noted that this is essentially an application of the standard which requires no changes to the standard. Gordon did recommend use of TRST* on such ICs so that in case of instruction or data error they may be immediately reset. Adam Ley commented that even if these ICs have TRST*, other ICs on board may not - so, such board-level applications do present some hazards.
Markus Robinson inquired as to whether BSDL specifies parity or just opcode. Ken Parker responded that only the opcode is specified, but that this must encompass any parity bit, and there is no need to know device has parity.
Lee continued to present slides 2, 3 and 4 of his presentation. Representations of these slides follow:
Instruction Register
- - - - - - - - - - - - - - - -
| |
-----------------------
| | | |
TDI ----->| Shift Register |----------> TDO
| | | |
-----------------------
| | |
v
| ----------------- |
( )
| ( ) | |\
( Decode Logic )-----| >--> TSO
| ( ) | |/
( ) |
| ----------------- | |
| |
| v | |
----------------------- |
| | | | |
| Output Latch | |
| | | | |
----------------------- |
| | |
- - - - - - - - - - - - - - - - |
^ |
/ \ |
| |----------------+
----------- IR-Pause
| |
| TAP |
| |
-----------
^ ^
| |
TCK TMS
Test Signaling Output (TSO)
Instruction Parity Error (IPE)
- Pre-Update Instruction parity checking using TSO pin
- Decode logic outputs IPE to TSO pin during IR-Pause
- Decode logic updates Bypass to output latch on IPE
Instruction Register
- - - - - - - - - - - - - - - -
| |
-----------------------
| | | |
TDI ----->| Shift Register |--------------------> TDO
| | | |
-----------------------
| | |
v
| ----------------- |
( )
| ( ) |
( Decode Logic )--------->|\ |\
| ( ) | | |--| >--> TSO
( ) DPE->|/ |/
| ----------------- | | |
| | |
| v | | |
----------------------- | |
| | | | | |
| Output Latch | | |
| | | | | |
----------------------- | |
| | | |
- - - - - - - - - - - - - - - - | |
^ | |
/ \ | |
| |---------------------*----+
----------- IR/DR-Pause
| |
| TAP |
| |
-----------
^ ^
| |
TCK TMS
Test Signaling Output (TSO)
Instruction Parity Error (IPE)
Data Parity Error (DPE)
- Pre-Update Instruction & Data parity checking using TSO pin
- Decode logic outputs IPE to TSO pin during IR-Pause
- Decode logic outputs DPE to TSO pin during DR-Pause
- Decode logic updates Bypass to output latch on IPE
Instruction Register
- - - - - - - - - - - - - - - -
| |
-----------------------
| | | |
TDI ----->| Shift Register |--------------------> TDO
| | | |
-----------------------
| | |
v
| ----------------- |
( )
| ( ) |
( Decode Logic )------------------>|\
| ( ) | | | |\
( ) DPE->| |--| >--> TSO
| ----------------- | | | |/
| +->|/ |
| v | | | |
----------------------- | | |
| | | | TEO-1->|\ | | |
| Output Latch | | |-+ | |
| | | | TEO-n->|/ | |
----------------------- | | |
| | | | | |
+------------------------+ | |
| | | |
- - - - - - - - - - - - - - - - | |
^ | |
/ \ | |
| |------------------------------*----+
----------- IR/DR-Pause or RT/IDLE
| |
| TAP |
| |
-----------
^ ^
| |
TCK TMS
Test Signaling Output (TSO)
Instruction Parity Error (IPE)
Data Parity Error (DPE)
Test Event Output (TEO)
- Pre-Update Instruction & Data parity checking using TSO pin
- Decode logic outputs IPE to TSO pin during IR-Pause
- Decode logic outputs DPE to TSO pin during DR-Pause
- Decode logic updates Bypass to output latch on IPE
- TSO permits TEO signaling
Colin Maunder noted that his proposal for parity output does not require extra pins (TDO pin has shared-function).
Lee continued to present slide 5 of his presentation. A representation of this slide follows:
-----------------
( )
( Non-Functional )
Instruction--->( (Off-Line) )---> TEO-1
Run-BIST-1 ( BIST-1 )
( )
-----------------
-----------------
( )
( Non-Functional )
Instruction--->( (Off-Line) )---> TEO-2
Run-BIST-2 ( BIST-2 )
( )
-----------------
-----------------
( )
( Non-Functional )
Instruction--->( (Off-Line) )---> TEO-n
Run-BIST-n ( BIST-n )
( )
-----------------
TEO's Signal When:
BIST Begins
BIST Is In Progress
BIST Ends
Colin suggested that parity enabled in TDO is still and alternate idea worth looking at. However, he acknowledged that Lee's ideas illustrate where the idea of "enabling legislation" could be helpful.
Grady Giles suggested that Lee's ideas could be embellished by gating 3-state enables on parity error.
Gordon Robinson pointed to the need to specify a general mechanism which enables such additional capability without specifying a large number of implementation details.
Math Muris asked if such capabilities are proposed to be optional. He also noted that BSDL would need to be upgraded to describe such capabilities.
Rod Tulloss suggested that a TAP would be required on the device which interprets TDO. Colin noted that decoding states is also a problem for dot 5. Adam Ley suggested that problems in dot 5 are moot for this discussion. He noted further that the 1149.1 bus master/controller, which is sending the TAP states to the target scan chain, would be the device which would manage parity messages.
At this point, being rather late on the evening of March 4 and having dinner reservations, the working group moved en mass to adjourn until 9:00am the following day. Unanimous approval.
The remainder of Lee Whetsel's presentation was not treated. However, his slides 6 and 7 are entered into the meeting record here. Representations of these slides follow:
Instruction Register
- - - - - - - - - - - - - - - -
| |
-----------------------
| | | |
TDI ----->| Shift Register |--------------------> TDO
| | | |
-----------------------
| | |
v
| ----------------- |
( )
| ( ) |
( Decode Logic )------------------>|\
| ( ) | | | |\
TSI->TEI ( ) DPE->| |--| >--> TSO
| ----------------- | | | |/
| +->|/ |
| v | | | |
----------------------- | | |
| | | | TEO-1->|\ | | |
| Output Latch | | |-+ | |
| | | | TEO-n->|/ | |
----------------------- | | |
| | | | | |
+------------------------+ | |
| | | |
- - - - - - - - - - - - - - - - | |
^ | |
/ \ | |
| |------------------------------*----+
----------- IR/DR-Pause or RT/IDLE
| |
| TAP |
| |
-----------
^ ^
| |
TCK TMS
Test Signaling Output (TSO)
Test Signaling Input (TSI)
Instruction Parity Error (IPE)
Data Parity Error (DPE)
Test Event Output (TEO)
Test Event Input (TEI)
- Pre-Update Instruction & Data parity checking using TSO pin
- Decode logic outputs IPE to TSO pin during IR-Pause
- Decode logic outputs DPE to TSO pin during DR-Pause
- Decode logic updates Bypass to output latch on IPE
- TSI/TSO permits TEI/TEO signaling
-----------------
( )
( Functional )
Instruction--->( (On-Line) )---> TEO-1
Run-BIST-1 & TEI ( BIST-1 )
( )
-----------------
-----------------
( )
( Functional )
Instruction--->( (On-Line) )---> TEO-2
Run-BIST-2 & TEI ( BIST-2 )
( )
-----------------
-----------------
( )
( Functional )
Instruction--->( (On-Line) )---> TEO-n
Run-BIST-n & TEI ( BIST-n )
( )
-----------------
TEI Signals When:
BIST Should Begin
TEO's Signal When:
BIST Begins
BIST Is In Progress
BIST Ends
The meeting was reconvened by working group chair Gordon Robinson on March 5 at 9:00am. Grady Giles was the only member present for the March 4 session, who was not present at this time. However, as will be noted below, he did enter the meeting later in the day.
Najmi Jarwala suggested that in light of the informal nomination of CJ Clark to working group membership which took place at last night's dinner, a formal record of such should exist.
Najmi Jarwala moved that CJ Clark, having met all requirements for membership, should be named a working group member and granted all such rights. Dilip Bhavsar seconded. Approved by acclamation.
Gordon Robinson requested that, since he had been tacitly asked to provide a sense of his vision for the standard and that since the decisions to be made throughout the day might be affected by such, he be allowed to present such at this time. There being no objection, Gordon presented a slide which summarized this vision. A representation of that slide follows:
1) 1149.1 is a chip-level standard
defining facilities for use in
board, system (and some chip) test
and maintenance
2) 1149.1 must be
Correct
Understood
Stable
Obeyed
- Fix errors
- Explain misunderstandings
- Evolve where out of line
with technology
- Evolve where tradeoffs widely
perceived as wrong
+ Chip designers
+ Test/Maintenance users
+ Tool builders
3) Encourage applications based on
existing framework
- Recommended Practices/extra stds
rather than "larger" .1
4) Extend framework (compatibility) to
meet needs of applications
- Fault tolerance
- Emulation
Gordon noted that he considers the working group mandate pursuant to his point 2 to be to address errors (Correct), clarify misunderstanding (Understood), minimize extent of changes (Stable), and ensure practice follows standard (Obeyed).
Najmi Jarwala commented that system-level extensions to boundary-scan seem to be proliferating and growing in popularity for test/maintenance applications. He wondered whether a subgroup to look at such T&M solutions would be indicated.
Colin Maunder noted that the ASP and other such extensions seem mostly to be outside of Gordon's scheme. However, he suggested that some accommodating changes - such as reserving the use of TDO - might be needed in dot 1.
Gordon concurred that SCAN Bridge/ASP are out of the scope of dot 1. However, he suggested that there may be benefit to standardization of such approaches. He noted that there is extensive precedent for families of related standards. Najmi noted that the spectrum of system types may be large enough to encompass and accept many solutions.
Tom Williams suggested that such issues be worked within the framework of 1149.5. Najmi countered that 1149.5 has standardized an existing practice of more than 10 years, while SCAN Bridge and ASP are emerging practices which don't fit in the 1149.5 framework. He wondered if there were some way that standardization could be encouraged.
Colin noted that logical naming of such alleged standards would be better served if all 1149.x standards fit the same level of hierarchy. He noted that dot one might have better been served by better internal partitioning.
Gordon suggested that it is too late to change 1149.x history. However, he did note that 802 has a precedent of refinement of divisions.
Colin suggested that in the case of P1149.5, the name would not be fixed until the standard is promulgated. Gordon and Najmi both pointed out that any name changes would be a matter for the Test Technology Standards Committee.
Colin stated his opinion that with respect to fitting within the dot 1 framework, ASP/SCAN Bridge are out, parity is in, event qualification is borderline.
Gordon noted that if a mechanism were introduced which would signal events to external logic, that an input to respond to externally-signally events would be a logical follow-on.
Lee Whetsel reinitiated the subject discussion of the agenda item (11.7. Parity (including IR-Scan and DR-Scan Error Detection)) with a summation of his presentation of the preceding afternoon.
Gordon Robinson commented again that Lee's "bare-bones 1149.1 parity" is in fact a compliant application/implementation of the existing standard. He suggested that a recommended practice or application note could be drafted to communicate this application to the user community. Colin noted that he already has the basis for such a document.
Math Muris expressed concern about how ATE can comprehend the behavior of such devices. Colin noted that one is simply populating the IR space with a large number of opcodes which map to BYPASS - there is no need for ATE to comprehend any other complexity.
Ken Parker asked if parity would need to be acknowledged in BSDL. Gordon responded that it would not be required. However, Ken noted that it might be valuable to have software support for parity. This could be provided with a simple parity "flag" in BSDL.
Gordon summarized the discussion by saying that had heard two motions forming, 1) changes to BSDL, 2) admission of Lee's extra pin(s).
Tom Williams argued that the parity implementation of Lee's "Bare-Bones" approach is completely compliant and that therefore there are no issues and no need for BSDL changes. Najmi suggested that there may be value in BSDL support for semantic checking.
Rod Tulloss noted that intelligence as to whether parity is supported in some or all devices on a board may need to be acquired via BSDL. As an aside, he wondered if the practice of using DR "headers" is common. Terry Borroz stated that there may be some advantage to knowing that certain devices fail in a specific way.
Colin disagreed, saying that such proposed changes only accommodate parity and therefore only single-bit errors. In order to allow a full range of fault- tolerant schemes, no assumptions can be made. Adam Ley agreed.
Dilip Bhavsar noted that BSDL needs only to document the fault tolerance attribute. Gordon, however, suggested that the purpose of BSDL is to allow defined facilities to the described to tools.
Colin Maunder moved to encourage Lee Whetsel, et.al. to document a recommended practice for such applications. Terry Borroz seconded. Unanimous approval.
ACTION -Lee Whetsel to document a recommended practice for compliant implementations/applications for instruction and data parity.
Colin Maunder moved that any action on error-detection scheme specified by the working group should accommodate multiple error-detection schemes - not just simple parity. Dilip Bhavsar seconded. Approved with 13 for, 1 abstention.
Lee inquired as to what this means for his proposal for IR & DR parity with TSO pin. Gordon responded that the fundamental concept is of the addition of a pin to indicate IR and DR errors and/or other error/event signals.
Colin expressed a desire to discuss the tradeoff of using an extra pin versus reusing TDO for this purpose.
Colin Maunder moved that (to be named) develop an optional facility which supports the reporting of scan errors prior to update and other events in states to be named. Rod Tulloss seconded.
Lee suggested that enabling events in Test-Logic-Reset state seems to be beyond the control of 1149.1 and therefore difficult to manage. Rod noted that some device has to keep track of the TAP state so as to understand the significance of error/event signals. Also, additional status registers might be required to further refine the source of the error/event.
Adam noted that with the addition of an event input pin, Lee's goal of using 1149.1 to set-up normal-mode on-line testing can be achieved. Colin disagreed.
Ken Parker suggested that he would like to see the possibility here of reusing a system input. Dilip Bhavsar concurred, noting that he would use such capabilities for chip-manufacturing test and reuse pins through compliance enable facility.
The question was called. Approved with 13 for, 1 abstention.
ACTION -An "error/event" subcommittee develop an optional facility which supports the reporting of scan errors prior to update and other events in states to be named.
Najmi Jarwala moved that such error/event signaling be specified to be implemented by use of a separate pin. Dilip Bhavsar seconded.
Ken Parker suggested that BSDL should describe which pin would be used.
Colin suggested that the addition of a pin will be a barrier to acceptance of such mechanisms - he once again suggested reuse of TDO pin. Najmi questioned how such an implementation would fit into hierarchical implementations.
Najmi Jarwala and Dilip Bhavsar withdrew the motion at hand.
Najmi Jarwala moved that the decision as to whether such capabilities should be implemented by use of a separate, additional pin, or not, should be assigned to a subcommittee for further study. Dilip Bhavsar seconded. Unanimous approval.
Najmi Jarwala moved that the decision as to whether to support error/event inputs and any consequent need for input pins should be assigned to the same group. Dilip Bhavsar seconded. Unanimous approval.
The following working group members volunteered to be work on the subcommittee: Dilip Bhavsar, CJ Clark, Najmi Jarwala, Colin Maunder, Rod Tulloss, Lee Whetsel.
ACTION -The "error/event" subcommittee should decide whether the error/event signalling facility should be implemented on a separate, additional output pin and if a facility for input of error/event signals should be provided along with required input pin(s), if any.
Tom proposed that any such proposals should be testable.
Dilip Bhavsar moved that the standard technical editor attach notes to IR implementations in the standard which illustrate decode logic following latches - such notes to explain why such design practice is not recommended. Ken Parker seconded.
Markus Robinson suggested that the current implementation examples may in fact need warning but that they need not be changed as they can be valid. Colin went further to say that the standard is already filled with enough "general health warnings." He stated that he feels no further warnings are required.
Dilip Bhavsar and Ken Parker withdrew the motion at hand.
Ken noted that there is an implication of the standard that a one-to-one relation exists between shift latches and hold latches. He suggested that descriptions to the effect that this will not always be required might be helpful.
At this point, Najmi Jarwala suggested that the agenda be reprioritized to treat the issue of the purpose of sample as early as possible. There being general agreement, the working group moved on to agenda item 11.5 (out of sequence).
Ken Parker began by noting that a discussion which began with the question of whether SAMPLE and PRELOAD should be divorced has evolved into a question of the purpose of SAMPLE. He said that while SAMPLE has been noted to be analogous to guided probe, it really gives more capability as it now exists (allows knowledge of which drivers are supposed to be on versus off the bus). He suggested that SAMPLE could perhaps be liberalized to provide option to capture only the state of the pin so the such cells as the Single-Cell Bidirectional could be allowed
Dilip Bhavsar inquired as to the purpose of guided probe. Ken responded that guided probe shows the "net" state of a given node - it does not show which drivers are on versus off. SAMPLE as currently defined does allow enable state to be determined.
Colin suggested that there is little benefit for backing off of the stated value of SAMPLE - only a limited number of cells would be eliminated. Rod agreed, noting that if made optional, we might find that few devices implemented the desired SAMPLE capabilities.
Math Muris suggested that one can only prove at what point an output signal is captured (prior to buffer/driver, or at pad/pin following buffer/driver) by doing a potentially destructive test - that is, to hold the output to a state which is opposite that intended. He suggested further that this suggests the rule which requires the output of the on-chip logic to be captured in SAMPLE, rather than the pin value, may be invalid.
Najmi noted that the current SAMPLE does have added diagnostic capability beyond that provided if the pin/pad were allowed to be captured.
Gordon noted that the rules for bidirectionals indicate that 2 cells are, in fact, required to support SAMPLE. However, he noted further that the implementors of GTL, who use such self-controlled bidirectionals, are reluctant to use 2 cells on such pins. Colin countered that we must maintain the integrity of the standard as opposed to bowing to every demand of IC implementors.
Colin suggested that there are two ways of "liberalizing" SAMPLE with respect to the single-cell bidirectional: 1) allow the cell as drawn; 2) require that when the output is 0 (active) capture 0 (irrespective of pin state), and when output is 1, capture pin.
Rod suggested that we shouldn't relax concerns related to "un-probe-abilty" of systems. He noted that we are just now realizing applications beyond board manufacturing test. He also noted the use of SAMPLE to "grab" states. He concluded, saying that it seems unwise to alter the intent of SAMPLE at this time.
Tom countered that it is a folly to assume that the crossing of a physical boundary is the appropriate point to detect such errors. Colin noted that he is concerned with devices not designed with detailed knowledge of board-level application. Tom suggested that normal functional signals can't be captured anyway - due to timing constraints, invalid and/or metastable values will be captured.
Lee offered a diagram to clarify the issue of the single-cell bidirectional. A representation of this slide follows:
^
|
/
\
|\ /
>-----*---------------------|\ | \ |
| | |----|OC>--*--[PAD/PIN]---*
| +--|/ | / |
|\ | |/ |
"0"--|0| ----- ----- | |
| |--| C |---| U |--+ |
+-|1| | | | | |
| |/ ----- ----- |
| |
<--*-------------------------------------+
IF "1" CAPTURED THEN:
a) THIS & ALL BUFFERS ARE OFF
IF "0" CAPTURED THEN:
THIS BUFFER IS ON OR AT LEAST ONE OTHER IS ON
Colin expanded upon this by noting that if a "1" is captured, then all devices must be in agreement (and are driving the intended value "1"), while if a "0" is captured, and the bus disagrees (i.e., it is a "1"), we can know which device is not achieving the intended value.
CJ Clark stated that he would prefer only to relax rules for single-cell bidirectional versus complete removal of SAMPLE. He said that he finds SAMPLE very useful in the area of system-level debug. He stated further that it is too early to remove requirement for SAMPLE - he suggested that catalog vendors would be quick to abandon the capability if it were optional.
Ken stated that he believes that Lee's circuit will allow one to first determine if a newt has a wrong value, and if so, which driver is "frustrated." He stated further that therefore this degenerate case does meet the requirements of SAMPLE.
Gordon suggested that whether this cell meets requirements of SAMPLE is problematic, but is not germane to the discussion at hand - the purpose of SAMPLE.
Lee noted his thought that the addition of TSI for event qualification will demonstrate the value of SAMPLE.
Dilip stated that he wants to see the issue of his cell resolved.
Najmi Jarwala moved that the 1995 revision of the standard should not change the specified behavior of SAMPLE (per section 10 rules). Rod Tulloss seconded.
Gordon suggested that we note that compliant implementation of a single-cell bidirectional is possible. Ken presented a diagram of a reduced-logic implementation of "Lee's single-cell bidirectional." A representation of this slide follows:
^
|
/
\
|\ /
>--*------------------------|\ | \ |
| | |----|OC>--*--[PAD/PIN]---*
| AND +--|/ | / |
| / | |/ |
+--- ----- ----- | |
| )--| C |---| U |--+ |
+--- | | | | |
| ----- ----- |
| |
<--*-------------------------------------+
Colin Maunder suggested that rule 10.6.1d precludes open collector drivers.
Math Muris stated that he would like to see the physical point of capture at outputs allowed to be at the pad.
The question was called. Approved, 7 for, 5 against, 1 abstention.
ACTION -The standard technical editor shall not make any changes in the 1995 revision of the standard that would change the currently specified behavior of SAMPLE (per existing section 10 rules).
Following a lunch break, a discussion related to the requirement for BSDL broke out. It was pointed out that the IEEE is now allowing appendices to be labelled "normative" and thereby a legitimate part of the standard.
Najmi Jarwala moved that the phrase "informative" in the opening note to Appendix B be changed to "normative" and a rule added to chapter 12 to require IC's to have supporting BSDL. Colin Maunder seconded.
After much discussion in which Rod Tulloss, Colin Maunder and Markus Robinson were the chief participants, Adam Ley noted that chapter 12 already requires that b/s device facilities be documented. BSDL is simply a form, albeit preferred, of such documentation.
Najmi Jarwala and Colin Maunder withdrew the motion at hand.
Ken Parker moved that the requirement for SAMPLE/PRELOAD should not be changed for the 1995 revision. CJ Clark seconded.
Tom Williams suggested that this motion might be inappropriate at this time as later issues to be discussed might cause it to be contravened. He further suggested that he be allowed to take the floor to discuss said issues.
Ken Parker and CJ Clark withdrew the motion at hand.
Tom took the floor and presented the four slides of a prepared presentation. A representation of these slides (pages 4, 5, 6, and 8 of 10) follows:
+ Current State - Accepted by a Number of Design Groups - Boundary Scan Description Language, BSDL Passed! _ Manufacturing Sites are Pleased to Receive 1149.1 + There are Problems - Reuse of Boundary Registers as Function - Performance and Overhead!
+ Draft being finalized - Objectives - Wire Test - Reuse of Boundary Scan Registers - TAP of Encoded Controller
+ Problem Areas:
* Sample
- Not a real Problem if Eliminated
* PreLoad
- 3-state Conflict, device Damage...
A REAL PROBLEM
+ If Chip Design Group Wants to
- Use Boundary Scan Flip Flops Functionally
- The need an extra Primary Input
* Held High all 3 States are forced to High Z
* Scanning can occur with NO BURNOUT!
* Test Generation is Required to Provide Correct
Values.
Tom also presented a diagram to illustrate the proposed primary input and associated logic. A representation of this slide follows:
| ------
| --| D |
+---- | |----O PO
| )---| E |
HighZ PI O-------- ------
Colin stated that before discussion goes further, we need to understand why designers are deviating from the standard. Tome cited area and performance as being the two determining factors.
Ken Parker asked if we could explore the idea of sharing the update latch (with functional logic) versus the capture latch. Tom countered that this still leaves the performance issue - which essentially relates to what is in front of the driver.
Colin noted that he has earlier proposed a shared update latch circuit which eliminates the performance issue. Tom countered that his circuit has the best possible performance.
Colin noted that concerns issued during the ballot resolution included PRELOAD as well as SAMPLE. Tom concurred that PRELOAD presents a problem.
Lee Whetsel suggested that cell implementations illustrated in the standard may be taken by some to be the only valid implementations. He also stated that truly high performance BSCs might not be shared by IC vendors for competitive reasons.
Dilip Bhavsar noted that while he wished such factors had been better considered earlier, the changes proposed at this time would dismantle dot 1. He noted that the dot 2 architecture is completely different.
Ken suggested that the problem is not just that high Z at outputs may be undesirable, but that the resulting floating inputs of downstream devices might cause unexpected/undesired conflicts at output of such ICs. Colin added that Tom's proposal would clearly rule out universal use of cluster testing. Najmi noted that he had brought this objection on the same topic at ITC.
Colin noted that the requirement for cluster testing will be reduced as the number of boundary-scan ICs increase. However, he noted that other overhead- saving implementations would meet cluster test requirements.
Gordon summarized the discussion saying there were 3 things we could decide:
Najmi Jarwala moved that Tom Williams' "shared-I/O" proposal be rejected by the working group and that consequently no changes to the standard would be made. Rod Tulloss seconded. Approved with 11 for, 1 against, 1 abstention.
The remainder of Tom's presentation was not treated in the meeting but was handed over to the minute's editor for inclusion. They are therefore, so included as follows (pages 1, 2, 3, 7, 9, and 10 of 10).
T. W. Williams
VLSI Design for Testability
5 Oct. 1994
+ Management VLSI Design Rules Control + For IBM's Electronic Design Automation + Tool: TestBench
- Future Architectural Direction with Emphasis on Test - Teaching design Groups How to Design with: * LSSD * Embedded RAM and ROMs * Three State Design Rules * IBM Boundary Scan * IEEE 1149.1 * Self-Test * ? * ? - Both Internal IBM Groups and Outside IBM * For Example: IBM ASIC Customers
+ IBM Three State Design Rules:
- Part of Scan Gating
- A Primary Input is held high
* Result in Scan Clocks Connected
* Scan Path Connected
* Three States are Held at High Impedance
* High Z is required for Manufacturing Testing
Compatible with IEEE 1149.1 Compatible with IEEE P1149.2
+ IT IS TIME TO EXPAND THE CAPABILITIES OF BOUNDARY SCAN WHILE STILL BEING WITHIN A STANDARD
Colin noted that he does not find this resolution to be satisfying. He suggested that there would be value in re-examining past decisions to determine which might be suspect.
Gordon also noted that termination of this discussion at this time results in a situation in which some designers may choose or continue to choose not to obey the standard.
Najmi suggested that the issue needs a champion and needs "offline" work. However, Colin noted that working such things over email is difficult. He said that exploratory sessions which allow better face-to-face clarification are needed.
Markus Robinson suggested that preparation is the key to a productive meeting. Gordon noted that the working group had at times past used a two week rule. Any issue for which 2-weeks notice had not been provided could be denied a vote by the objection of only one person. Colin noted further that those items meeting the 2 week rule would be given priority on the agenda.
Gordon state that a desire to have a stable standard now puts the onus on those requesting change to assess impacts and sell benefits relative to costs. Ken suggested that any such guidelines are within the chair's purview.
Rod commented that in earlier days, the working group had used a 3-stage development process. He said the 2nd stage has now been dropped. He suggested that we may now again need some explorative activities and might need to reinstitute this 2nd stage. He also commented that we may be relying too much on computer communication. He suggested that we need a balance of communication types. He further suggested that a medium-level non-schedule-driven level of discussion be reintroduced. Colin asked if we might be able to set up a fax reflector through Piscataway.
Tom commented that he feels the concepts of his proposal are simple and that the impact is clear. He noted that the tone of the discussion seemed to indicate that the decision was, in fact, a consensus.
Rod stated further that his comments were not directed toward any particular presentation. He noted that his thought on these matters began yesterday as decisions seemed to be made hurriedly. He commented further that now that we may have questions about what we want to produce we may need other, exploratory, methods of discussion.
Markus agreed that a middle-level of discussion would be valuable. He said that above all we need to consider our installed base of users. Further, he said that he thinks the vote on Najmi's motion may be due to many not being clear on the impact to users and therefore cannot support such change at this time. Math Muris concurred with this sentiment, saying that if the impact of a change is not understood we must vote no.
Najmi commented that teams fatigue as well as individuals. He suggested that new folks may be needed to take on exploratory roles.
Rod concluded this discussion by again stating that more views are required at the 2nd level. He noted that email may degrade the quality of interaction. He said that social controls are needed to improve the quality of group interaction.
At this point Grady Giles entered the meeting.
Najmi Jarwala began this topic with the first slide of a prepared presentation: A representation of this slide follows (editor's note, at time of this draft, the original slides were not available, so this representation may be incomplete or even inaccurate):
- Permit multiple RUNBIST-like instructions - Expand RUNBIST in 1 of 3 ways 1) Generalize RUNBIST to family 2) Leave RUNBIST as is but define new family 3) Leave standard unchanged but support BSDL attribute
Najmi expressed a preference for the 3rd of the above options. He then presented his second slide. A representation of this slide follows (editor's note, at time of this draft, the original slides were not available, so this representation may be incomplete or even inaccurate):
- Shift in instruction - Shift in data - Wait duration - State of BSR - Scan out response
Najmi presented a third slide which illustrated some examples of the proposed syntax. (editor's note, at time of this draft, the original slides were not available and my notes were extremely sketchy, so no representation is given at this time)
Najmi commented that these examples fall within the base protocol of RUNBIST, they define extensions which allow data registers to be seeded if required, and which allow multiple data registers to be scanned for result.
Michel Parot noted that the goal of such RUNBIST-like instructions are different from RUNBIST even though their operation is the same. He noted further that implementors don't like the use of BSDL extensions to describe such.
Colin Maunder stated that he perceives that Najmi's proposal exceeds what Michel has requested. He said that he sees some of the extended ideas as useful, but as a template for instructions other than RUNBIST. He suggested that WAVES might be useful for expressing such templates.
Markus Robinson commented that the proposed BSDL expresses not only chip architecture but also test context. Gordon Robinson questioned whether we, as a working group, want to recommend and define description of such capabilities. Lee Whetsel noted that TI BIST operations work in a fashion similar to Najmi's proposal.
Michel Parot confirmed that the extended capabilities of Najmi's proposal are not required. He said that he greatly prefers that RUNBIST-like instructions be supported in the standard. He proposed the addition of a section which describes such additional instructions and clarifies the purpose of "the" RUNBIST.
Colin suggested that the instructions as currently documented may be thought of as both class definitions and instances. He noted that dot 4 is going to force us to treat EXTEST on this basis as it will have both "logical" and "physical" instances of EXTEST. He suggested that we consider this in making any such changes.
Grady Giles commented that he likes Michel's proposal but also sees use for seeded BIST and multiple result registers. Lee suggested that a class of USERBIST instructions be defined.
Rod Tulloss moved that a "RUNBIST-like" subcommittee develop a template to describe user-defined RUNBIST-like instructions and assess impact to remainder of standard document. Michel Parot seconded. Unanimous approval.
ACTION -The "RUNBIST-like" subcommittee to develop a template to describe user- defined RUNBIST-like instructions and assess impact to remainder of standard document.
Colin Maunder suggested that work on SVF should not be done in isolation from this work.
The following working group members volunteered to work on this "RUNBIST-like" subcommittee: Colin Maunder, Michel Parot, Rod Tulloss, Lee Whetsel.
Colin queried as to whether other subcommittees still required to be populated. Adam responded that the only such group was the interpretation response subcommittee(s).
Gordon noted that the current standing body consists of the following members: Colin Maunder, Rod Tulloss, Lee Whetsel, and Tom Williams. He suggested that he and Ken Parker be added.
At this point, Tom Williams requested that the patent issue be discussed. There being no objection, this was done. (editor's note, section 11.15, therefore, occurs out of sequence).
Tom Williams volunteered to be a clearinghouse for papers relevant to 1149.1. He noted the he already has such papers from IBM & Honeywell. He suggested that copies of any relevant papers be sent to him. He would then copy and send to any requesting to be on the mailing list.
Colin noted that it would be helpful if we had an annotated bibliography presenting all known related papers. This could then be made widely accessible through World Wide Web.
As John Andrews was not available to present this topic at this meeting, this topic was not addressed.
Colin noted that the changes agreed upon at the ITC meeting should be posted for public comment. He committed to make such posting on TTTC/1149.1 home page on World Wide Web.
ACTION -Colin Maunder to post changes to compliance enable rules (deletion of rule 3.8.1d) to World Wide Web.
Dilip Bhavsar began this topic with a slide illustrating a chip with on-board oscillator. A representation of this slide follows (editor's note, at time of this draft, the original slides were not available, so this representation may be incomplete or even inaccurate):
----------------------
|
| -----
+--------|--| + |
| | | | -------
----------- | | | | |
| crystal | | | |--| BSR |
----------- | | | | |
| | | | -------
+--------|--| - |
| -----
|
----------------------
Dilip noted that a BSR cell compliant to 10.4.1 does not meet the intended objective - that is, to determine that the clock output of the oscillator is good.
Dilip continued his presentation with a second slide. A representation of this slide follows (editor's note, at time of this draft, the original slides were not available, so this representation may be incomplete or even inaccurate):
1. Allow cell omission when purpose is only EXTEST - Expand exclusion list under 10.4.1c. 2. Recommend clock "sniffer" with BSR cell to cover such clock pins - Add new permission or recommendation to rules (10.5.1s)
Najmi Jarwala inquired as to whether such recommendation would apply only to crystal inputs or for high-speed clocks also. Grady Giles replied that it would ideally apply to both.
Ken Parker noted that he views clocks as an analog reference. Lee Whetsel noted experience at TI with selectable crystal/digital inputs.
Colin Maunder suggested that there is nothing usual about this situation. He said the minus pin is defacto analog while the plus pin is selectable digital/analog - the position of the required boundary-scan cell is clear.
Grady noted that the rule requiring cells at digital interfaces is so open- ended as to be of questionable value.
Gordon recognized the value of clock "sniffers." Colin acknowledged that he also sees value of such but thinks that an application note may be indicated as opposed to changes in the standard.
Ken noted that a context is required in order to know whether the internal cell for clock sniffer should capture 1 or 0 in presence of good clock.
Colin Maunder moved that the proposal in item 1 of Dilip's slide be dropped. Lee Whetsel seconded.
Dilip argued that with ICT absent only a clock "sniffer" can determine good connectivity. Colin countered that it is difficult to describe limits of exceptions. Dilip countered that our strategy for including/excluding features may not be consistent with our test goals and methods.
Rod Tulloss asked if it were always the case that if a digital signal is applied to either plus or minus terminals proper operation will follow. He suggested that an application note be written to describe the value of clock sniffers. Other cases requiring such notes might be when the IC clock is "programmable by environment."
Colin Maunder noted that his work to determine level of interest in revised CS tutorial for 1149.1 is in progress.
The question was called Approved with 13 for, 2 abstentions.
CJ Clark moved that Dilip Bhavsar write an application note treating the issue of boundary-scan cells at clock pins. Ken Parker seconded. Unanimous approval.
ACTION -Dilip Bhavsar to write an application note treating the issue of boundary-scan cells at clock pins.
At this point, time being of the essence, it was decided that the reports of agenda items 10.1-10.5 should be submitted to the working group by email.
ACTION -Adam Ley to report on members whose attendance has not met the required criteria (attend 3 or last 5 meetings).
ACTION -Gordon Robinson to report formal requirements for obtaining and retaining membership in the working group.
Rod Tulloss had prepared a report for presentation to the working group. He submitted it to the minutes editor for inclusion. Representations of these 11 slides follow:
Not assigned formally to a subgroup by the IEEE 1149.1 Working Group. A special interest group has been formed. Meeting 14.xii.1994 followed by email discussion. Persons currently involved in the discussion: Bob Allen, AT&T Wayne Daniel, TI Peter Hansen, Teradyne Najmi Jarwala, AT&T Ken Parker, HP Gordon Robinson, GenRad Rod Tulloss, AT&T (chair)
* No gratuitous changes. * No VHDL. * Keep in mind a wide range of 1149.1 test applications (ATE, system test, etc.) * Within agreed scope, aim for simplicity and compactness * Assure ability to apply any sequence possible given the TAP of IEEE Std 1149.1 * Treat issues of backward compatibility explicitly.
1. Make small changes (when necessary) for linguistic consistency, reduction of ambiguity 2. Define a "constrained block" structure. 3. Create a section of the SVF definition document entitled "Recommended Practices for Generation of SVF Programs Having Maximal Portability." Note-Combined with A. and B. above, this should provide >95 per cent of the needed solution for GO/NOGO test. 4. Define a mechanism for transmission of diagnostic data via SVF.
* Example: TDI, TDO, MASK, and SMASK almost always are used as a global variable to which a value is assigned. However, when assignment of the TDO parameter is omitted, the effect differs from that in all other cases--omission of a TDO parameter is used to indicate that values shifted out of circuit under test are to be ignored. This discrepancy should be eliminated either by requiring the use of an "all don't care" MASK value or by introduction of a new keyword such as "TDOG" (for "TDO iGnore").
* CONSTRAINED BLOCKS shall be units of SVF code within which ALL EXPLICIT STATE- TO-STATE MOVEMENT shall be programmed. * Such blocks shall have "BEGIN" and "END" markers. * Note--Importantly, test programs that avoid Run-Test/Idle would do so ONLY WITHIN constrained blocks. * Note--In some cases, contents of constrained blocks will not be translatable from an arbitrary SVF source to an arbitrary SVF using facility. * Note--If features supporting "binary" programming of the TAP were added to SVF, these features would be required to lie within constrained blocks. * CONFORMANCE TESTING requiring TAP manipulation would be carried out (to the degree possible) within constrained blocks. But see III, below.
* EXTERNAL to constrained blocks, SVF shall support only description of test vectors (DR and IR scan sequences) without explicit state motion control (i.e., programmed assuming a free running TCK signal) or program control (e.g.. branch) structures. *Note--The proposed view deals with a test as an abstract entity independent of the target test environment. Before implementation by various tools, the generation of a set of test vectors was long ago understood. The state transitions utilized by a particular tool's implementation place constraints; however, the Standard is built around a core concept of an abstract set of vectors. * Note--The present proposal places the burden for portability on the boundary- scan test generator. It is possible that everything in an atomic test could be described by SVF language constructs restricted to constrained blocks. There is also a penalty for doing so--potentially reduced portability. * An SVF program without constrained blocks shall be called ATOMIC. Atomic programs are translatable to arbitrary ATE or for use in intra- and inter- board testing in a system. * Should compactness (file size) be a dominant concern (e.g., vs. improved readability in a era in which "viewing aids" are not common)?
* But why bother with the atomic parts? Don't most tools generate tests from circuit descriptions and BSDL anyway? If the sole purpose of a vector transfer format were to move between sophisticated ATEs, then it could be argued that it is not needed. Portability of circuit descriptions would be more useful. * The need for SVF arises when a set of vectors is to be ported to an environment lacking test generation intelligence or in which it is desirable to emulate behavior of another environment (e.g., an ATE). * In moving to a system test environment, interconnect and BIST dominate requirements. In moving to a bench top emulation of an ATE (e.g., for design debugging) constraint blocks may or may not take dominance depending on the "native mode" of the source and target machines. * Should the ability to describe normal ATE vector application (e.g., end every vector application in Run-Test/Idle) be part of SVF or a run time parameter for a translation toll or..? At any rate, such a description is not a part of an atomic SVF test.
* No matter what the appropriate place for the description or parameterization is, it must supply the ability to describe implementation specifics on state transitions between vectors in uninterrupted vector application between sets of vectors in cases in which a local vector memory must be reloaded in mid-test at the termination of application of a set of vectors. * This capability is being called a "test application behavior template."
* The portability section envisioned for the SVF specification would describe constraints on SVF generation that will make SVF translation simple and make test programs conveyed in SVF as portable as possible. * The essential recommendation is that SVF be generated so that all application of IEEE Std 1149.1 required and recommended commands be presented in application neutral form--with free running clock assumed. * Note--At the receiving end and SVF program written in application neutral form is translatable into any ATE's favorite mode of vector application. * Note--RUNBIST can be accommodated here because it is required to operate correctly in an environment with free running clock that might run beyond the number of cycles necessary to "get the answer." NOTE: Combined with II.1 and II.2 above, this should provide > 95 per cent of the needed solution for test transport and translation.
* Tabular approach suggested by Ken Parker and circulated via email.
* TMS low-level programming * The multi-chain issue.
ACTION -Math Muris and Najmi Jarwala to report on their discussion of issues of MCM support in 1149.1 and thereby educate and bring issues to the working group as appropriate.
ACTION -Colin Maunder to report on his progress toward 1149.1 Applications Guide.
Grady Giles reported that boundary-scan has been implemented on a Motorola FSRAM in a write-only fashion (that is, treating I/O-pins as inputs only).
Colin Maunder reported that Intel has cache RAMs with boundary-scan.
Gordon Robinson reported that other Motorola RAMs claim to have boundary-scan but not 1149.1.
Grady suggested that we can serve a wider community by allowing such RAMs. Lee Whetsel countered that if we make exception for RAMs what else will be excepted.
CJ Clark noted that most customers can perform read/write emulation to RAMs to accomplish interconnect test.
Ken Parker suggested that a key point to consider is that RAMs don't have boundary-scan and may never have it if we don't make exception.
Colin Maunder noted that Philips has put forth methods for interconnect test on RAM without boundary-scan. He suggested that the key issue with the Motorola FSRAM is that it hints at compliance to 1149.1 when it clearly is not.
Math Muris concurred that he had previously presented a paper on memory interconnect ATPG. However, he noted that a larger number of vectors are required than if the memory had boundary-scan (contrast 600 vs 20).
Markus Robinson asked if there were value in standardizing this practice. He asked further if it were critical to acceptance of the standard.
Dilip suggested that the opportunity here is to discuss ways in which compliant devices interface to such devices.
Grady noted that he has thought that such RAMs may need to claim conformance to establish a marketing position which would allow them to promote boundary-scan on RAMS.
Grady Giles proposed that time is required in such circumstances following indication of update to setup a safe state in normal operation.
Gordon suggested that changes as to when update would occur would not be viewed kindly unless a concerted consensus from microprocessor vendors could be identified. He suggested further that Grady should provide much more detail on problem and proposed solution if the subject is to be considered by the working group.
Gordon proposed Portland, Maine (sponsor - National Semiconductor) and San Francisco, California (sponsor - Synopsys) as possible sites for the next working group meeting. He suggested further that the meeting be held in mid- July. He offered to take action to solicit location sponsors and to determine the actual place and time for the meeting. He suggested that he had observed a strong preference for the Maine location and would work that option as a first priority.
ACTION -Gordon Robinson to solicit potential sponsors of Portland, ME (NSC) and San Francisco, CA (Synopys) to determine place/time of next meeting.
No other business was addressed.
Tom Williams moved to adjourn. Rod Tulloss seconded. Approved by acclamation.
ACTION -A subcommittee (to be named) to address the issue of "what test issue is SAMPLE trying to solve?" and pursuant thereto to suggest changes necessary to resolve the conflict between rules 7.6.1.d and 10.6.1.g.
Error/Event Subcommittee:
(Dilip Bhavsar, CJ Clark, Najmi Jarwala, Colin Maunder, Rod Tulloss, Lee
Whetsel)
Interpretation Response Subcommittee:
(Colin Maunder, Ken Parker, Gordon Robinson, Rod Tulloss, Lee Whetsel, and Tom
Williams)
Pin Buffer/Driver Subcommittee:
(Grady Giles, Adam Ley, Colin Maunder, Ken Parker, Gordon Robinson, Rod
Tulloss, Lee Whetsel)
RUNBIST-like Subcommittee
(Colin Maunder, Michel Parot, Rod Tulloss, Lee Whetsel)
WG Chair, Gordon Robinson:
WG Vice-Chair, Math Muris:
WG Vice-Chair, Adam Ley:
Std Technical Editor (Adam Ley):
Dilip Bhavsar:
Najmi Jarwala:
Colin Maunder:
Lee Whetsel: