[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, Unpublished

Meeting called to order at 10:36 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Patrick Au
Tim Pender
Michele Portolan
Heiko Ehrenberg
Brad Van Treuren
Peter Horwood
Brian Erickson (joined 10:39)

Excused:
Carl Walker

2. Review and approve previous minutes:

11/23/2009 minutes:

  • Draft circulated on 23rd November:
  • Two corrections noted:
    • Meeting schedule - second heading should be "December"
    • AOB note from TTSC originated from P1687 WG
  • Eric moved to approve with above corrections, seconded by Heiko; 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: Post bullet points (architecture drivers) from today's discussion on forum. - COMPLETE
  • All: Add to, or comment on, the bullet point list of architecture drivers. - Ongoing.
  • {Brian joined}

4. Discussion Topics

  1. Newsletter
    • [Ian] I sent out an updated draft of the newsletter. I added the text in the section on the survey to point people to the link, and added a note on the due date for the next newsletter.
    • [Ian] Does anyone have anything else.
    • [Heiko] Is there a "do" missing near the end of the second sentence on the survey?
    • [Ian] Correct. I'll fix that.
    • {Patrick moved to approve publication with the above correction, seconded by Brad, no objections or abstentions}
    • [Ian] OK, I'll try to get that out tonight.

  2. White Paper Review - Review of Virtual Systems
    • [Ian] I posted the list of bullet points we developed last week on the forums, but when I last looked, there had be no further comments.
    • {Forum topic on Volume 3 shared}
    • [Ian] Does anyone have anything to add to this?.
    • {Silence}
    • [Ian] OK, one thing that came to my mind, because of some things I've been looking at recently was security.
    • [Ian] The background here is that I've been looking at using the Anti-Tamper Bit in some Altera devices. However it transpires that once you load the AES key and set the Anti-Tamper Bit it locks out the JTAG port for test as well as configuration. That obviously has a significant impact on the testability that can be achieved from that point on.
    • [Tim] Is that a bug or on purpose?
    • [Ian] It seem like the device vendor has been focussed on the configuration security issue and has ignored the test problem.
    • [Brain] I think that's actually deliberate on the part of Altera. Customers are concerned about hacking of things like set-top boxes or the i-Phone through the JTAG port.
    • [Brad] It's for those reasons that in some cases we've done the chain management by other ways, avoiding JTAG mechanisms. That way people can't just hack in on the JTAG port.
    • [Tim] So, is the only way to configure the device then through the configuration port?
    • [Ian] As I understand it, yes.
    • [Tim] Don't Xilinx devices use some sort of key?
    • [Ian] Well, the Altera also has a key. Once you set the AES key and fuse the AT bit, the only way to configure the device is to use a bitstream encrypted with the same AES key. Since the JTAG port does not support encrypted bitstreams, it can no longer be used. We've been getting advice from Altera and have a remote update scheme to relay the encrypted bitstream. I'm not keen on it though.
    • [Brian] They're probably reacting to customers asking then to just shut down the JTAG.
    • [Ian] I'm sure that's the case, but protecting the configuration memory doesn't need to mean denying access to the BScan I/O cells as well.
    • [Tim] Which device families does this apply to?
    • [Ian] Stratix III and Arria II that I'm aware of.
    • [Tim] What about Cyclone?
    • [Ian] I don't know. I don't think we use those.
    • [Ian] What I'm really trying to bring out is that security may have an effect testability and therefore architecture.
    • [Brad] That depends on the strategy for remote updates. In the case of the i-Phone hacking, the chain topology and devices could be determined, which gave access to registers and much of the circuitry could be discovered that way.
    • [Ian] The driver for us is the complication of ITAR and Technology Transfer deals, and trying to stop end users gaining access to parts of our systems that would allow them reuse those parts in unauthorised ways. Protecting circuit details isn't that big a deal; the IP is in the firmware.
    • [Ian] Since our philosophy now is to program a completed system box rather than programming boards as they go through manufacture, it means we can apply test loads, etc., as we need during manufacturing, and only set the AT bit at the point of shipment.
    • [Brad] We often need to update to ensure that the latest revision has been loaded onto a board.
    • [Ian] We've mandated that all firmware and software has to be loadable at the system level, with covers on.
    • [Brad] We have the issue of needing to test spare parts inventory and maybe can't test all of the features until it's installed in the customer's equipment.
    • [Ian] That's a point. We will have to supply spares at some point, but I don't know if we'll ship programmed or blank spares.
    • [Brad] Another issue, with multidrop, is that we may have boards with different art but similar function. The boards are dissimilar enough that the test for one won't work with another. That's why we came up with the concept of Boundary Scan Plug'n'Play.
    • [Ian] Yes and we're trying to head in a similar direction now, and in effect it applies to the functional BIT as well as the BScan. One "control" card in the system manages all the BIT messaging, but each board looks after the conduct of it's own BIT operations and simply reports status messages back to the control board. There's an interface control between boards, a sort of BIT API.
    • [Brad] That's similar to ATCA. If you look at my virtual systems, then what you're describing is the Manager and Agent roles.
    • [Ian] Only we're avoiding using software. But that probably doesn't change anything.
    • [Brad] No, the roles are still the same.
    • [Ian] In the past we'd have had a single process that went round polling low level features and signals. Now there's more concurrency.
    • [Brad] You've gone from a "pull model" to a "push model".
       
    • [Ian] OK how do we move forward from this bullet list?
    • [Brad] That's what's frustrating me - I haven't had time to think about it.
    • [Ian] Can we perhaps try to expand the bullets in turn, see what each implies in respect of hardware features, constraint, etc?
    • [Brad] That seems reasonable.
    • [Ian] OK, I think we may see some overlaps here. If we take the first point, multiple assemblies in a system, then that implies the last bullet, a need for addressing.
    • [Ian] There's also a need to choose an arrangement, e.g. Star or Multidrop. That can then lead to questions of fanout, buffering, impedance control, termination.
    • [Brad] I'm looking through the document for Volume 3: Some of the headings under Device Under Test Connectivity Schemes seems to be properly what we need. Maybe at this stage we don't need to be specifying Rules though.
    • [Ian] I thought that, with the comment last week about leading people in gently, that the Hardware Topologies section was maybe a bit too heavy for some readers so early in the document.
    • [Brad] There are important things like compliance enable, isolation; that is needed.
    • [Brad] There are a lot of things here that we will need for our standard; I don't want to lose the work that Carl and Carl and maybe others have put in here.
    • [Ian] What I can do is "park" a copy of this as it stands so that we don't lose anything, then we can use this as a working copy.
    • [Brad] Section like BIST, ISP, EBST, may be more properly placed in a software or some other volume; they're not really Use Cases nor architecture features.
    • [Ian] I think that the XBST and EBST sections do have a place as they relate to hardware features within the system.
    • [Brad] Maybe we should really talk about "System architecture" in this Volume 3, that way we can discuss both software and hardware: What is hardware, what is firmware, what is software.
    • [Brad] There will be overlap regions, as we discussed earlier, with some things done in software in some cases and in hardware in other cases.
    • [Ian] Sounds reasonable.
    • [Brad] We can partition things into those that are strictly hardware or strictly software, then get into things that could be done in hardware or in software.
    • [Brad] "Tooling requirements" needs to be a chapter here, and perhaps also "conformance levels" are required for Volume 3.
    • [Ian] Conformance levels was about degrees of compliance to any standard.
    • [Brad] And that gets to how you deal with COTS items in your system.

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

5. Schedule next meeting

Schedule for November 2009:
Monday December 7, 2009, 10:30 AM EST
Monday December 14, 2009, 10:30 AM EST
  • Eric won't make Dec 7 or 14
  • Patrick will miss Dec 14

6. Any other business

  • [Ian] There is an update for the forum software available that includes some important security changes. I've didn't want to apply it straight away as it's a significant update; I didn't want to interfere with the forums while we're using them. What I plan to do is update the software over the Christmas break, as that gives me time to make sure all our customizations are reloaded.

7. Review new action items

None.

8. Adjourn

Peter moved to adjourn at 11:29 AM EST, seconded by Patrick.

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.