Minutes of Weekly Meeting, 2013-02-18

Meeting called to order: 11:05 AM EST

1. Roll Call

Ian McIntosh
Carl Walker
Patrick Au
Adam Ley
Eric Cormack
Peter Horwood
Heiko Ehrenberg
Brian Erickson
Brad Van Treuren
Tim Pender (joined 11:10)

Harrison Miles

2. Review and approve previous minutes:


  • One correction noted:
    Change 'Device Versioning' to 'Environmental Stress Test' in the phrase: '...questioned the dash for Device Versioning in both Field Service and Workshop Repair...'
  • Brad moved to approve with the above amendment, 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
  • Harrison will attempt to come up with a table of use cases and their associated layer and what can be done at that layer. Ongoing.
  • Harrison: Send summary of iNEMI BIST Work Program to Ian and Brad. COMPLETE
  • Ian to update slide #9. COMPLETE

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

5. Discussion Topics

  1. Proposals for SJTAG at ITC or BTW 2013 (if any update available).
    • No discussion.
  2. What did we learn from the discussion of lifecycle phases and Use Cases?
    • Ian had circulated updated slides by email prior to the meeting.
    • {Slides shared}
    • Slide 9:
    • It was agreed this reflected the conclusions from the previous meeting.
    • Ian wished to add to the previous weeks discussion, by explaining his reasons for applying the '?' in Manufacturing for EST: There was a question of whether EST was conducted at board level or system level. Both are possible, although each approach can give rise to logistical problems, but if conducted only at board level, then does it fall under SJTAG? Brad noted that we had not spent much time defining where the boundary for SJTAG lay; There were systems and subsystems but perhaps the delineation lay at the FRU.
    • Ian felt it may an oversimplification to say that everything at the board level was 'JTAG' rather than 'SJTAG', as there could be boards that carried daughter boards. Brad agreed, noting that what had once been chassis had become boards and were becoming daughter boards and this was being taken further by 3D SOCs, so the distinction between board and system was not clear.
    • Heiko thought it may be enough to consider that the systems comprises FRUs and that was the boundary. He and Brad agreed that this placed the responsibility to define the testable items with the system designer, rather than being defined by the standard. Ian thought this seemed fair, but it left this group with the difficulty of describing that in a way that allowed us to easily identify what was inside or outside of our scope.
    • Brad observed that board level constructs that were required for use at board test would also be required for system level test, so how do you mandate the board level requirement to support system level test? 1149.1 is the only definition we have at board level and that only specifies the interface and the protocol. P1687 defines a hardware architecture and a protocol and Brad wondered if that was a better approach.
    • Ian felt that the overall test strategy needed to reflect a top-down flow to ensure that the system level objective are met, but there may be opportunity to exploit board features that weren't initially anticipated. Brad thought that if the hardware designers incorporated the required hardware, then the software can deal with the extra features later.
    • {Heiko dropped off the call for a few minutes}
    • Ian wondered if the discussions on the other Use Cases may have been slanted by board level considerations. Brad thought this was likely, most notably for POST, where boundary scan test is only a piece of POST. Brad was reminded of a presentation by CJ Clark (possibly 2003) describing parallel self-test on like boards. The main reason many people add resources to each board is to get such concurrency. Gunnar's point here was that boards require some level of management to constrain power consumption.
    • Brad considered that things had therefore evolved beyond the requirements that Dot5 had. Brad suggested it might be possible agree a Dot0 that defined the messages passed between the board management controller and the shelf controller. Ian wondered about the case where there is no specific shelf controller and each board is essentially autonomous. Brad thought that introduced the idea of a 'motherboard' rather than a 'shelf controller'. Brad asked if this was in alignment with the experiences of Carl and Tim, as the other 'system builders' on the call. Tim felt the scenario described was somewhat removed from the designs he worked with. While they were more like the motherboard (or 'pizza box') arrangement, there may be only two BScan equipped boards out of ten in the system, and most testing is done through firmware, with embedded diagnostics via USB and BScan is mainly for manufacturing test.
    • Carl had products that spanned the full range from architectures similar to those Brad worked with to smaller systems more like the 'pizza box'. Carl agreed that there was a need to observe management of power through some level of intelligence but he had limited experience of some of the 'Green' technologies that Brad referred to.
    • Ian commented on related but slightly different aspect: An aircraft running from a Ground Power Unit will often be restricted on power consumption compared to when the engines are running and full generator power is available. This can restrict what can be powered up for test or alter the sequence of testing. In effect there is a dependency on the environment. Additionally, Ian noted that it was often necessary to restrict the number of simultaneously switched IO on each BScan vector as the current demand during BScan testing could exceed that during functional operation, and lead to ground bounce issues or collapsing rails. Brad agreed that in his experience the power consumption during test was usually greater than in functional mode.
    • Brad asked if Ian's design always had some form of power management on the board. Ian acknowledged that they did but it may be a relatively dumb sequence and monitor. Brad noted that many systems needed some form of management to ensure sanity during power up and avoid a massive surge on switch on. Ian noted that some boards employ a discrete signal that tells the module it's OK to power up. Brad noted that ATCA took that forward by defining messages to used to perform that function.
    • Tim commented that some designs would use a small microcontroller to manage not just the power up sequence but also the resets. Further, some devices may require that compliance pins are set for the BSCan tests, so these would also need to be managed. Ian added that this introduced the need for some persistent memory that will survive resets to keep track of what the next stage should be. Brad pointed out this was particularly the case for POST.

6. Key Takeaway for today's meeting

  1. Board level testing needs to be coordinated with the board management controller:
    - More than just applying vectors.
    - Power functionality, Reset functionality and Compliance capability are requirements to the ability to apply vectors.

7. Schedule next meeting

Next Meeting:
25 - Heiko will miss.

March schedule:
11 - Patrick will miss.
18 - Patrick will miss.

8. Any other business


9. Review new action items


10. Adjourn

Eric moved to adjourn at 12:04 PM EST, seconded by Peter.

Respectfully submitted,
Ian McIntosh