[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-03-23

Meeting called to order at 10:35 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Brad Van Treuren
Harrison Miles
Tim Pender
Heiko Ehrenberg
Peter Horwood (joined 10:37)

Excused:
Patrick Au
Adam Ley
Carl Walker

2. Review and approve previous minutes:

3/16/2009 minutes

  • Draft circulated on 16th March:
  • Corrections:
  • Change from:
    [Tim] What about Architects?
    To:
    [Patrick] What about Architects?
  • Change from:
    [Tim] On the Use Cases: With the embedded application you need to thing about whether you have Master/Slave or multiple Masters.
    To:
    [Tim] Sounds like we are focusing questions around the use cases: however the area that really needs to be identified early is the architecture. The architecture makes all the use cases possible. Brad recently added some question to the survey on architecture. That is good; it made me start thinking more about embedded application and whether you have Master/Slave or multiple Masters and will a 5 wire bus be sufficient.
  • Brad moved to approve with these amendments, Eric 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
  • Carl W/Andrew: Set up conference call to organise review of Vol. 3 - Ongoing
  • Andrew: Make contact with VXI Consortium/Charles Greenberg. - Ongoing
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • All: Consider structure/content of survey - Ongoing
  • Harrison: Virtual system exploiting Configuration/Tuning/Instrumentation and Root Cause Analysis/Failure Mode Analysis Use Cases. - Ongoing
  • Brad: Virtual system exploiting POST and BIST Use Cases. - Ongoing
  • Ian: Virtual system exploiting Environmental Stress Test Use Cases. Discussed in topic 4b.

4. Discussion Topics

  1. White Paper
    • [Ian] There have been no updates on the website again this week. This is beginning to stagnate a bit. I had a look at The Use Case volume: There are a couple of the blank subsections I think I can add some text to if I can make the time.
    • [Heiko] It would be good if you could do that.

  2. 2009 Survey
    • [Ian] I haven't had too much time to work through my action. What I managed to do was write up some text on what an EST needs to be able to do; I've posted this under the EST Value Proposition discussion on the forums (http://forums.sjtag.org/viewtopic.php?f=14&t=48).
    • [Brad] I've been working on some material for BIST and POST but I'm not real comfortable that it's ready to share with the team yet. I've got a block diagram for POST, but the exercise is making me realise that there are some things I still need to consider. There are some global requirements and some that apply for a software based controller and others for a hardware based controller. It's sorting out what is global and what is specialised.
    • [Harrison] I've read through the definition on the site, and started to work some things up but I don't think I'm ready to share yet. I have an opportunity to discuss a customer application that fits here, so I'm looking forward to that.
    • [Brad] One of the things I'm struggling with is the different TAP sources you could have: You might have a local TAP and an external TAP and you need to work out which one takes priority, but I'm starting the realise that the answer is "it depends!"
    • [Ian] It sounds like a useful exercise. Maybe for today, though, our best option is to review my notes on the EST Use Case, if we open the forum post.
    • [Ian] What I did here was to step back from JTAG and consider what any ESS, EST or Environmental Qualification test needed to be able to do: Whether you apply a structural or functional test, there are some that need to happen in any case.
    • [Ian] The first thing is that results have to be presented to an operator for quick interpretation. How you do that probably doesn't really matter too much right now.
    • [Ian] One thing that is very important is correlating test fails with what the environmental stimulus was doing. That isn't alway easy as the environment is probably some self-contained, free-running process controller, with only very loose connection, if any, with the UUT test process. This means you may need to "time tag" results so they can be matched to the cycles of the environment. Time tags aren't inherent in JTAG, so that is data that needs to be added by the Test Manager.
    • [Ian] You have a choice to defer delivering test results, but one thing you need to then consider is the criticality of the failure: Do you have a fault like over-temperature or over-current that makes it unsafe to continue with testing? You need to make those critical faults visible immediately so that everything can get shut down, but how do you determine a critical fault from a failing vector? Do you design in some specific "flag" locations to make these faults more obvious, or use some additional monitoring process?
    • [Ian] For non-critical failures, you don't need to immediate access to detailed test data; it's probably enough to show the operator how fails have occurred, so he can decide at what point he wants to stop testing and start investigating. Diagnostics are useful but you can generally cope OK with off- line diagnostics, if trying to do it real time is going to be costly in terms of wasted test time.
    • [Ian] If you're storing test results for deferred output then you need to think about how much data you can afford to buffer up. Some tests could easily run for 24 hours or even several days. What are the appropriate intervals for dumping data. Does the test regime drive the design of the equipment or the design of the equipment drive the test regime? Do you have enough information at design time to be able to predict how much data storage you might need during test?
    • [Brad] That's an interesting perspective you've presented there. Some of the things you mentioned may have implications on other Use Cases so it's good to bring those out.
    • [Brad] One thing we've found with EST is that there is more to be learned during the transitions that just by looking at the hot soak.
    • [Ian] I agree. Our typical thermal screening cycle will be to cold soak to, say, -20°C, then switch on the UUT and start the warm-up together and continue testing right through the warm-up and the hot soak, then switch off the UUT and start the cool down. We find a lot of problems are cold-start or occur only at specific temperatures.
    • [Harrison] I'm thinking that while you have the traditional stage of testing in a controlled environment, there's also the subject of monitoring in the field, given that we have the instrumentation of IJTAG coming along.
    • [Ian] Yes, even now we might have several temperature sensors distributed through our systems, but we don't necessarily make best use of them. When we record BIT faults we don't record the temperatures unless it's an over- temperature fault, so we might be ignoring useful data.
    • [Brad] There is another issue here: 1149.1 is a polling protocol with no concept of an interrupt. You can't wait for something to go out of bounds, you have be looking periodically.
    • [Harrison] What are the other activities providing to the top? Is there some higher level entity involved? I can see information being gathered at the 1149.1 level and passed up a hierarchy. Does SJTAG fit in at that higher level?
    • [Ian] Identifying those critical faults may not be that hard. We tend to bring all the major fault signals back to something like a CPLD that has the functional BIT role of monitoring and reacting to faults. Since that CPLD tends to be in it's own chain, it should be fairly easy to spot the symptoms of a critical fault. But I'm wary of reading too much into how we approach these things. The point is you need to design it in that way.
    • [Brad] The same goes for Fault Injection. To be able to simulate those faults for software testing you need to have thought about how you can provide access to the stimulus pins.
    • [Brad] One of the things we've done with our Test Flow Control Language is to apply a subset of an SVF, then depending on the result we can then apply a completely different SVF or a different subset of the same SVF. We can do similar things with STAPL.
    • [Ian] That whole dynamic aspect is something we are a bit lacking on right now. Our testing tends to be linear.
    • [Ian] JTAG might find faults that get masked by the functional software. To prevent spurious false alarms there may be filtering on fault indicators in software, so the odd bit of noise doesn't bring the system down, but it may still be useful to know that exception ocurred. It's like BER testing: Some errors may be expected but you'd like know how frequently, in case something is degrading.
    • [Brad] Yes, gathering of trend information.
    • [Ian] I think we've talked this out for this week. Brad, Harrison do you expect to have something ready for next week?
    • [Brad] I should be able to have something.
    • [Harrison] Yes, I think so, providing other things don't come up again.

5. Schedule next meeting

Schedule for March 2009:
Monday Mar. 30, 2009, 10:30 AM EDT (15:30 BST)
We will be on British Summer Time next week, so "normal" times are resumed.

Schedule for April 2009:
Monday Apr. 6, 2009, 10:30 AM EDT
Monday Apr. 13, 2009, 10:30 AM EDT
Monday Apr. 20, 2009, 10:30 AM EDT
Monday Apr. 27, 2009, 10:30 AM EDT

6. Any other business

  • [Ian] Next week I'd like to be able to take a look at what 1149.7 might mean for SJTAG. Patrick and Adam are both keen be involved in that discussion.
  • [Brad] I've already bees asked if this means we only need two pins in the backplane now!
  • [Harrison] It's interesting that it is coming from that angle; I've seen some movement in the area I'd expect to see earliest uptake, the mobile market.
  • [Ian] I'd expect that too. It's probably the area where the reduced pin count has the highest impact. For many backplanes saving a couple of pins might not be such a big deal.
  • [Brad] I'm talking about products that are already short of pins for JTAG.
  • [Tim] And pins can add up, if you need to have more than one TAP.
  • [Harrison] The biggest investment is to get it inside the chip.
  • [Ian] I also wanted to get back to the Operating Procedures, but I'm not going to hold up the technical discussions for that. We'll just see how time goes.

7. Review new action items

None.

8. Adjourn

Moved to adjourn at 11:25 AM EDT by Peter, seconded by Tim.

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.