[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-11-09

Meeting called to order at 10:37 AM EST

1. Roll Call

Adam Ley
Eric Cormack
Ian McIntosh
Patrick Au
Carl Walker
Brian Erickson
Peter Horwood (joined 10:47)

Excused:
Brad Van Treuren (comments by proxy shown [Brad (P)])
Tim Pender

2. Review and approve previous minutes:

11/02/2009 minutes:

  • Draft circulated on 2nd November:
  • No corrections noted.
  • Eric moved to approve, seconded by Patrick. No objections or abstentions.

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
  • All: Review 'straw man' virtual systems and notes on forums:
    http://forums.sjtag.org/viewtopic.php?f=29&t=109. - Ongoing
  • Ian: Add help text to question 3.5. - COMPLETE
  • Ian: Make amendments to survey invitations. - COMPLETE
  • [Ian] I made the changes to the survey form and invitations. I ran the mailing over the weekend, so every one should now have received their invitations. Have you?
  • [Eric] No, I don't think I did.
  • [Carl] I don't recall seeing anything.
  • [Ian] OK, I'll need to look into that. I now realize that I didn't get a copy here either, so I'll need to check the reports from the server, then organize a resend if necessary. {ACTION}

4. Discussion Topics

  1. White Paper Review - Review of Virtual Systems
    • [Ian] It's unfortunate Brad isn't on the call as much of the input came from him. I guess we can look at my EST diagram first. It's simpler, I guess, but we'll see if it throws anything up.
    • [Ian] In drawing this, I put a lot of what Brad has in his diagrams into a single BSCAN Test Manager box; that may be a mistake and we discussed last time that there may be scope for the tool vendors to input something here without exposing too much about their tools' inner workings.
    • [Adam] It seems to me that the key is to understand the requirements first then we can decide what we need to represent.
    • [Brad (P)] It would be nice to know the full requirements, but at this point we don't really have a clear identification of what it is we are supposed to be doing as a standard. The point of the diagrams is to foster dialog to help refine what it is that we all agree as important for the standard. Only then can we really begin to specify the requirements. Could we spend some time on Monday to pursue what Adam is referring to as requirements to get a better understanding of his definition? High level elements that are required and possibly assertions about them might fall into this category that we should be able to define today.
    • [Ian] This all led on to a thought there may be a need for a Volume 6 to address software architectures.
    • [Adam] I can't speak against that. Since we've already said that SJTAG is largely a software issue, then if we don't have software included, then we've not done it right.
    • {Peter joined}
    • [Adam] What we don't want to do is to create artificial boundaries to support the end application requirements.
    • [Brad (P)] This is a very good point! Our use cases provide us with the applications people are using JTAG for in their systems. These systems have both a software component and a hardware component as to what makes a system. We need to be smart at defining our interfaces and look especially hard at where the overlap regions are for each of these applications. It is at these overlapping regions where I feel we might be able to identify enough common elements to constitute a standard interface. The virtual systems give us a model to apply the interfaces to in order to see if they fit naturally in each environment.
    • [Ian] Getting back to the hardware aspects, I've drawn a very basic multidrop scheme. There's maybe not much to talk about there; maybe I'd have teased more out if I'd used a Star, so we could maybe have talked about, say, the issues of synchronizing the chains for 1149.6 operations.
    • [Adam] I believe you'll still have that issue with multidrop.
    • [Ian] Yes, but I think it's easier to manage in multidrop.
    • [Adam] That's possibly true.
    • [Ian] Although some of the scan path linkers can deal with it at the cost of creating longer scan chains.
    • [Ian] Maybe we should have a look at Brad's POST diagram now. Peter, maybe we can bring you in to comment here; I'm sure much of what is on this diagram can map onto features within some of your products?
    • [Peter] One of the key things here is whether you want something stand alone that sits in a corner of board, runs the POST, then releases the board to boot-up, or something like having the Test Manager, etc., embedded into existing devices. In that case it can impact on the software build.
    • [Brad (P)] Good insights, Peter. Each user of SJTAG may have different motivations for using JTAG in the system. Maybe this gets back to what Adam was referring to as requirements. The motivation for the use of JTAG is going to dictate the required run-time environment chosen to implement. POST has some very peculiar issues that Peter has begun to keenly point out. POST is one of the most difficult motivations for JTAG I have experienced and it is directly driven by the boot process requirements. In some cases we have to run the POST to completion before the board begins to boot. Others, we have to run POST as long as we can to fit it into the time budget. Still others require a multi-staged POST that runs POST on a core of logic to ensure the firmware can boot and continue the testing after the firmware is running. Some people will pay for the extra hardware so a total POST implementation in hardware can be used. Others do not have any money or space to add hardware and require a limited JTAG POST to be done using software and spare GPIO signals.
    • [Ian] I know that in our case the design team were adamant that the JTAG POST must not be dependant on software running on processors; firmware in a PLD was OK, though.
    • [Ian] The principle was that the JTAG had to verify the board structure, prior to allowing the FPGA configuration and software load. I guess that in effect the desired boot process timeline was driving the architecture of the JTAG implementation.
    • [Peter] Yes. You can have also have a board boot-up including a POST, then it reboots, this time without the POST.
    • [Ian] That requires some kind of state memory that survives between boots.
    • [Brad (P)] This is a common practice, even for some functional tests that cause the core logic of the device to not be guaranteed to be in a known/deterministic state following a test. There are also functional tests that are performed at boot where a different load is given to the programmable logic on initial power up to validate the hardware the first time the board is installed in the system. There are other functional tests that verify the version of the programmable logic and repumps the images with the updates followed by a reboot. So having a reboot after a JTAG test sequence is not unusual. The key take away is the need for a state memory that survives between boots as Ian said.
    • [Ian] Another thing that was giving us issues was that the boot time for some of our boards is quite long, so multiple boots is something we'd like to avoid. We're having to pare down the testing we do fit our 'readiness' deadline. We can increase the scope of that testing, and include reboots during in initiated BIT, as we're probably dealing with something we suspect is faulty, and have more time.
    • [Brad (P)] It is this boot time issue that has motivated some of our product teams to support both a local (on-board) boundary scan testing and a multi-drop interface. The on-board testing is performed at power up with all boards powered up independently and perform their own testing in parallel when they are ready to. C.J. Clark gave a paper at BTW2006 talking about his cJTAG architecture and solution to the concurrency of test problem.
      http://www.molesystems.com/BTW/material/BTW06//BTW06%20Presentations/BTW2006-Clark.pdf
      As Ian notes, a passing test suite takes little time to run. A failing test requires more time.
    • [Peter] I guess what we're saying is that there is some mechanism that allows vectors to be run. Some will want it stand alone and will pay for the board resources for that, some will want to use the existing facilities in their design.
    • [Ian] I guess it comes down to how expensive your software is compared to your hardware costs, considering your product volume. In our case, the volume is low enough that any software NRE swaps the extra hardware costs.
    • [Peter] What we look to have here in the diagram is a generic processor based system with some communications interface. And most boards now have a processor with some communications interface. I guess the core of the diagram could overlay onto many solutions.
    • [Ian] OK, if we look at the Remote Test diagram briefly, does anyone want to volunteer a comment?
    • [Patrick] This could be useful for field analysis. When the customer engineer gets stuck, we could run some diagnostics to see if we can find the problem.
    • [Ian] I think Brad cited the option to run tests prior to the engineer even arriving on site.
    • [Ian] In our case we would almost certainly never have our equipment attached to a network that would allow us to access the system from base. What we could do though is perhaps to access the radar via a cockpit connection to maybe the mission computer, rather than taking off hatches to get at the equipment. So what is meant by 'remote' is subject to definition.
    • [Peter] You're talking to the system via a communications interface. What that really means is 'away from the production line hardware'.
    • [Ian] It's more the point that it's some unspecified communications interface.
    • [Ian] This starts to raise some question about where the interfaces are here that we can hope to standardize.
    • [Peter] I'd say you want a high level API to run a test, collect results, and leave people to decide how to implement that, and put in features that give their product a competitive advantage. Think about NE2000 network cards; the software was standard but there any number of implementations of the NE2000.

  2. 2009 Survey
    • {Not discussed due to lack of time}

5. Schedule next meeting

Schedule for November 2009:
Monday November 16, 2009, 10:30 AM EST
Monday November 23, 2009, 10:30 AM EST
Monday November 30, 2009, 10:30 AM EST
  • Patrick won't make 16th
  • Tim won't make 23rd

6. Any other business

None.

7. Review new action items

  • Ian: Check for mailer problems and resend survey invitations.

8. Adjourn

Eric moved to adjourn at 11:29 AM EST, seconded by Brian.

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.