[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-08-03

Meeting called to order at 10:39 AM EDT

1. Roll Call

Ian McIntosh
Adam Ley
Tim Pender
Heiko Ehrenberg
Carl Walker
Brad Van Treuren (joined 10:41)
Peter Horwood (joined 10:59)

Excused:
Eric Cormack
Patrick Au
Brian Erickson

2. Review and approve previous minutes:

7/27/2009 minutes:

  • Draft circulated on 27th July:
  • One correction noted:
    The following text was omitted from the approval of the 7/20 minutes:
    ", seconded by Brad, no abstentions or objections".

{Brad joined}

Heiko moved to approve with the above correction, seconded by Tim, no abstentions or 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
  • 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)
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - 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. - Ongoing
  • Ian/Brad: Construct new langauges/layers question(s) based on Brad's previous graphic to replace Q3.5. - Ongoing.
  • All: Test at least part of the draft survey form and provide comments through forums. - Ongoing.
    http://www.sjtag.org/survey/forms/form1.html
    http://forums.sjtag.org/viewtopic.php?f=32&t=83.
  • Ian: Review wiki updates on POST. - COMPLETE

4. Discussion Topics

  1. White Paper Review
    • POST Updates
    • [Ian] I went over the edits Heiko had submitted. There were a few things I had notes on from the meeting that hadn't gotten onto the page yet, so I tidied those up.
    • [Heiko] I'd kept the page open from last week but didn't submit the last edits. Does the wiki have an autosave?
    • [Ian] I don't think it does. If I'm making bit edits I often copy the page out to a text editor then paste it back in when I'm done.
    • [Ian] Value Proposition looks like the only other thing still needing attention. It looks like a bullet list that still needs formatting.
    • [Heiko] Yes.
    • Environmental Stress Test
    • [Ian] I managed to have a look at this one a couple of weeks ago, so I think it should be in pretty good order, although Tooling Requirements and Consequences still need filled out.
    • [Ian] Looking at it again, we seem to be missing the introductory paragraph.
    • [Heiko] Maybe the bit beginning "Qualification testing can be quite a lengthy process..." can go there?
    • [Ian] That's a specific extension; we really need a statement that takes in the general EST case. The same applies to Application Fields; the general case is missing. I should probably write up something for that. {ACTION}
    • [Ian] The Detailed Description looks OK. Alternative Techniques doesn't have much in there because most of the discussion seemed to be more in support of the Value Proposition.
    • [Brad] I agree that's probably the better place for that text, but it may not be clear what is meant by passive test in Alternative Techniques.
    • [Brad] The block of text containing the bullets in Value Proposition can probably be moved into Alternative Techniques.
    • [Ian] I agree with that.
    • [Brad] And probably the first few sentences of the following paragraph too. We need to reiterate the cycle time advantage of boundary scan over functional test.
    • {Peter joined}
    • [Brad] Maybe I'm missing it, but I don't see the point about testing during the thermal transitions.
    • [Ian] There is a comment related to testing during the thermal ramp and how functional test usually gives too few test cycles to be useful, but maybe it could be worded better.
    • [Brad] For Tooling Requirements, maybe we should be highlighting the difference between embedded and external test. In embedded testing I can use the same Ethernet connection for reporting boundary can results that I would use for functional test.
    • [Ian] That's a slightly different angle from us. We're trying to get away from using the mission databus cables because they're heavy and expensive and test cables don't wear too well if they're continually going through vibration cycles.
    • [Brad] That's another reason lead people into embedded testing.
    • [Tim] It's not just big and heavy. You may get into expensive materials too if you have vacuum test and need to avoid outgassing.
    • [Ian] Yes that's certainly an issue we have had with space products. All test connector shells had to be gold plated to avoid any cross-contamination that could result in outgassing during Hi-Vac testing or in use.
    • [Tim] One advantage of external testing is that it doesn't require the equipment to be functioning.
    • [Brad] True, but you usually need to provide some electronics to repeat the TAP signals, as the cables lengths can be quite long for EST.
    • [Ian] Yes, one of problems I find is that the 5-wire TAP isn't designed for long cables and using Extender Buffers, just leaves you with little boxes in the cables to get damaged during vibration. So you end up packetising the data over Ethernet to get a simpler but more robust connection. Usually that only needs part of an FPGA and few components.
    • [Brad] Yes, and that small bit of circuit is probably less likely to fail than the external buffer.
    • [Ian] I'm still keen to maintain a low-level TAP for external testing just in case we do get a total failure. I'm sure you do the same, Brad.
    • [Brad] The other thing to mention is the levels of software access that can be partitioned out with embedded testing. You can command a BIST to run as well as having independent access to the board via the same Ethernet. We often have Peek and Poke type operations via the service on the board; these are things we'd use for functional test too.
    • [Ian] What do have for Consequences?
    • [Brad] Well some of the discussion on resources given over to test should go into consequences.
    • [Ian] That's what I was thinking too. Is there more on Tooling Requirements?
    • [Brad] We need to have some way of looping tests. We also need to be able to correlate with external events.
    • [Tim] You mean time tags?
    • [Ian] Time tagging is one approach. The key concept is that we have an environment that isn't controlled by the UUT so you need to have some way to tie events during the BScan test to what the environment was doing. You might synchronise using some external trigger from the chamber controller.
    • [Brad] That's a problem with the STAPl exports; triggers aren't really a feature so have to write some c/c++ wrapper or similar to do that. You could make use of an on-demand test.
    • [Brad] In our EST the Test Shelf isn't necessarily the same as in the full system. Quite often we several identical boards in the shelf configured for loopback testing. This means you have additional test for the loopbacks that would not be part of the normal board test. We have some proprietary ways of modelling that in so we can leverage the extra test coverage.
    • [Brad] The other advantage of embedded testing is that it allows parallelism in execution that is difficult to get with external test.
    • [Ian] It sounds like we're building a strong argument for embedded testing. I should probably amend my action to undertake the revision of the whole of the EST section.

  2. 2009 Survey
    • [Ian] Over the weekend I sent out a reminder on the action, as only Heiko and I had actually used the form. I see now that Carl has also tried it out.
    • [Tim] I started looking at it earlier today, but haven't gotten round to submitting anything. What sections did you want us to fill out?
    • [Ian] Anything you like. Sections 1 and 2 are mandatory, but you needn't spend time trying get the answers "right" in those sections just now; just fill them in and move on to another part of the form. Deliberately trying to do the wrong thing is actually quite good as it's bound to happen in real use. Last year we discovered that certain characters like ampersand, apostrophe and carriage return caused the SQL injection into the database to fail. I should have those trapped this time though! And submit as many times as you like.
    • [Tim] Question 5.10 asks about the level of diagnostic resolution, but the answers don't seem to match. I'd expect to see things like "board level", "FRU" and "System" but instead there's "Go/NoGo" and "offline diagnostics".
    • [Ian] I see what you mean. There's maybe two questions here, one about the granularity of the diagnostic and another about the method of performing the diagnosis.
    • [Brad] I think it's three questions: There's the level of the diagnosis, to board, FRU, etc.; There's the locality of where the diagnosis takes place; And the resolution or detail of the diagnostic.
    • [Ian] We'll need to start thinking about the kind of help we give the user in things like pop-ups. Someone, maybe Patrick had suggested including links to the White Paper or Glossary pages.
    • [Tim] The Glossary would have been useful for the question is section 2, "What is a Test Manager", etc!
    • [Ian] Yes, there's a history behind those questions - they were to see who'd actually read the White Paper, so maybe we don't want to give clues!
    • [Brad] They were self-serving questions!
    • [Brad] We do need to take a look at the survey to see where it will feed into the White Paper or how the information will take us beyond the White Paper.
    • [Brad] I'm worried that the survey might lead us in one direction while the White Paper is heading in another.
    • [Ian] Thats a good point. We need to be careful that we haven't isolated ourselves from the global opinion, and decide what we think is the best way forward, while industry as a whole has a different aspiration. It's something we need to consider when reading over the questions: That we aren't inadvertently directing people to answer in a particular way. It is hard to keep the question neutral.
    • [Brad] Yes, we must try to avoid bias.
    • [Ian] I think we've just made an argument for avoiding adding links to other resources. The form should be self-sufficient, with just enough help to make the questions clear.
    • [Brad] That's way I'd see it should work.
    • [Tim] Once you submit the form, if you use the browser's "back" button will you be able to get back to your form with the data still entered?
    • [Ian] Yes, that should be what happens. It's a good point as it means you can then quickly submit another version with repeating filling out sections 1 and 2.

5. Schedule next meeting

Schedule for August 2009:
Monday August 10, 2009, 10:30 AM EDT (Heiko to chair)
Monday August 17, 2009, 10:30 AM EDT
Monday August 24, 2009, 10:30 AM EDT
Monday August 31, 2009, 10:30 AM EDT (provisional)

Expected absences: Ian, 10th; Patrick, 17th; Heiko, 17th and 24th, Peter 31st.

6. Any other business

None.

7. Review new action items

  • Ian: Revise wiki section on EST.

8. Adjourn

Brad moved to adjourn at 11:41 AM EDT, 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.