Minutes of Weekly Meeting, 2013-06-10

Meeting called to order: 11:04 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Carl Walker
Brad Van Treuren
Peter Horwood (left 11:37)
Heiko Ehrenberg
Tim Pender (joined 11:13)
Harrison Miles (joined 11:14, left 12:08)

Adam Ley
Patrick Au

2. Review and approve previous minutes:


  • One correction noted: Change "... software people don't test added into their stack." to "... software people don't test software added into their stack."
  • Eric moved to approve with the above amendment, 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
    • {System Examples slide set shared}
    • Ian had briefly summarized the slides at the previous meeting.
    • {Slide 3 - Classic Multidrop}
    • Ian noted that he had considered including a Radial Star in the slide set since it one of the topologies described in our White Paper, but wondered if it was really much different to a multidrop where the boards' gateways and selectors were replaced by a single gateway/selector on the backplane. Brad replied that the board gateways had some addressing mechanism while the selectors offered a kind of local broadcast when the chains were stitched together, but agreed that there was little difference from the star in some respects. The JTAG Switch came about where it was not possible to put the gateway on the board. Ian added that in the case of COTS boards, where the JTAG topology of the board may not be known at the time of backplane design it may be wise to include a gateway/selector on the backplane to ensure that board chains are individually accessible. Brad remarked that in the case of COTS boards there may also be some IO translators involved.
    • Brad felt that plug 'n' play could be added to the diagram by showing a path from the selector to a JTAG readable memory that held the test vectors for the board and would allow an external Test Manager to fetch those vectors. Tim enquired if the vectors may be held in Flash attached to the uP, but in Brad's case these were actually in a configuration PROM on the JTAG chain. It was generally agreed that this relied on JTAG being designed in at the outset, with SJTAG having a role in educating designers in best practise.
    • {Slide 4 - Multidrop with BIST}
    • While external control is still possible, the important feature is that the uP (could equally be an FPGA or dedicated BIST device) on each board now has a means to control the selector and the downstream chains allowing it to run self-tests autonomously. Brad noted that device was typically the Board Management Controller which has to be operational for the board to start up; there is therefore a dependency on some level of functionality in the UUT. Ian commented that in those circumstances, JTAG may not always be the best choice for performing a BIST, depending on what kind of diagnostic you needed at that point. Brad took the view that if you had the hardware in place to support board test in manufacture, then it was down to whether or not you chose to implement the software. Harrison argued that this wasn't really in the mindset of most people implementing JTAG today, and this was agreed.
    • Ian observed that the BIST was board-centric with no knowledge of the rest of the system, while Brad remarked that this supported concurrency in POST but perhaps trading power consumption for execution time.
    • {Slide 5 - Shelf Controller Multidrop}
    • This is similar to the Classic multidrop except that a Master up has the ability to coopt the multidrop bus. In Ian's description he suggested that the Master uP needed to have knowledge of the test to be applied to the other boards but Brad countered that in a Plug 'n' Play arrangement the Master could fetch the tests from the each board (after polling to see which gateways were present) and would only need to know if the test passed or failed. Essentially, this was operating higher up the protocol stack. Ian made the point that this was still board-centric testing with no interboard testing or collaboration.
    • {Peter left}
    • Ian wondered how important testing between boards was and asked if there were examples where such testing was a particular requirement. Harrison cited an example of a processing chain: While this largely predated JTAG and instead used a custom 'PCN channel' it was a case where JTAG might have been applied had it been an option. Brad has done this a few times but acknowledged that it gets back to architecture needing to support it.
    • Brad suggested the default vectors from the BSDL could be used to sample and determine that nothing was driving the backplane then patterns used to drive board to board (ensuring that only one board is driving the backplane at any time). This could reduce the knowledge needed of the system design.
    • Brad noted that as you move up the hierarchy you become more limited as to when you can run those tests, possibly on power up or during installation, while board level tests may be run with the system operational but the board is offline.
    • Ian remarked that he tends to think of JTAG tests as mainly offline or as part of POST as that is his main experience. Harrison tended to agree. However, newer techniques including instrumentation could allow for more in-service types of operation, although Harrison was now inclined to avoid overselling the opportunities from P1687. Brad noted that in past project JTAG was used to supplement functional test by checking DRAM. For P1687 as it currently stands, it was agreed that it stops at the chip boundary and there was a missing 'ICL' to take it to the board edge. Ian had been under the impression that IJTAG had been scoped at only the chip level and that SJTAG would deliver vectors to the chip, but Brad responded that early IJTAG diagrams showed a board level scope. Harrison noted that the board level for P1687 was a case of solving the same problems with a different scope.
    • {slide 6 - Delegating Controller}
    • This was similar to Slide 4, except that the Master uP (determined by some undefined arbitration process) has a communication channel to the other board controllers: This may be JTAG but is more likely to be some other bus, e.g. I2C, Ethernet, etc. This provides for similar facilities but with the addition of self-test features on each board that can be triggered or coordinated by the Master. An additional capability highlighted by Brad was that the Master could upload new tests into each board if required, commenting that this was in line with Gunnar's 2005 paper. Both Harrison and Brad preferred this architecture, feeling it was readily understood and easy to 'sell' to others. Brad added that Brocade presented a paper that was somewhat similar, using I2C to select the gateway.
    • Ian asked if this was a scheme that we should work on developing more fully as a 'Dot0' architecture. The consensus is that it was.

6. Key Takeaway for today's meeting

  1. Gateways, Selectors, and JTAG Switches all represent an abstraction of an addressable connection to a chain segment.
  2. Plug-n-Play features are required to be defined by the architecture of a system.
  3. Board BIST has no knowledge of system concerns.
  4. Gateways provide some level of "PING" capability to identify populated slots in the system.
  5. Default vectors could be used to ensure non-driving of the backplane while only one board drives at a time to reduce modeling overhead.
  6. Gunnar's 2005 ITC paper is relevant ('Remote Boundary-Scan System Test Control for the ATCA Standard', Gunnar Carlsson, David Bäckström, Erik Larsson)( http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1584042).

7. Schedule next meeting

Next Meeting:
June 24 (both Ian and Heiko are unable to make June 17, so it was decided to skip that date).

July schedule:
1, 8, 15, 22, 29
As several people indicated that they'd be absent on July 1 that date may be skipped - to be decided at next meeting.

8. Any other business

  • No contact from Bill Eklow yet.
  • {Harrison left}
  • Ian had set all Newsletters subscribers to 'unconfirmed' and set out fresh verification requests. So far 27 people have resubscribed, mostly on the first day. Ian will send out a final reminder a week from now to those who have not yet responded.

9. Review new action items


10. Adjourn

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

Respectfully submitted,
Ian McIntosh