Minutes of Weekly Meeting, 2013-02-25

Meeting called to order: 11:05 AM EST

1. Roll Call

Ian McIntosh
Peter Horwood
Harrison Miles
Brad Van Treuren
Adam Ley
Carl Walker (joined 11:07)
Tim Pender (joined 11:11)
Eric Cormack (joined 11:15)

Excused:
Heiko Ehrenberg
Patrick Au

2. Review and approve previous minutes:

2/18/2013:

  • No corrections advised:
  • Insufficient members on the call for approval.

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)
  • 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

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).
    • Ian had emailed Bill Eklow to enquire about BTW arrangements for 2013, but had yet to receive a reply.
    • {Bill's reply arrived during the meeting}
    • BTW will probably be in October this year since ITC is in September. It is unlikely that Fort Collins will be the venue as BTW cannot get access to Intel's Conference Rooms. Bill will be sending out an email shortly with further details.
  2. What did we learn from the discussion of lifecycle phases and Use Cases?
    • Ian summarized how the discussion of the past few weeks had brought us to point where last week we questioned where the boundary lay between 'SJTAG' (relating to the system) and 'JTAG' (relating to boards and devices). Ian had hoped that we could make further progress on defining 'primitives' from this work. Brad noted that the discussion of primitives had got to the level of gateways before we became unsure of how to proceed. Last week's discussion ended by asking if there was a gain from setting multidrops aside and considering a software protocol for Dot0 and requiring a board management controller.
    • Harrison considered primitives as atomic and unaware of system function. It becomes SJTAG when there is a collection of primitives with some kind of manager that assembles a picture. The 'system' may be another picture. Ian was wary about terminology and noted that there could be hardware primitives and software primitives and it could be confusing if we're not clear which we mean. Brad commented that 1149.1-2013 starts to consider this by introducing structural and behavioural aspects.
    • Harrison observed that a system was typically targeted towards a particular application but primitives are not necessarily doing that. System function requires hardware, firmware and software to be good but you tend to have poor observability of hardware and firmware at system level.
    • Ian noted that his applications will typically apply JTAG only in 'offline' conditions, and that for the types of application that Brad often describes there needs to be awareness of system states. Brad thought that a standard could address the situation Ian described but still accomodate the more dynamic cases too.
    • Ian wondered if the discussion here about shelf managers might parallel the discussion from some time previously where it was noted that JTAG did exist by itself and always needed to be under the control of some higher level process.
    • Harrison noted that what was done before POST was probably 'JTAG' while what was done after POST was more slanted towards supporting the application and was probably more reliant on the features of the newer standards. JTAG was meant to solve problems before POST.
    • Brad agreed that after an interconnect test it was traditionally necessary to reboot the boards as they were not in any predictable state, although again this is addressed in 1149.1-2013.
    • Peter felt that what Brad had been trying to describe was where a blade may be a self-contained unit that can perform it's own self-test and may be like the 'pizza box' and have a number of plugins or it could be a stand alone design. Brad agreed and noted this was especially the case of a µTCA blade evolving into a chassis leading to a cascading hierarchy. Tim's system boxes, where the motherboard runs everything and may test selected plugins, is somewhat similar to ATCA with mezzanines. But the ATCA boards plugged into a chassis have a higher level entity coordinating them.
    • Harrison commented on a Corelis product that can take over control of a processor (Intel, for example) and do a lot of things through that but once the Southbridge starts to bring up the Flash it becomes harder to stay in JTAG as it becomes necessary to reflect more of the environment that supports the application. It is no longer in 'Test Mode' but 'Pre- application Support Mode'. Brad wondered if the assumption was that the processor was in control of the JTAG; Harrison noted that in the case on a multiprocessor board another processor could be in charge. Indeed, much of the time, a given processor might not know which processor was in control. Ian noted that this was his thought from earlier; that there is is some global process that has overall control of when JTAG is applied. It could decide whether it is appropriate to perform an action via JTAG or some alternative method depending on its observation of the system state.
    • Brad understood Ian's point, noting that from a blade's perspective it was 'external control' whether from a shelf controller or replication of those functions within test equipment. Ian remarked that he was simply wondering if the distinction between a shelf controller and a control process over an external Test Manager was an unnecessary complication and as an abstraction they might be equivalent.
    • Harrison introduced the concept of the 'Orchestrator', a role that exists mainly for the DoD, Aerospace and Telecoms sectors. The Orchestrator has ownership of that overall control, and came out of Teradyne's work for silicon based ICT due to the costs and criticality of the tasks for that.

6. Key Takeaway for today's meeting

  1. There is a question whether there is a difference between the control function within an embedded system and that surrounding an external Test Manager.
  2. The role of an 'Orchestrator' needs to be considered - ensures that all features integrate.

7. Schedule next meeting

Next Meeting:
March 4.

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

8. Any other business

The reaffirmation of officers needs to take place. Ian will send out an email this with the intent of holding the reaffirmation vote at the next meeting.

9. Review new action items

None.

10. Adjourn

Tim moved to adjourn at 12:00 midday EST, seconded by Brad.

Respectfully submitted,
Ian McIntosh