Minutes of Weekly Meeting, 2012-04-30

SJTAG conference call; April 30, 2012

Call to Order: 11:05 AM EDT

1. Roll Call

Absences:
Harrison Miles
Ian McIntosh

Roll Call:
Brian Erickson (left 11:31am )
Patrick Au
Peter Horwood
Carl Walker
Tim Pender
Brad Van Treuren
Eric Cormack
Adam Ley
Heiko Ehrenberg

2. Review and approve previous minutes:

Approval of April 23 minutes (draft sent April 24):
Brian moved, Carl seconded; no objections -> minutes approved

3. Old Actions

• Adam proposed we cover the following at the next meeting:
  • Establish consensus on goals and constraints
  • What are we trying to achieve?
  • What restrictions are we faced with?
• 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)

4. Discussion Topics

1. Can existing system services provide the identification as required by JTAG test?
   • [Brad} what are existing solutions doing today, using system services, in order to support identification for JTAG tests; referring to slide 3 of my slide stack Ian showed last week
   • {Brad shared the slide titled "Product Application Software" again}
   • [Brad] need some addressing mechanism to determine which of these agents to work with (doesn't necessarily have to be a hardware feature, but could be an IP address, for example);
   • [Brad] data for the test needs to be resident with the control software (on a shared resource, e.g. Flash drive in the system, or resident and available at a certain address
   • [Heiko] so that data must include the structure of the current system configuration;
   • [Brad] it depends on what the test is supposed to do; e.g. with SVF or STAPL the intent of the vector is lost;
   • [Brad] at BTW 2005 (I think) I presented on an idea to add data for diagnostics to the data set
   • [Brad] we also need some way of preserving the results
   • [Brad] available tests could be identified by test name (test step identifier)
   • [Heiko] what if two boards have tests with the same name?
   • [Brad] agent identifier can be used to identify the board/module to apply the test to; could be an combination of IP address and TCP/UDP port, for example;
   • [Brad] Gunnar was using "services" in his paper ("boundary scan service") to identify the available tests and which test to run (ITC 2005)
   • [Heiko] addressing of agents, data for diagnostics, recording of results - do we need anything else for JTAG test?
   • [Brad] we need to look at the scope of what "JTAG test" means; here we have used it to refer to board test so far;
   • [Brad] difficult: running from a multi-drop interface this model would look very different; target module for the test and control module (test controller card) are separate in multi-drop;
   • {Brian left}
   • [Tim] even before an agent becomes a diagnostic agent, it may need to be configured;
   • [Brad] one use case: tester driving data to the system with some awareness of what needs to be applied - "push" concept
   • [Tim] somehow one needs to make sure that the system is configured in a way to allow the test to be applied
   • [Brad] that ties in with the states Harrison was talking about
   • [Brad] I think Harrison was talking about a "pull" model which utilizes an external database that gets queried in order to find out which data to use for a certain board to be tested and then to fetch that date to apply the test;
   • [Brad] another use case is a built-in self test, as modeled on the "Product Application Slide";
   • [Heiko] for such cases you really only need the addressing and the reporting of results, since the diagnostics really are part of the (built-in) test itself
   • [Brad] that's what Gunnar was proposing in his papers; this also allows concurrency
   • [Tim] if there is concurrency going on, where - say - two line cards are testing themselves, then any connections between these cards need to be handled in a synchronized manner (to avoid contentions)
   • [Peter] is it a goal to standardize the diagnostics format?
   • [Brad] I'd say at least standardize what is provided for diagnostics, if not the format
   • [Brad] for each of these tests that we are applying, the intention of the vectors can be very different (e.g. a failing bit in an infra-structure test can mean a very different thing than in an interconnect test)
2. Excerpts from iNEMI survey (if available)
   • deferred

5. Today's Key Takeaways:

• identification requirements for JTAG test:
  • addressing of "agents"
  • data to support diagnostics
  • recording/preserving test results
• test control in multi-drop architecture is different than using agents embedded on every board;
• push-model vs. pull-model to obtain data
• for embedded testing a repository needs to be available in the system (for test data and for response data)

6. Schedule next meeting:

Schedule for May 7th: - bank holiday in the UK ??
14th:
21st:

7. Any other business

• Website software updates:
  • Forum, wiki,
• Organize brief on 1149.1-2012?
  • Heiko offered to prepare an overview, but will need a couple of weeks;

8. Review new action items

• Heiko to prepare overview of proposed updates for 1149.1

9. Adjourn

Peter moved, Brad seconded;
meeting adjourned at 12:04 PM EDT