[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-06-08

Meeting called to order at 10:35 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Peter Horwood
Brad Van Treuren
Tim Pender
Adam Ley
Carl Walker
Heiko Ehrenberg (joined 11:00 AM)

Excused:
Brian Erickson

2. Review and approve previous minutes:

6/1/2009 minutes:

  • Draft circulated on 1st June:
  • No corrections noted.

Eric moved to approve, Brad 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)
  • 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 - CANCELLED
  • 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
  • Brad/Ian - Prepare draft survey for review by group. - CLOSED.
  • All: Propose answer options for the questions shown as needing completion. - CANCELLED.
  • All: Assess which section each question should be placed into. - CANCELLED.
  • Ian/Brad: Construct new question(s) for row 21 based on Brad's previous graphic. - Ongoing.
  • Ian/Brad: Construct new question(s) on gateway devices (linkers, bridges, instrumentation gateways). - Ongoing.
  • [Ian] There are few actions involving Harrison, but he hasn't joined the call for several weeks, so we haven't been able to move those at all.
  • [Ian] I'm inclined to close the action on preparing the draft survey for review. I think we've achieved that.
  • [Brad] I'd agree with that. It wouldn't preclude further changes.
  • [Ian] No, and there are three actions for the group to review and propose amendments to the survey: I propose to cancel those and replace them with a single action to review and comment through the forum.
  • [Brad] That sounds like a reasonable change. {ACTION}

4. Discussion Topics

  1. Architectural Features of an SJTAG Board
    • [Ian] Looking back at last year's survey, I was drawn again to the fact that virtually no-one felt that a common hardware architecture was important. I can understand that, but over the months we've discussed several hardware features that we thought may be important, including the items I listed as "discussion seeds" in the calling notice. I guess I'm asking if there's a "line in the sand" on how far we can dictate hardware aspects within the standard and if so, can we define it?
    • [Brad] It's important we know whether SJTAG is a hardware standard or a software standard or a bit of both.
    • [Ian] For example, so that OEM/COTS vendors can supply boards that are SJTAG compliant do we expect to have a defined TAP signalling voltage?
    • [Brad] If you're working with something like ATCA you have to comply with that standard. If we start to define things like voltages in SJTAG we could end up conflicting with, say, PCI.
    • [Eric] I agree, we can't pin people down on voltages. Logic levels are likely to keep going down.
    • [Ian] OK. I guess that when 1149.1 was drawn up there was a kind of assumption that 5V logic would be around forever, but we've seen 3V3, 2V5, 1V8, 1V6 and still heading down. But in that case how do we define an interface?
    • [Brad] For most COTS boards, I'd hope that they comply with some industry standard like ATCA, PCI, etc.; we piggy back onto that.
    • [Tim] A lot of pods commonly sense the board voltage and set the TAP to that.
    • [Ian] And that brings in the issue of using additional signals beyond the 5-wire TAP.
    • [Brad] These kinds of things could be a note.
    • [Tim] You'll get the same things with terminations; some will want to pull up others will pull down.
    • [Ian] Does an SJTAG board have only a single TAP? Does it matter?
    • [Carl] Most of our boards have two TAPs for redundancy.
    • [Brad] With a multidrop from the backplane, a local TAP for embedded control and a manufacturing test TAP, you could have three.
    • [Ian] We usually have a single TAP to the backplane, but maybe three or four on the frontplane, mainly for board test and programming.
    • [Brad] But you still need to manage the access to those TAPs.
    • [Carl] We also have muxing logic for that.
    • [Tim] I guess I can see the need for two TAPs.
    • [Brad] There is test from the edge, test from the local controller, and test from a manufacturing test header. I guess that may be the same as edge access.
    • [Tim] Some of the headers can be a bit big. Do we make recommendations on using more dense connectors?
    • [Brad] That's a recommendation I'd not be keen on making.
    • [Tim] With two TAPS that maybe means 12 or 14 pins. I think that at least the pinouts should be standard.
    • {Heiko joined the call}
    • [Brad] Well, I have JTAG piggybacked over fibre.
    • [Carl] The physical layers will always change.
    • [Tim] OK, I guess it also comes down to device vendor's preferred pinouts too.
    • [Carl] And every device vendor will base that on their existing pods.
    • [Tim] Do we want to come up with definitions for various classes of header; I'm thinking of access into the system.
    • [Peter] I agree with Tim, that you should be able to define a standard system connector.
    • [Brad] I know of at least one tool vendor who offers JTAG access to an embedded bit of IP over ethernet.
    • [Ian] A standard pinout presumes using the 5-wire TAP, but one of the problems we found with using JTAG in EST with an external controller was that the 5-wire interface isn't robust enough for the cable lengths involved. Going to differential pairs is one step, but we're looking at that JTAG over ethernet option. We've also considered using an IrDA port for a contactless connection.
    • [Ian] Within the types of Test Access Connector we use, I'd be happy enough to declare a standard pinout for things like JTAG for our own applications, but I wouldn't think those connectors would translate well into the likes of Brad's or Carl's businesses.
    • [Tim] This kind of gets into gateways too.
    • [Brad] I think that we've decided that we need to define a minimum signal set required to support SJTAG, but the physical implementation is up to the user.
    • [Carl] Exactly. How they get abstracted is of little importance.
    • [Tim] Do we have any CMs on the call?
    • [Ian] I don't think we even have any CMs on the fringe group. but I guess that CMs will really only be interested in the board level operations.
    • [Tim] Yes, so they'd be keen to see more consistency in connection.
    • [Carl] Our CMs would say "You're going to supply us with all the assets we need to test your boards".
    • [Tim] If people want to put SJTAG into their system, maybe the first thing they'll look for is some recommendation on pinouts, so we'll need to state that they should define their own pinout.
    • [Brad] An additional signal that we find useful is one to indicate that a mux path has been activated.
    • [Carl] We have much the same feature for the same reasons.
    • [Tim] That's similar to the Mode Pin I have. I default to connecting the chains for the device family for the pod. When the Mode Pin is set then the path selection becomes active.
    • [Ian] What about identifying board type or build standard: How should we be managing the dynamic configuration of systems? Do we use call backs?
    • [Brad] You get into a chicken and egg situation. Typically, the information is already there for system functional use. Call backs are usable for internal querying but assume some level of functionality.
    • [Brad] The alternative is to have vectors associated with the UUT and have the system controller fetch them as required. This ensures that the right vectors are always available, and gives the simplest method of management.
    • [Ian] Yeah, I can see why that works, and it'd probably map into externally controlled tests too.
    • [Brad] What I'm more concerned about is getting access to board state signals; Is it online, handling a call and I should leave it alone, or is it offline and available to test? That's why we want to embed BScan, to get the coordination with the system logistics.
    • [Ian] I can see that being important, especially in your business.
    • [Brad] I'm interested to hear reactions on vector locality. I prefer test data to be stored within the UUT.
    • [Ian] I like the idea but I'm thinking that there are cases where might not be popular. Most of our systems don't change configuration in the field, so we pretty much know what's in the system. But you'll get cases where the vectors need to change because of a BOM change even if the PCB artwork is the same. Changing the brand of flash, for example, will change the result of a ReadID but notionally the board is the same from a functional perspective.
    • [Heiko] I'm not sure. Some people will be reluctant to allocate the extra memory needed to store the test data.
    • [Brad] I want to think about the process issues to ensure you get the right vectors.
    • [Heiko] You need some database that you can lookup the board type and get the relevant tests from.
    • [Eric] On some of the designs I've worked with in the past, there'd be a small PROM that was programmed up at manufacture. You read that and then lookup a database of tests.
    • [Tim] You shouldn't get surprises in the field. You should know what's in each system.
    • [Brad] Maybe where this is headed is what we might call our "dot 1": In dot 0 you manage the test data. For dot 1 and a higher level of compliance you have the vectors on board.
    • [Tim] Much of my business is high speed scanners. They're linked to PCs so storage can use the HDD in there. That keeps the memory in the scanner available for scanning functions.
    • [Ian] Some of the survey questions ask about the memory available for test.
    • [Eric] I'm looking forward to seeing the responses on that.
    • [Ian] The bottom line is that there's a cost, and there has to be a return shown on that investment.
    • [Brad] I think we've identified that there needs to be different levels of compliance: A minimum level and then deeper level with increasing levels of constraint.
    • [Ian] In the past we talked about "SJTAG Compliant" and "SJTAG Compatible". I sense that we're now talking about finer grained compliance levels.
    • [Brad] I think we are.

  2. 2009 Survey
    • [Ian] I didn't manage to write up any new questions on gateways, despite the useful discussion last week on the subject. I started out to do this, but ended up distracting myself with changing the order of the questions as I couldn't see a natural place to set out the gateway questions.
    • [Brad] Yeah, I started to think about it, but then some of fires I'm dealing with now started to come up.
    • [Ian] There's no feedback coming through the forum again this week.
    • [Ian] We also need to expand the "line 21" question, as noted in the actions.

5. Schedule next meeting

Schedule for June 2009:
Monday June 15, 2009, 10:30 AM EDT
Monday June 22, 2009, 10:30 AM EDT
Monday June 29, 2009, 10:30 AM EDT

6. Any other business

None.

7. Review new action items

8. Adjourn

Eric moved to adjourn at 11:47 AM EDT, seconded by Peter.

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.