Meeting Minutes - 2010-03-15

Minutes of Weekly Meeting, 2010-03-15

Meeting called to order at 10:40 AM EST

1. Roll Call

Eric Cormack
Ian McIntosh
Brian Erickson
Tim Pender
Peter Horwood
Heiko Ehrenberg
Michele Portolan
Adam Ley (joined 10:50)

Excused:
Carl Walker

2. Review and approve previous minutes:

03/08/2010 minutes:

  • Draft circulated on 11th March:
  • Two corrections noted:
    • Adam's comment on Q9.4 should be '...probably see more "we already do this" answers'.
    • Tim's expected absence has moved from 3/15 to 3/22.
  • Eric moved to approve with the above corrections, seconded by Adam; 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
  • 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.
  • Heiko: create forum entries for what we have so far for further discussions / details; send out an email with links to these new forum topics. - COMPLETE
  • ALL: review / comment in preparation for upcoming meetings. - see discussion

4. Discussion Topics

  1. White Paper Volume 3 Review
    • What are the 'big topics' for system JTAG architectures?
    • Can we relate these to the 'building blocks' we discussed before?
    • Do these things give us a direction for how we proceed with discussion or how we structure Volume 3?
       
    • [Ian] Heiko posted the items that had been identified during the previous two meetings.
    • {Forum post 'Big (Hot) Topics for system JTAG architectures' shared}
      {http://forums.sjtag.org/viewtopic.php?f=29&t=115}
    • [Ian] Is there anything we want to add here or anything we want to discuss further?
    • [Eric] It doesn't seem like it.
    • [Ian] Didn't we have 'backplanes' as one of the items?
    • [Eric] Yes we did.
    • [Heiko] OK, I must have missed that.
    • [Ian] I guess another thing that can become an issue is control of the board boundary.
    • [Ian] A little while back, probably late last year, we tried to think of 'building blocks' that we could use as part of our descriptions.
    • {Forum post 'Drivers for Hardware Architecture - Brainstorm' shared}
      {http://forums.sjtag.org/viewtopic.php?f=29&t=110}
    • [Ian] Actually, this isn't the post I was thinking of! I was thinking of the post that had the hand drawn diagrams in it. However there are still a number of pertinent items mentioned there, and worth a quick refresh on some of those things:
      • Means to isolate assembly under test from other signals on the backplane
      • Coexistence of embedded control with option for external control
      • Fanout may be large, especially across large backplanes
      • Security
    • [Ian] A good number of these things line up with the bullet points we had from the last two meetings. A number of the items I raised two weeks ago can be traced back to observations drawn from the survey inputs.
    • [Eric] I think the diagrams you were thinking of were in the 'Virtual System' posts.
      • [Ian] Ah, OK!
  2. {Forum post 'Virtual System' shared}
    {http://forums.sjtag.org/viewtopic.php?f=29&t=109}
  3. [Ian] These introduce a few items that we haven't really considered elsewhere, such as 'Temporary Storage' and the concept that there some overall management process outside of the JTAG domain.
  4. [Ian] The real question is that having made all these observations, does this help us to shape Volume 3 in any way?
  5. {silence}
  6. [Ian] We some useful content in the existing document, but some of it is maybe going too deep for a White Paper and other things need fleshed out more. I'm conscious that as a White Paper this shouldn't be an attempt to draft the standard.
  7. [Ian] We've tended to look at things more abstractly to keep everything generalised, but would a 'worked example' allow people to take away the essential lessons and apply it to their own applications?
  8. [Eric] I think it could. People are looking for direction, so abstraction doesn't really help. I think people want us to do most of the directing.
  9. [Ian] Well, when we look back to the interview we did for the magazine article, one of the questions was whether there was any 'best practice' advice. I know I get people saying to me "Just sketch me out an architecture that'll work, and I'll do it"; they don't really want to have to work out all the implications from first principles.
  10. [Eric] There are always going to be exceptions, but that could be a benefit, providing us with enhancements for the future.
  11. [Brian] You're talking about Best Practice for a typical application?
  12. [Ian] Yes, if we think that provides an adequate illustration for people. Volume 3 is probably where the hardware designer first makes contact with SJTAG, so I'm thinking we can put things in a way the hardware designer can quickly grasp, at least at the front end of the document.
  13. [Brian] Design engineers, and test engineers, tend to look at best practices as guidelines only, and if it doesn't fit what they're doing then they'll ignore them.
  14. [Ian] That's OK so long as they've taken away some learning that they can apply.
  15. [Brian] Maybe just need to include that in the write up.
  16. [Ian] Is it possible to talk round a single example system? We currently discuss three connectivity topologies in Volume three, and then there is the issue of embedded and external control. If we try to cover every case then we may just end up confusing people, instead of helping to guide their design decisions.
  17. [Ian] Is there one preferred connectivity topology? Most people seem to talk about Multidrop, but I gather microTCA used something more like the Star.
  18. [Eric] It's too difficult to talk about both.
  19. [Tim] It's pretty much the case that there will be some different Use Cases depending on where the master controller resides. All the JTAG features themselves aren't that important once you can get the commands to them. What is important is to understand what the similarities and differences are in each of the possible solutions.
  20. [Ian] In the existing diagrams we have, the locality of the master controller isn't really addressed. You could read these diagrams and assume that it is always external.
  21. [Tim] Also there's the issue of digital I/O that is not available in the system. If you're using digital I/O during board test to control some things then you may need to find another way to do that in the system.
  22. [Tim] You maybe need some abstraction for scan path selection, then everything should be the same no matter who is the master.
  23. [Ian] We've got 'Ring', 'Star', and 'Multi-drop', are we suggesting that the Ring is 'Bad Practice'?
  24. [Peter] It may be, but some designers will go for that because it's inside their comfort zone.
  25. [Ian] I met someone at a conference a year or two back who asked me to explain why he shouldn't use a ring. He just hadn't considered the possible consequence of a missing board or a single chain fault.
  26. [Tim] With the survey, in the question on how many of the standards were recognised we saw that a lot of people knew of a lot of the standards. But the focus group is maybe the more advanced users. I think if we went out to the wider group then we'd see less familiarity.
  27. [Ian] That's a good point Tim. In one of Brad's comments he observed that the survey showed 'we were talking to the right people', but in some cases that might be a bad thing.
  28. [Ian] It sounds like we feel the need for a diagram pretty much up towards the front of the document that introduces the management of chains. I can try to sketch something up that we can maybe talk round next week. {ACTION}
  29. [Tim] Maybe need a generalised controller, ignoring any aspect of locality at first, then show possible solutions, their drawbacks and advantages.
  30. [Ian] The point isn't for this volume to present a finished, ready-to-use architecture, but to provide the information to help guide design decisions.

5. Schedule next meeting

Schedule for March 2010:
Monday March 22, 2010, 10:30 AM EDT
Monday March 29, 2010, 10:30 AM EDT

Schedule for April 2010:
Monday April 05, 2010, 10:30 AM EDT
Monday April 12, 2010, 10:30 AM EDT
Monday April 19, 2010, 10:30 AM EDT
Monday April 26, 2010, 10:30 AM EDT

Tim and Peter will miss March 22nd.
Carl and Peter will miss March 29th.
Ian, Heiko and Brian will miss April 5th.
Eric will likely miss all meetings in April.

Review viability of meeting on April 5th at next meeting.

6. Any other business

None.

7. Review new action items

  • Ian: Draft a generic system diagram for discussion next week.

8. Adjourn

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

Respectfully submitted,
Ian McIntosh