Minutes of Weekly Meeting, 2013-06-03

Meeting called to order: 11:05 AM EDT

1. Roll Call

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

Patrick Au

2. Review and approve previous minutes:


  • No corrections noted.
  • Eric moved to approve, seconded by Carl. 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.
  • Ian/All: Look for real world examples of boards that we could take through from board test to a system test implementation as a worked example case. Ongoing.

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. Discussion of System Examples slides
    • Ian had circulated some slides in advance of the meeting and there had already been some email exchange with regard to those slide.
    • {System Examples slide set shared}
    • Ian commented that slide 2 had been used in the 2008 ITC material. It was a development of an earlier SJTAG view where XBST and EBST were implied to be two distinct forms. This slide attempted to show that there was valid ground between the two extremes. Brad added that in his protocol, which was presented at the same time, the interfaces between layers in the stack were structured so that they could move down to accomodate the transition into the embedded case. Harrison saw that there was no difference in the interfaces; the differentiator were what you were trying to observe or control and that as you moved towards the right there was a greater dependency on the end environment. Brad noted that the 'application level' provides the context, although Harrison argued that JTAG, as currently used, does not know or care about the application.
    • Brad described a hybrid solution used to address an EST problem. Harrison suggested that was a reaction to a constraint in the original design. For something like equipment on a single seat aircraft, Ian was of the opinion that detailed diagnostics in flight were of limited value and that simpler go/nogo on major capabilities were what the pilot needed to know. Since this could probably be obtained by high level functions without any recourse to JTAG, that was why Ian suggested in his email that there could be a challenge for SJTAG here. Detailed diagnostics would typically be obtained offline and JTAG may well be appropriate there. Harrison felt that line of thought extended to non-DOD sectors and suggested the financial sector's server farms as an example.
    • Brad felt that economics was a factor that had not yet been adequately addressed: It was possible that, depending on volumes, investing in an embedded test solution could mitigate against a capital investment in external test equipment, especially given the increased power available in many UUTs. Ian agreed and commented that a radar processor may contain upward of 24 Power PC cores.
    • Brad remarked that VMs as commonly used in server farms presented a problem as it was often difficult to determine which VMs were running on which hardware instance making it difficult to seamlessly switch out the VMs in order to investigate faults. Harrison claimed this was another case of limitation on observability, and you need to increase observability in order to take action. Observability is sacrificed as you move from left to right on slide 2, although Brad argued that getting pin and net diagnostics was perfectly possible in the right hand case. Harrison agreed but noted that it required some investment to make that possible.
    • Peter considered that there was a need to cater for all cases, from the very simple units through to the high end products with embedded diagnostics as some designs will not be able to carry the cost of embedding a Test Manager. Peter also noted that the SJTAG demo that Firecron did with Asset could retrieve diagnostics from the embedded test system and relay those results back into the originating tooling. Brad agreed, adding that he'd seen some applications where PowerQUICC cores were used as there reluctance to add dedicated hardware. Peter went further, noting that sometimes even the software people don't test software added into their stack. His main point was that he did not believe there was a 'one size fits all' solution for SJTAG. Brad accepted tha there was no standardization for the Test Manager, and at best we had an abstraction of one.
    • Ian suspected that Tim's usage was likely to be more like the left hand/XBST case. Tim confirmed and said that they'd likely get boards returned to the engineering area after a board swap in the field for diagnostics, or the whole equipment may be returned. Ian added that was the typical model used in his company too, but recognized that swapping a board in the field may mean that you lose the environmental context of the failure, leading to possible No Fault Found on factory retest.
    • Ian quickly ran through the other slides in the pack to give a brief description prior to the next meeting and address some of the questions that Adam had raised in his email response. Brad invited a further comment from Ian with regard to Adam note regarding slide 5. Ian agreed that the connection from the master uP could have gone via the gateway (now bidirectional) instead of directly to the multidrop bus. However, Ian had chosen to illustrate it this way in an attempt to show where the flow of control was; this may not have been as obvious has it been shown as going through the gateway. Peter added that Firecron parts typically worked bidirectionally between the multidrop and the devices on the UUT. Brad noted that lot was dependant on the capabilities of the tooling that was available. In some cases going through a bidirectional gateway may mean that the way a board test itself differs from how it is tested by another controller, and that may be undesirable. In that case connecting directly to the multidrop may be preferable.

6. Key Takeaway for today's meeting

  1. The progression from XBST towards a full EBST is really polymorphic.
  2. The level of intelligence inherent in the UUT is a factor in how far towards EBST you can go.
  3. There is a need to cater for all complexities of system, from a simple system through to a complete embedded diagnostic capability. Cost burden and volume will be factors.
  4. Adopting EBST may be a trade off against capital cost of test facilities.

7. Schedule next meeting

Next Meeting:
June 10. Adam anticipates missing this meeting.

June schedule:
10, 17, 24

8. Any other business

Bill Eklow has informed Carl that he will contact Ian soon.

9. Review new action items


10. Adjourn

Brad moved to adjourn at 12:03 PM EDT, seconded by Brian.

Respectfully submitted,
Ian McIntosh