PAR scope and direction

Discuss the generic proposals for SJTAG
User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed May 18, 2016 4:19 pm

Here is the latest version of the Purpose we settled on in the meeting after reviewing Ian's forum comments (Slide 7 of new draft):

PURPOSE: A standardized method is needed to coordinate component access topologies, interface constraints, and other dependencies at the board and system level in order to be able to effectively leverage the existing and future component level standards. Thus, a new supervisory standard is required to define the coordination and dependencies of instruments as well as configuration, management, and application of vector based testing at the board and system levels. IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but fail to provide the contextual prerequisites for the dependence on each instrument configuration and/or aggregation of multiple instruments for the overall board and/or system maintenance operations. Further, many components only support non-JTAG interfaces (e.g., I2C or SPI) to their instrumentation registers.

We worked on the NEEDS section some more and posted the following text for review (Slide 9 of new draft):

NEED: As signals get faster on boards, there is a need to use alternate test techniques from the traditional continuity testing that was originally supported by IEEE 1149.1. These techniques, and others, requires special instrumentation to be implemented in the source and destination components wired together. There is a need to coordinate the configuration of components, selection of access paths (scan paths?), and configuration of instrumentation access to perform the required test and maintenance operation. For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component and mapping of instruments to pins under test.

There are 2 questions that need to be discussed that need some text added to the need. Please try to address these questions on the forum before next meeting.
1. Are we sufficiently addressing the issue of "Access to the target" in the NEEDS?
2. How are we to deal with the issue of "Multiple Host Selection?" For example, BSCAN can be hosted by an on-board controller, system-level controller, and external tester; all targeting the same design circuit.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 418
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK
Contact:

Re: PAR scope and direction

Post by Ian McIntosh » Wed May 25, 2016 2:49 pm

Bradford Van Treuren wrote:NEED: As signals get faster on boards, there is a need to use alternate test techniques from the traditional continuity testing that was originally supported by IEEE 1149.1. These techniques, and others, requires special instrumentation to be implemented in the source and destination components wired together. There is a need to coordinate the configuration of components, selection of access paths (scan paths?), and configuration of instrumentation access to perform the required test and maintenance operation. For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component and mapping of instruments to pins under test.

There are 2 questions that need to be discussed that need some text added to the need. Please try to address these questions on the forum before next meeting.
1. Are we sufficiently addressing the issue of "Access to the target" in the NEEDS?
2. How are we to deal with the issue of "Multiple Host Selection?" For example, BSCAN can be hosted by an on-board controller, system-level controller, and external tester; all targeting the same design circuit.
"These techniques, and others, requires special instrumentation to be implemented..." - I think we need to make sure we don't imply that providing the instrumentation is part of our standard.
What really is the need? Is it to provide a description of the constructs such that it simplifies the job of the tooling?
Maybe we should be turning this round and be thinking about the accesses and hosts first (as mentioned in Brad's comments) and then see where that leaves us?
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed May 25, 2016 4:11 pm

Here is the NEED text drafted during today's meeting.

NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. There is also a need to configure the topology of the access mechanisms from one or more hosts, which must be described from the perspective of the tooling driving the applications. These techniques, and others, requires special instrumentation to be implemented in the source and destination components wired together. For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component connected to the source and mapping of instruments to pins under test.

Please consider the following item and respond in the forum before next meeting so we can complete the NEEDS section of the PAR during next week's meeting:
Need to deal with difference between configuration of topology and configuration of instruments needing to be coordinated in operation (Need this explained before we can introduce examples)
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 418
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK
Contact:

Re: PAR scope and direction

Post by Ian McIntosh » Wed Jun 01, 2016 2:18 pm

There is also a need to configure the topology of the access mechanisms from one or more hosts, which must be described from the perspective of the tooling driving the applications.
I'm wondering if that needs to say "from one or more hosts to the target(s)", or is that unnecessary expansion?

The red text from the previous post is an easy concept but hard to put into words! How about:
"There is a further need to ensure that any pre or post-configuration of instruments/registers occurs in a timely manner in order to facilitate the operation in hand."
Probably a bit clunky?
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed Jun 01, 2016 4:03 pm

The text discussed in the 1 June 2016 meeting is below:

NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. First, any differences in the access link protocols need to be managed and described to act as a single interface form for the host tooling. Second, there is a need to configure the topology of the access mechanisms from one or more hosts to one or more targets, which must be described from the perspective of the tooling driving the applications. Third, the host needs to ensure that any pre or post-configuration of instruments/registers occurs in a timely and coordinated manner in order to facilitate the operation in hand. (Interconnect Example First) For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component connected to the source and mapping of instruments to pins under test.

Please consider the wording for the Interconnect Test Example and the working of the sentence in RED.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 418
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK
Contact:

Re: PAR scope and direction

Post by Ian McIntosh » Mon Jun 06, 2016 7:08 pm

I'm happy enough with the first red sentence (including the green addition).

The Interconnect example is more awkward. I think any example we use has to be sufficiently different from any "conventional" board level interconnect test, including anything that spans different chains on the same board, otherwise there's no obvious value add compared to what can be covered by existing tooling. So that suggests that we need to span boards. On the other hand, maybe we need to span protocols instead - show some of the bridging and why that makes timing (co-ordination) essential.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed Jun 08, 2016 4:12 pm

Below is what was settled on so far for the NEED section from today's call:

NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. First, any differences in the access link protocols need to be managed and described to act as a single, common, abstracted interface for the host tooling. Second, there is a need to configure the topology of the access mechanisms from one or more hosts to one or more targets, which must be described from the perspective of the tooling driving the applications. Third, the host needs to ensure that any pre or post-configuration of instruments/registers occurs in a timely and coordinated manner in order to facilitate the operation at hand. (See slide 13 for suggested sentences) For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component connected to the source and mapping of instruments to pins under test.

For homework, we are all to look at the content of slide 13 (see below) to flesh out the missing examples for the NEED section.
Content of slide 13:
  • Traditional board interconnect test relies on precomputed vectors that are applied consistently for each board design. However, when applied in a system, the test needs to be associated with an instance of a board (one of many) with a slot ID or unique identifier. More importantly, a board may require a different set of constraints at the board edge based on which slot the board is plugged into or what is mated to it in adjoining slots.
  • Example 1 Traditional board interconnect test (precomputed ATPG vectors).
  • Example 2 Backplane interconnect test.
  • Not fully composed system where population may vary and new constraints may be imposed on previously known entities.
  • Board stand-alone test is different than board in-system test.
  • Board stand-alone may allow for applying external instrumentation that is impossible when in-system.
  • When buying a COTS board, how can we include it in the system with test.
  • For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component connected to the source and mapping of instruments to pins under test.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 418
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK
Contact:

Re: PAR scope and direction

Post by Ian McIntosh » Tue Jun 14, 2016 1:35 pm

What we've got in the top blue bullet seems to be a conjunction of Example 1 and Example 2, so maybe I've forgotten exactly what we thought we were saying at the end of last week's call, but I'm a bit confused about what we want now.
I understood that we wanted Example 1, Example 2 and the existing Instrument case as distinct cases. Was that first bullet WIP before we identified Example1 and Example 2 as distinct? I'll assume so, for now.
  • Traditional board interconnect test relies on precomputed vectors that are invariant and applied consistently to any given board design. It is possible to similarly precompute test vectors for a board within a system but the test must either discount board edge conditions or assume a single, fixed system configuration.
    (This seems to address the topic of Example 1 but doesn't show any "co-ordination"?)
  • For a portable test, that test needs to be adaptable such that it may be associated with a specific instance of a board (one of many) with a slot ID or unique identifier and more importantly, the test may employ a different set of constraints at the board edge based on which slot the board is plugged into or what other boards may be interfaced with it.
    (I'm not sure this really covers Example 2 - it feels like it doesn't address the question "Is the board properly installed?")
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Tue Jun 14, 2016 3:16 pm

I believe the thought process was as follows:
  • Traditional board interconnect test relies on precomputed vectors that are applied consistently for each board design. However, when applied in a system, the test needs to be associated with an instance of a board (one of many) with a slot ID or unique identifier. More importantly, a board may require a different set of constraints at the board edge based on which slot the board is plugged into or what is mated to it in adjoining slots.
was trying to address the following bullet items as an attempt to consolidate these bullets into a single sentence:
  • Example 1 Traditional board interconnect test (precomputed ATPG vectors).
  • Not fully composed system where population may vary and new constraints may be imposed on previously known entities.
  • Board stand-alone test is different than board in-system test.
Example 2 was thought to be yet another case. In the first bullet, the emphasis is on whether there is a possible reuse (or salvage) of a traditional board test developed for manufacturing test of the board in a standalone environment that could be used at the system level. The bullet points out that there are many more factors involved at the system level testing that don't exist when testing a board in a standalone test environment.

I feel Example 2 is going to need to discuss the use of precomputed vectors that are targeted specifically at the backplane connections and not for other circuits that reside on the board. There are a set of patterns that act as stimulus to the backplane to provide unique discrimination between failure conditions and there will be a single safe vector that is used to only observe the interface pins or be configured with specific constraint drivers that must persist over the life of the test. These are very different variables from what is required for Example 1. Example 2 is also not attempting to test a single unit in the system, but instead it attempting to test the interface of each unit at the next higher module level (the backplane interconnection). They each have their own unique set of criteria.

I think that both Example 1 and Example 2 are quite relevant for COTS board testing in the system. We are beginning to identify a standardized set of constraints that must be applied to board level tests if these boards are to be tested within a system. That means the local board chain topology and the choice of interface components may require modular separation and required 1149.1 test access for any signal emanating from the board as well as be observable for any signal entering the board. To reduce the vector size for that board, ideally, the devices mating to the backplane should be in a separate scan path to reduce the size of the scan chain to its minimum size. These are all decisions that have to be made at the architectural level of the product and cannot be thought of as an add-on to a design after the design is complete. Understanding these issues and explicitly providing a checklist for what to plan for is quite a huge value add that SJTAG can bring to the community.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 418
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK
Contact:

Re: PAR scope and direction

Post by Ian McIntosh » Tue Jun 14, 2016 6:34 pm

Brad wrote:I feel Example 2 is going to need to discuss the use of precomputed vectors that are targeted specifically at the backplane connections and not for other circuits that reside on the board.
That's just what I felt was missing in making my comment above - it could be implied but is not expressly brought out.

{Edited}
Anyway, am I right to summarise the aims as follows?:
Example 1 - The interconnect test of the circuits within a given board when installed in a system and subject to external constraints.
- We are concerned with the board edge conditions only in so far as they limit what tests are possible.
Example 2 - Verification of the interconnects between boards installed in a system.
- We are not interested in the internal circuitry of any particular board other than how it may be used to condition, drive or sense the board edges.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed Jun 15, 2016 4:14 pm

The latest version of the NEEDS section is shown below:
NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. First, any differences in the access link protocols need to be managed and described to act as a single, common, abstracted interface for the host tooling. Second, there is a need to configure the topology of the access mechanisms from one or more hosts to one or more targets, which must be described from the perspective of the tooling driving the applications. Third, the host needs to ensure that any pre or post-configuration of instruments/registers occurs in a timely and coordinated manner in order to facilitate the operation at hand. Traditional board interconnect test, targeting circuits within a given board, relies on pre-computed vectors that are applied consistently for each board design. However, when applied in a system, the test (a test version) needs to be associated with an instance of a board, which may be one of several boards, with a slot ID or other unique identifier. More importantly, a board may require a different set of constraints at the board edge, which are influenced by factors such as the slot the board is plugged into, what is mated in adjoining slots, or a change of the system configuration. A management layer needs to select which test version is to be applied to each instance in a system for the current configuration. (See slide 14 for suggested sentences) For example, there is a need to coordinate the configuration of component ports and instrumentation to allow for a loop-back configuration in the destination component connected to the source and mapping of instruments to pins under test.

Slide 14 contents that are referred to are:
  • Example 2 Backplane interconnect test.
  • Board stand-alone may allow for applying external instrumentation that is impossible when in-system.
  • When buying a COTS board, how can we include it in the system with test.
  • Anyway, am I right to summarise the aims as follows?:
    • Example 2 - Verification of the interconnects between boards installed in a system.- We are not interested in the internal circuitry of any particular board other than how it may be used to condition, drive or sense the board edges.
As homework for next time, please look at fleshing out Example 2.
I am also looking at the last sentence we added
A management layer needs to select which test version is to be applied to each instance in a system for the current configuration.
which I feel needs to be modified to emphasize how SJTAG is providing the access to each board instance based on the configuration specification. This does not seem to be clear to me with the current text and seems to imply that SJTAG is going to define how the tooling is going to describe such a topology and model of the entire system netlist to generate such test versions. I feel that is outside of the SJTAG scope, but it is a related topic that may need to be addressed by a sibling standard.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 418
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK
Contact:

Re: PAR scope and direction

Post by Ian McIntosh » Wed Jun 22, 2016 10:26 am

Regarding Example 2, I think I'll start off by just trying to list (some of) the things we might need to highlight:
  • Consider board edges, not their internals.
  • Slot dependency.
  • Signals that are constrained or unknown (don't care) due to being in a system (generic).
  • Signals that are constrained or unknown due to other boards in the system (specific, variable).
  • Knowledge of operational state of the system - not just what's connected, but what is on/off, active/inactive.
A lot of the above could be rolled up under the heading of "physical configuration", but it seems that how far you want to go with these will depend on how comprehensive a test you want: That could be anything from a fairly cursory test that is essentially pre-computed and only adapted to account for changes in geographical address and ignores any I/O that cannot be easily assured through to something comprehensive that dynamically adapts to all changes in the installation environment. Are we prescribing how far you need to go?

I'll leave Brad's question on the "management layer" for the meeting to discuss.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed Jun 22, 2016 4:20 pm

Here is the contents of slide 16 that we discussed today regarding Example 2.
  • On the other hand, interconnect test between boards, targeting circuits connected by a backplane and/or cables, may require that any pre-computed vectors are adapted based on the physical configuration of the system or that the vectors are generated dynamically. Significantly, a board may need to sense or drive a different set of values at its edge depending on the system population, influenced by the same factors from above, but with an alternative perspective. A management layer is also needed to select how vectors are to be applied to each instance in a system for the current configuration.
  • Knowledge of operational state of the system - not just what's connected, but what is on/off, active/inactive.
Have a go at revisions of the blue text and whether the red text needs to be incorporated in the first paragraph. Any suggestions are welcome. We are still brainstorming.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed Jun 29, 2016 4:05 pm

In today's meeting we fleshed out the remainder of the NEEDS paragraph. Here is what we have so far:

NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. First, any differences in the access link protocols need to be managed and described to act as a single, common, abstracted interface for the host tooling. Second, there is a need to configure the topology of the access mechanisms from one or more hosts to one or more targets, which must be described from the perspective of the tooling driving the applications. Third, the host needs to ensure that any pre or post-configuration of instruments/registers occurs in a timely and coordinated manner in order to facilitate the operation at hand. Traditional board interconnect test, targeting circuits within a given board, relies on pre-computed vectors that are applied consistently for each board design. However, when applied in a system, the test (a test version) needs to be associated with an instance of a board, which may be one of several boards, with a slot ID or other unique identifier. More importantly, a board may require a different set of constraints at the board edge, which are influenced by factors such as the slot the board is plugged into, what is mated in adjoining slots, or a change of the system configuration. A management layer needs to select which test version is to be applied to each instance in a system for the current configuration. On the other hand, interconnect test between boards, targeting circuits connected by a backplane and/or cables, may require that any pre-computed vectors are adapted based on the physical configuration of the system or that the vectors are generated dynamically. Significantly, a board may need to sense or drive a different set of values at its edge depending on the system population, influenced by the same factors from above, but with an alternative perspective. A management layer is again needed, to have knowledge of the operational states of the entities in the system, how to select the vectors that are to be applied to each such entity, and how these vectors are applied for the current configuration. As a further example, one that involves embedded instrumentation, there is a need for a management layer to coordinate the configuration of component ports and instrumentation, as well as mapping of instruments to the physical pins under test, perhaps to allow for a loop-back configuration (Master through Slave Mode) in the destination component connected to the source or to support Master to Master Mode connections (e.g. , Tx1 to Rx2, Tx2 to Rx1).


Please review the text in blue and comment any further updates that may be required. Post your discussion on this forum site in response to my post. Thanks. Next time we will begin to distil the information we need for an abbreviated NEEDS paragraph that will be placed into the PAR.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 103
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed Jul 06, 2016 4:10 pm

The expanded NEED statement as our baseline from today's meeting is:

NEED: A growing number of test and maintenance applications are needing to access IEEE 1149.1 compliant components and there is not a way to give these applications uniform access to the targets at the board and system levels. Current standards are only dealing with the interfaces inside of a component. Further, components may use alternate interfaces (e.g., I2C, SPI) to provide access to the test features. Consequently, special consideration must be given to the communications between the host and the target. First, any differences in the access link protocols need to be managed and described to act as a single, common, abstracted interface for the host tooling. Second, there is a need to configure the topology of the access mechanisms from one or more hosts to one or more targets, which must be described from the perspective of the tooling driving the applications. Third, the host needs to ensure that any pre or post-configuration of instruments/registers occurs in a timely and coordinated manner in order to facilitate the operation at hand. Traditional board interconnect test, targeting circuits within a given board, relies on pre-computed vectors that are applied consistently for each board design. However, when applied in a system, the test (a test version) needs to be associated with an instance of a board, which may be one of several boards, with a slot ID or other unique identifier. More importantly, a board may require a different set of constraints at the board edge, which are influenced by factors such as the slot the board is plugged into, what is mated in adjoining slots, or a change of the system configuration. A management layer needs to select which test version is to be applied to each instance in a system for the current configuration. On the other hand, interconnect test between boards, targeting circuits connected by a backplane and/or cables, may require that any pre-computed vectors are adapted based on the physical configuration of the system or that the vectors are generated dynamically. Significantly, a board may need to sense or drive a different set of values at its edge depending on the system population, influenced by the same factors from above, but with an alternative perspective. A management layer is again needed, to have knowledge of the operational states of the entities in the system, how to select the vectors that are to be applied to each such entity, and how these vectors are applied for the current configuration. As a further example, one that involves embedded instrumentation, there is a need for a management layer to coordinate the configuration of component ports and instrumentation, as well as mapping of instruments to the physical pins under test, perhaps to allow for a loop-back configuration (Master through Slave Mode) in the destination component connected to the source or to support Master to Master Mode connections, where a Tx instrument residing in one device communicates with the Rx instrument residing in another device and vice versa, thus a coordination of these instruments is required from a management layer.

The last example has been clarified and expanded to fulfill our action items from last meeting. We began to revisit the SCOPE and have provided the following update of the SCOPE statement:

SCOPE: This standard defines methods to allow, in conjunction with existing methods, for the coordination and control of device, board, and sub-system test interfaces to extend access to the system level. It also defines the description of such a system to allow better management of the test interfaces that exist when used at the system level.

If you were not on the call today, please look over the latest SCOPE and comment whether the changes create a problem for you. The homework for this week is to review the current PURPOSE statement to identify if there are any revisions that may be able to simplify the statement without losing the understanding and context.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

Post Reply