Minutes of Weekly Meeting, 2013-04-22

Meeting called to order: 11:04 AM EDT

1. Roll Call

Ian McIntosh
Brian Erickson
Eric Cormack
Harrison Miles
Carl Walker
Patrick Au
Adam Ley (left 11:29)
Brad Van Treuren (joined 11:06)
Heiko Ehrenberg (joined 11:11)
Peter Horwood (joined 11:14)

Excused:
Tim Pender

2. Review and approve previous minutes:

4/15/2013:

  • Eric noted one correction in Section 5:
    Change '... what is source was,...' to '... what its source was,...'.
  • Eric moved to approve with the above amendment, seconded by Brian. 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)
  • 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. Ian added that he expected this would take a little time.

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. Newsletter
    • The newsletter is due early next week, but there are currently no suitable topics identified. Brad didn't feel that the current stack discussion was mature enough for publication. Brad had an idea for an article on new technologies but it would need time that he didn't have this week to in order to prepare it.
    • Heiko asked if the mailer tooling could report on whether recipients had read the newsletter of followed up by clicking any links, as this would help gauge whether it was worth writing the newsletter or show what articles were of interest. Ian didn't think the tooling was able to track that kind of data. {Post meeting note: Both message tracking and click tracking are available within the software, but neither is currently enabled.} In that vein, Ian thought it might be worthwhile using the newsletter to get people to verify their interest in continuing to receive the newsletter and clean up the database, similar to the way Brad validated the SJTAG membership via a request to complete a survey. Brad noted that it was important to filter on positive responses only.
    • Heiko suggested that the newsletter could be used to seek out examples that could be used for our 'worked example'. That could be done by presenting only an overview of how he hoped to use the example.
    • Ian would draft up a newsletter addressing both the appeal for examples and revalidation of recipients. {ACTION}
  2. Follow up on Mike Westermeier's slides/Harrison's slides
    • Ian opened up a topic from an email from Brad, that there may need to be some form of 'virtual P1687 register' to use with non-scannable (memory mapped) instruments.
    • Harrison commented that P1687 allows you to take devices into a near mission mode state of operation.
    • {Adam left}
    • Brad's point was that it should just be another interface, and this was the abstraction in TFCL: It was up to the Test Step to understand the access mechanism. Brad felt that last week's discussion was trying to delineate roles for each layer but failed to acknowledge that sometimes those roles can be delegated to a lower layer.
    • Harrison argued that much of the topical discussion centered around the chip and that the layers were a first attempt to get buy-in at the board and chassis levels of assembly. Harrison didn't believe that this was because it was perceived to be complex but simply because there weren't enough examples. P1687 is the grandest attempt so far at organizing the chip. Brad maintained that is was still the Test Step level that carried the understanding of the protocol involved, whether it was a P1687 or a memory mapped instrument being considered. Harrison agreed and added that P1687 was providing an abstraction, while Brad observed that in making the abstraction P1687 was standardizing the interface.
    • Harrison saw that we were facing some of the same consideration of conventions as P1687: The use of namespaces, the use of 'levels' (do we need a Level 0 and a Level 1?), etc. Brad added that much of this was in common with the software community where 'agents' are running on boards and need to communicate with the top layer to get the application to work.
    • {Peter dropped off the call for a few minutes}
    • {Slide from previous meeting shared}
    • Harrison wondered if what he should have shown, although unsure where, was a SOA-like (Service Oriented Architecture) middleware layer. Brad agreed but he was not convinced that the layer Harrison presented properly correlated with the boxes on the left of the diagram; for example it was quite possible that Test Packages might apply at the board. Harrison felt he might be interpreting the layers differently and accepting that all of those things could be pushed into the board, felt this was a reasonable way to build up from the chip, so he was using the concept of a board as a 'collection point'.
    • Brad saw the Test Package as equivalent to an action in NI Test Stand - something that needs to happen a particular point in time as the result of a preceding decision. Harrison accepted that but has assumed that it was running at the board level. Brad noted that was one application but not necessarily the application. Harrison was trying to follow the hierarchy from chip to board to chassis, etc.
    • Ian thought that was OK but maybe we had missed how the aggregation could be nested: 'Chips' could be aggregated in a stacked die or SOC as easily as on a board, daughter boards could be aggregated on a carrier board, etc. This may mean that as move down the stack you may need branch and work down a fresh stack. A form of recursion. Brad agreed that a stack may contain sub-stacks.
    • Harrison maintained that P1687 was providing a significant step forward which Brad acknowledged but added that there would still be traditional testing that might have no need of instruments.
    • Harrison wondered if he should have considered three trees: One stack for manufacturing and NPI, a second for manufacturing for production and a third for aggregation of 'production items' (boards). Until now, he felt JTAG has just been for getting things out of the factory, but there was the opportunity to use it for 'bare metal' assessment of the system.
    • Brad noted that the intent when he prepared the original stack diagram was to try to decouple the tests from the application that was trying to run them, so that tests could be changed without changing the application software as that could often be costly. This was a different goal to that set for P1687.
    • Harrison felt that the framework formed by P1687 and P1838 were in concert as they gave consistency at the chip level, although they did not offer complete answers in themselves. Brad's goal was to have separation and he felt that P1687 was just giving an interface, much like a memory mapped instrument. Harrison commented that P1687 hasn't looked at the board level ICL yet.
    • Brad commented that some applications, like programming devices, has no need of P1687. There are possibly two types of solution: The tightly coupled one that doesn't use the full stack, only the bottom layers and the loosely coupled one that uses the whole stack.
    • Harrison remarked that some user want the ability to back the embedded software out and run the tests externally, or use JTAG for emulation and take over the board.
    • Ian was reminded by the discussion of something that troubled him about 1149.1-2013. Some of the recent changes had moved away from 1149.1 defining the interface and TAP controller on the device and was now specifying behavioral aspects of the devices. That seemed to be out of place and may possibly create future problems. Harrison noted that Carol Pyron's view may have been that P1687 was taking too long, so it was better to get these things in somewhere.
    • Ian felt there was still a long way to go to establish a consolidated view on the stack (or stacks). Brad though the discussion was helping to flesh out where our 'dot' releases are and to move towards looking at the requirements, as Adam had suggested.

6. Key Takeaway for today's meeting

  1. The intent behind Brad's original version of the stack was to decouple 'test code' from 'application code'.
  2. P1687 instrument registers should look no different to memory mapped instruments from a behavioral perspective.

7. Schedule next meeting

Next Meeting:
April 29. Eric and Patrick will be absent.

May schedule:
6 - Patrick will be absent.
13 - Eric will be absent.
20
27

8. Any other business

  • Ian has emailed Bill Eklow for any update BTW plans. Too soon to expect a reply.

9. Review new action items

  • Ian: Draft newsletter with call for mailing list members to revalidate their interest.

10. Adjourn

Peter moved to adjourn at 12:10 PM EDT, seconded by Eric.

Respectfully submitted,
Ian McIntosh