Minutes of Weekly Meeting, 2016-07-06

Meeting called to order: 11:10 AM EDT

1. Roll Call

Ian McIntosh
Brian Erickson
Eric Cormack
Carl Walker
Brad Van Treuren
Bill Eklow
Heiko Ehrenberg (joined 11:21)
Adam Ley (joined 11:30)

By Proxy:
---

Excused:
Peter Horwood

2. Review and approve previous minutes:

  • Approval of June 29 minutes (draft circulated 06/29/2016).
    • No corrections noted.
    • Brad moved to approve, seconded by Eric. No objections or abstentions.

3. Review old action items

  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? See also Gunnar's presentation, in particular the new information he'd be looking for in a test language (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Ian: Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.
  • All: Review blue text on Slide 18. Comments to be posted to the forums (http://forums.sjtag.org/viewtopic.php?p=1154#p1154). CANCELLED (for this week).

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172
  • The Newsletter was due at the end of July 2015.

5. Discussion Topics

a. Continue PAR discussion
- Distil concise paragraph for formal Need clause in PAR
.

  • {Brad shared slide 18}
  • Looking at the last update to the Need statement, Ian was happy with all but the final sentence, which Brad agreed was really just a placeholder. It did not seem to provide enough explanation of the case.
  • Brad created a copy on Slide 19 for editing.
  • {Brad shared slide 19}
  • The text was expanded to better reflect Adam's description from the previous meeting. Adam agreed with the edits.
  • Ian noted that the PAR version of the need was to satisfy the Sponsor and NESCOM rather than to provide a technical justification. Brad added that it should also relate to the given Scope and Purpose.
  • {Brad shared slide 20}
  • Brad started to collect bullet points from the Scope (Slide 4) to Slide 20.
  • Bill asked for an explanation of "architectural philosophy". Brad explained it was about the differences between Access Links and Data Links. There was more than covered in 1149.1 or 1687. Bill acknowledged that Michele was suggesting that some things in 1687.1 should be SJTAG. Brad agreed that there were some "domain aspects" that 1687.1 wouldn't cover as it is concerned only from the pin edge inwards. It needs to describe what is available at the pin interface. Bill accepted that SJTAG is operating at a "higher level" than 1687.
  • Bill suggested simplifying some wording in the Scope, arguing that fewer words tended to leave less room for problems to be created. Brad made these amendments in a copy on Slide 21.
  • {Brad shared slide 21}
  • Brad was concerned that the Scope should differentiate itself from the existing standards, but Bill felt that was adequately covered by the remaining text as it comes in the references to sub-system and system.
  • Bill sought Adam's views on the revised wording. Adam was content, although he noted that some might see it as overly broad but it would be subject to review and revision by people outside of this group anyway.
  • The Purpose would also need similar re-review and Brad made a copy on Slide 22 but this was not used as time was running out.
  • Need (Slide 19) as agreed:
    • 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.
  • Scope (Slide 21) as edited:
    • SCOPE: This standard defines enabling methods to allow, in conjunction with existing methods, for the coordination and control of one or more (possibly different) device, board, and sub-system test interfaces to extend access to the system level. It also defines the architectural philosophy and description of such a system to allow better management of the test interfaces that exist when used at the system level.
  • For next week:
    • Especially for those not on the call, review and comment on the revised scope on Slide 21 {ACTION}.
    • Post comments to the forum thread(http://forums.sjtag.org/viewtopic.php?p=1155#p1155).
    • Re-read the Purpose in preparation for next meeting {ACTION}.
  • The revised slide pack has been added to the file manager: http://files.sjtag.org/Brad/SCOPE%20DRAFT20160706.pptx.

6. Topic for next meeting

  • Continue PAR discussion
    • Review "Purpose" statement.
    • Distil concise paragraph for formal Need clause in PAR.

7. Key Takeaway for today's meeting

  • Using fewer words in the PAR is likely to create fewer problems.

8. Glossary terms from this meeting

  • None.
    • Definition of "interchangeability" required.
    • 'Instance' (or a more specific version of the term) may require definition in future.
    • 'Master through Slave Mode'
    • 'Master to Master Mode'

9. Schedule next meeting

  • Next meeting July 13
  • July schedule:
    • 20, 27.

10. Any other business

  • Bill advised that IEEE has given approval for BTW this year and it would be good to have an SJTAG element. Anyone interested should contact Bill.
  • Ian hopes Michele will be able to provide a fuller report on the TESTA tutorial in due course.

11. Review new action items

  • All (those not on the call today): Confirm that you are satisfied with the updated Scope. Comments to be posted to the forums (http://forums.sjtag.org/viewtopic.php?p=1155#p1155). (Updates action set 6/29/2016)
  • All: Re-familiarise with Purpose prior to next meeting.

12. Adjourn

  • Eric moved to adjourn, seconded by Brad.
  • Meeting adjourned at 12:01 PM EDT

Respectfully submitted,
Ian McIntosh