Minutes of Weekly Meeting, 2010-02-22

Meeting called to order at 10:37 AM EST

1. Roll Call

Carl Walker
Adam Ley
Brian Erickson
Eric Cormack
Ian McIntosh
Michele Portolan
Tim Pender (joined 10:41)
Peter Horwood (joined 10:41)

Heiko Ehrenberg
Patrick Au

2. Review and approve previous minutes:

02/15/2010 minutes:

  • Draft circulated on 15th February:
  • One correction noted:
    • March meeting times from 15th onwards should be EDT not EST.
  • Eric moved to approve with the above corrections, seconded by Tim; 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
  • 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
  • All: Add to, or comment on, the bullet point list of architecture drivers. - Ongoing.
  • All: Provide forum comment on the graphics used during the meeting; suggest "building blocks" that may be used in future:
    http://forums.sjtag.org/viewtopic.php?f=29&p=257#p257 - Ongoing.
  • Ian: Add Newsletter section on Volume 3 work and correct existing errors. - COMPLETE - See topic 4a.

4. Discussion Topics

  1. Draft of Winter Newsletter
    • {Draft newsletter shared}
    • [Ian] I made the corrections we discussed last week and added the section on Volume 3.
    • [Ian] Brad then supplied some suggestions for further revisions, which I think he copied to you all. Are there any further comment that anyone would like to make?
    • {Silence}
    • {Tim, Peter joined}
    • [Ian] In that case, I'll take a motion to approve the Newsletter for publication.
    • {Moved by Eric, seconded by Michele. No objections or abstentions}
    • [Ian] OK, I'll get sent by the mailer later this week. {ACTION}
  2. Review of Survey Results
    • {Proxy comments from Brad are indicated: [Brad, P]}
    • Q3.7/3.8
    • [Ian] I was going to look back at Q3.7 and Q3.8 again, but as Brad isn't on the call I think I'll leave that.
    • [Ian] Last time we got up Q7.2. I know this is taking a bit of time to go through all these, but I'd like to continue and give everyone the chance to comment.
    • {Main survey charts shared}
    • Q7.3
    • [Ian] The feeling here seems to be that automation of path selection is desired, but with a degree of control from the user.
    • [Eric] Yes, that seems to be what's said.
    • Q7.4
    • [Ian] The 26% block here is essentially supporting the HSDL method.
    • [Eric] I'd say it was.
    • [Ian] But it seems like most people are in favor of including the protocols within a standard. Possibly those more in favor of user definition of the gateways are those more involved with embedded applications?
    • [Eric] That might seem reasonable.
    • [Ian] It's difficult to tell, I may need to chart that specifically.
    • Q7.5
    • [Ian] The "Don't know" answers are confusing things. I would rather that people had omitted questions they couldn't answer, so probably offering the "Don't know" option was a mistake.
    • [Ian] I guess what we can say is that there's no strong opinion in favor of constraining selection protocols to only use 1149.1 compliant operations.
    • [Eric] No, people want to have some control.
    • [Michele] Maybe the key word here is "strictly": It may be good if it is all in 1149.1, but sometimes it is just easier to have another way to do it.
    • [Ian] I think you may be right.
    • Q7.6
    • [Ian] I'm surprised at the number of "Don't know" answers here. Maybe it's just my view, but I would have thought that handling the resynchronization bits would be key to getting device vendor tools to provide support for gateway, and it always seem to be big issue for the people I speak to.
    • [Michele] Maybe it's a mix of people who don't use gateways yet and those who just didn't understand the question.
    • [Eric] Maybe we need to do some education on the website. Put some definitions up. Maybe people don't generally know about the these resynchronization bits.
    • [Ian] Do others think that standardizing on these kinds of issues will help push device vendor tools to support gateways?
    • [Tim] I doubt it. With the Altera tools, it is possible to make a chain with only Altera parts, but if the wrong one is first in the chain it will show an open chain. They can't even do the simple things, so I don't think they'll support gateways. Mostly just want to make the gateway transparent.
    • [Ian] I have to say that's been my way out. But if you need to make paths to several chains transparent then you end having to bring out a number of additional signals to do the path selection and then provide control of them. It gets messy.
    • [Peter] Tool vendors will only support something if it is standard right across the board.
    • [Michele] This is similar to a discussion in P1687. I think it should be possible to describe a gateway and it's protocols in a way that is transportable. Gateways that are transparent are outside of the standard.
    • [Ian] One things is clear and that is that gateways, as a whole, are going to be a key subject for SJTAG.
    • Q7.7
    • [Ian] Using gateways to manage access to chains in devices is a low score here. Maybe that indicates some lack of knowledge regarding 1149.7 or P1687? Skimming through the results, it looks as if that may be the case.
    • [Ian] The top three, Managing chains on boards, chains on mezzanines, and access to boards in a system, aren't surprises as top scores.
    • Q7.8
    • [Ian] We've got a cluster of results for a single interface and another for three interfaces, but not much for two interfaces.
    • [Ian] I don't think my model actually fits any of these options all that well: It's two interfaces like b) but rather than External and Embedded, the latter is more like the "Local" mentioned in c).
    • [Ian] On the other hand, the question is about interfaces rather than necessarily discussing physical ports. We're heading into the area of making external board tests reusable.
    • [Brad, P] There are a few issues here. One, there is the issue of arbitrating the input/primary ports. Two, there is the issue of viewing the topology of the scan chain in a way that an external tester may prove in the tests using the same chain topology as it would if run from the embedded environment. Otherwise, you end up with really 2 test flows to prove in. Three, there is an issue of whether the chain topology looks identical from the local embedded test port as it does from the multi-drop test port. This can be quite difficult with gateway devices that are themselves in the scan chain and visible with registers. How does one address the gateway from the multi-drop while also supporting testing by the local embedded test engine during power up concurrently with other boards? Can one really achieve identical scan chains as far as topology is concerned with a pure 1149.1 addressing protocol? I think one has to resolve the arbitration problem of Q7.8 before they can tackle the rest of the issues. If you look at Q7.9 you will see that people really want identical topologies no matter where they are accessing the chain from. Ian is right, it is a reuse zone issue.
    • Q7.9
    • [Ian] Discounting those who didn't understand the question, three-quarters would like the multidrop topology to match the board access topology. Again we're in the reuse zone here.
    • Q7.10
    • [Ian] No surprises: Almost universal demand for support of hierarchical chains.
    • Q7.11
    • [Ian] Oddly, we have no "Don't know" answers here.
    • [Eric] I was going to comment on that, given the number of "Don't know" answers we've had on the preceding questions!
    • [Ian] Anyway, Scaleability through gateways is what people want.
    • Q8.1
    • [Ian] This may be a bit misleading: The way the scores have come out, the higher scorers have been interleaved with low score items and this is exaggerating the differences. If the columns were arranged by rank then it would like a more gradual distribution.
    • [Ian] Nevertheless, the top four are no surprises Structural test, BIST, Programming and POST. Software debug gets a low score, but is maybe one of the use cases that people hadn't really considered.
    • [Ian] What disappointed me personally was how low a score EST got here. To me there are great benefit to be had in using JTAG in EST.
    • [Eric] Yes, I can see that.
    • [Tim] Maybe that's not so important, in the consumer market. It'll be more of an issue for Mil and Aero.
    • [Ian] True. But I'd have though that telecomm would also have an issue with EST - Is anyone able to comment on that?
    • [Carl] No, not really.
    • [Ian] Do Cisco products tend to be in relatively benign environments?
    • [Carl] It does vary.
    • [Brad, P] EST does have its place in telecom, but again it comes down to what the customer desires and is willing to pay for. Generally, customers of highly reliable systems require EST for telecom. I also hear that is the case for server farms. I think the consumer product industry is so low cost and disposable right now, that they do not consider it an important factor as Tim pointed out.
    • Q8.2
    • [Ian] There's a small bias of opinion towards believing that embedded test is less costly that external test, but nothing conclusive.
    • [Michele] I think a lot this will be concerns about the real estate used on the board, etc. If you asked the same question using "DFT" instead of "SJTAG" I think you'd get results that are very similar to these.
    • Q8.3
    • [Ian] Most people expect SJTAG hardware support to add up to 10% to their material cost. This will end up as a factor in the ROI equation.
    • [Brad, P] Even though the number is 10%, the ROI is perceived to be needing to be much higher to consider as a different methodology for test within the system. This is why it has been so difficult to sell to the product engineering teams. They have certain ways they have been doing things and it is difficult to introduce a new way of doing something unless they really have to because there is no other choice.
    • [Ian] OK, we'll leave things there for today.

5. Schedule next meeting

Schedule for March 2010:
Monday March 1, 2010, 10:30 AM EST
Monday March 8, 2010, 10:30 AM EST
Monday March 15, 2010, 10:30 AM EST
Monday March 22, 2010, 10:30 AM EST
Monday March 29, 2010, 10:30 AM EST

Patrick and Carl will miss March 1st.

6. Any other business


7. Review new action items

  • Ian: Publish newsletter before end of the month.

8. Adjourn

Peter moved to adjourn at 11:35 AM EST, seconded by Tim.

Respectfully submitted,
Ian McIntosh