[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-02-23

Meeting called to order at 10:35 AM EST

1. Roll Call

Eric Cormack
Ian McIntosh
Tim Pender
Adam Ley
Carl Walker
Peter Horwood
Brad Van Treuren
Michele Portolan
Heiko Ehrenberg
Harrison Miles

Excused:
Carl Nielsen

2. Review and approve previous minutes:

2/9/2009 minutes

  • Insufficient attendees to vote on approval during last meeting.
  • no corrections and none had been advised by e-mail.
  • Eric moves to approve, Peter seconded, no objections

2/16/2009 minutes

  • comments and corrections were submitted, revised minutes were sent out;
  • no additional comments during the call;
  • Brad moves to approve, Adam seconded, no objections

3. Review old action items

  • 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?
  • Establish whether TRST needs to be addressed as requirements in the ATCA specification if it is not going to be managed globally (All)
  • Adam review ATCA standard document for FRU's states
  • Patrick contact Cadence for EDA support person.
  • All to consider what data items are missing from Data Elements diagram
  • 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)
  • Adam: (continue) revise wording of section 5 - Ongoing
    • [Adam] No progress to report.
  • Ian: Draft sample questionnaire by 02/09 - COMPLETE
  • Carl W./Andrew: Set up conference call to organise review of Vol. 3 - Ongoing
    • [Carl W] Waiting for feedback from Harrison.
    • [Harrison] It's on my to-do list.
  • Andrew: Make contact with VXI Consortium/Charles Greenberg. - Ongoing
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
    • [Ian] did not get to it last week.
    • [Brad] I added some material to the forum, an attempt to better understand how we represent registers in the context of the model.
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • All: Consider structure/content of survey - Ongoing
  • Brad: Prepare presentation given to IJTAG for next week. - COMPLETE
  • Ian: E-mail links to relevant discussion forums. - COMPLETE

4. Discussion Topics

  1. White Paper
    • Volume 2:
    • [Heiko] no updates
    • Volume 3:
    • [Carl W.] waiting for contribution by Harrison
    • Volume 4:
    • [Ian] No updates

  2. IJTAG-SJTAG Presentation [Brad]
    • [Brad] I should introduce Michele Portolan: Michele is with Bell Labs, Ireland and he and I have worked together on lot of the IJTAG material.
    • [Brad] What we have here is sub-set of slides that we previously shared with the IJATG group. I reflects some of the trends that Michele and I have seen in industry and in the developments in tooling. I'm particularly looking to Heiko and Harrison to comment here.
    • Slide 4:
    • [Brad] IJTAG identified something like 170 types of instrument. This is a simplified representation, picking on instrumentation tasks that are being done today: Sampling alarms on a dead pack, tuning SERDES links, etc.
    • [Harrison] The article in IEEE Spectrum (see 4d) will add more to that list.
    • [Brad] You might want access to what segment of a device is failing to send back to vendor. You can start the root cause analysis before de-populating the board.
    • Slide 5:
    • [Brad] Conceptual representation of the software in an embedded systems. The Diagnostic Agent is typical of what you see in functional test and needs a minimum set of resources that are functioning. BSCAN tests that are "board local" can run autonomously, but will need to return results to a Test Manager. For a multi-drop, there is no local agent; there is a virtual Diagnostic Agent resident elsewhere, on a controller card.
    • Slide 6:
    • [Brad] We want to take advantage if existing technologies. At the same time, let test engineers do what they're good at: Developing and implementing tests. System diagnostics tend to be written by software engineers and they're usually good at recognising and managing the states of a board and error handling. Embedded BSCAN could do operations in the same way, through common APIs so program loading would look similar to an interconect test.
    • Slide 8:
    • [Brad] Four stages of the Tool Integration Process are expanded in the following slides.
    • Slide 9:
    • [Brad] Model is build by tooling from persistent data, like BSDL and netlist. For the system, there may be other sources of data; HSDL is often used for some of this.
    • Slide 10:
    • [Brad] Tools vendors have been able to extend the model, by bringing in models of cluster logic or memory behaviour.
    • Slide 11:
    • [Brad] Some of the thought process on instrument access; ordered sets of registers. Basically this is extending our description of what we call "a circuit".
    • Slide 12:
    • [Brad] This is similar to what is done for cluster testing. User Defined Scripts can refine how the model is extended.
      We ask "Is this interactive, or a batch process that can be pre-generated?". A lot of things like power management can be pre-generated and run on demand. Other things like BERT need some interactivity. If your tooling can support interactivity, then you can also think about scheduling and concurrency. User defined JTAG preconditions are things like compliance pins or glue logic for chain selection.
    • Slide 13:
    • [Brad] Vector generation iterates through device acces to establish what is needed to assemble the global vectors. Currently, we generate vectors that can be applied at anytime after generation, hence SVF and STAPL.
    • Slide 14:
    • [Brad] Results may need stored and analyzed if we're looking for more than just a Go/NoGo indication.
    • Slide 15:
    • [Brad] Vectors need to packaged in some efficient form that can be transferred into the system. Results may be stored or uploaded for later analysis or actively analysed to extract diagnostics.
    • Slide 17:
    • [Brad] For interactive tooling we have to flatten everything into the Interactive Instrument Management Process.
    • Slide 18:
    • [Brad] This is really the same front end process used for the batch process generalization for creating the circuit model. The point to note, however, is that this circuit model is not directly applicable to embedded applications due to its size. This large of a model will not fit into an embedded resource space. As we move to register or device scoped vector representation for interactive programs, there is a need to begin replicating part of this information in the embedded space with as much efficiency and compaction as we can. This is where we need to identify what generalized abstractions in the representation is possible.
    • Slide 19:
    • [Brad] Taking the models and surrounding them with APIs or GUIs. Dot 7 emulations may need to be concurrent on two or more processors but run over the same chain.
      IJTAG were keen on seeing behaviour similar to LabView. This then take you into a need for Event Queues. The Instrument Extended Model provides the model of the circuit under test. The Pattern Composer turns functions into test patterns.
    • [Harrison] I think this is good, The slides point to the complexity even for a single board.
    • [Brad] Yes, and then you have the 1687 position where the chain length varies.
    • [Brad] The thing I struggle with is how we get an efficient representation that we can actually use embedded.
    • [Harrison] AMD and Intel were pushed into looking the power bill compared to the compute power. In this case speed could kill because the electric bill is too high.
    • [Brad] That brings up a good point. There may be portions of a device or board that go into shutdown to save power.
    • [Harrison] The Spectrum article also mentions ramping speed to better match demand.
    • [Brad] Tying in to the distributed systems - this reminds me of the Hypercubes and things shutting down when they're not needed.
    • [Harrison] we should also get the cellular communications industry involved (e.g. LG, Nokia, Motorola, Qualcomm, etc.).
    • [Brad] at BTW 2007 someone from Nokia made a presentation on similar topics and he may be someone we can try to get in touch with.
    • [Ian] Brad, would it be a problem if we turn this into a PDF and add it to the SJTAG website?
    • [Brad] that would be fine

  3. 2009 Survey
    • discussion postponed due to lack of time

  4. Newsletter
    • [Ian] one section "JTAG in Distributed Systems" needs a forum topic to link to.
    • [Harrison] I'm working on some material to be written up on this topic.
    • [Ian] if we can get that in this week, I can include it in the newsletter and send it out; with that addition in mind, can we approve the newsletter?
    • → Brad moves to approve the Feb 09 newsletter, seconded by Harrison.
    • [Harrison] there is also an interesting article in the Feb issue of IEEE Spectrum that relates to Distributed Systems. Google, Yahoo!, etc., creating huge server farms from server clusters pre-built in shipping containers; 67.5m3 with 2500 servers. It's on page 40, "Tech Titan Building Boom".

5. Schedule next meeting

Schedule for March 2009:
Monday Mar. 2, 2009, 10:30 AM EST
Monday Mar. 9, 2009, 10:30 AM EDT (14:30 GMT)
Monday Mar. 16, 2009, 10:30 AM EDT (14:30 GMT)
Monday Mar. 23, 2009, 10:30 AM EDT (14:30 GMT)
Monday Mar. 30, 2009, 10:30 AM EDT (15:30 BST)

6. Any other business

None.

7. Review new action items

  • Ian: Post Brad's presentation as PDF on the SJTAG website.

8. Adjourn

Moved to adjourn at 11:50 AM EST by Eric, seconded by Peter.

Many thanks to Heiko for providing additional notes.

Respectfully submitted,
Ian McIntosh

Copyright 2007-2009 The SJTAG Working Group
The SJTAG Initiative is "work-in-progress" and the views and opinions expressed here are subject to change without prior notice.