[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2010-05-24

Meeting called to order at 10:35 AM EST

1. Roll Call

Eric Cormack
Ian McIntosh
Carl Walker
Tim Pender
Brad Van Treuren
Patrick Au
Michele Portolan
Peter Horwood (joined 10:47)

Excused:
Heiko Ehrenberg
Adam Ley

2. Review and approve previous minutes:

05/10/2010 minutes:

  • Draft circulated on 10th May:
  • Corrections supplied by Brad:
    • [Ian] Brad managed to get some more slides out, which we'll go through. I've got a couple too, but they're more just some thoughts I had. They kind of fit in with some of Brad's, so I'll jump to them when it comes up.
    • [Ian] This is a new one on the switch.
    • [Brad] That's what I wondered. I did try to overlay this onto 1149.1 state machine diagram, but it was difficult to show how it changes over time.
    • [Brad] There are pros and cons on both sides. There's no one technology that suits everyone - it's dependent on the application. Some are more cost effective than an ASP. That's the tradeoff and some will only test from external or multidrop.
  • Brad moved to approve with the above corrections, seconded by Patrick, no objections or abstentions.

05/17/2010 minutes:

  • Draft circulated on 20th May:
  • Two proxy additions following Brad's comment:
    • [Brad] There is a reason the commercial linker devices place the internal data register closest to TDO in their designs. But, I am not sure why that is the case. I really have not spent much time thinking about it until now.
    • [Ian, P] I'm not sure but it may be so that that you can at least get the linker's ID back during an infrastructure test even if the selected "Local" Scan chains are broken. In the example with the CPLD, placing it near TDI may make sense in many ways, but also means that you're "working blind" if you get no TDO at all.
    • [Peter, P] I would like to add, between the commercial linker vendors there is a mix; some have their data registers closest to the TDI whilst another has its registers closest to TDO.
  • Patrick moved to approve with the above additions, 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?
  • 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.
  • ALL: review / comment in preparation for upcoming meetings. - Ongoing

4. Discussion Topics

  1. White Paper Volume 3 Review - Discussion of system description diagrams
    • {SJTAG Volume 3 Consolidated V5.ppt shared}
    • [Brad] I didn't get time this week to add to the slides. I didn't even manage to make the changes we discussed last week.
    • [Ian] The slides I have are the same ones you discussed last week?
    • [Brad] That's right.
    • [Ian] OK. Well, I hardly had time to look at them myself!

  2. How do we turn this into White Paper (wiki) material?
    • [Ian] Our plan was really to update the White Paper, so how can we take this material and set it out in White Paper format? I guess we could use the diagrams and flesh out the bullet points. But it seems like a lot of graphics for that format.
    • [Brad] We don't want the wiki just being notes pages for the presentation. I'm not sure that we want just references to the presentation.
    • [Eric, Ian] No, we don't want that.
    • [Ian] I guess we could cherry pick some of the diagrams and use text to fill in the blanks.
    • [Brad] We need to assess what our primary goal is for this section. To me, the big take away is knowing what are the key points we are trying to make in each section and building the white paper around those. I don't think there is anything in the Basic Input/Output Primitives that the reader should not have already known. In Scan Chain Elements I think it is the notion of STATIC_PATH, DYNAMIC_PATH, and EXTERNAL_PATH that are the key take-a-ways.
      And I forgot to mention the TAP Interface there.
    • [Ian] You mean the distinction we drew between a TAP Interface and an External Path?
    • [Brad] That's right.
    • [Brad] In Scan Chain Topologies and System Scan Chain Configurations, I think the keys are how the previous path elements may be assembled to provide flexible chain configurations at both the board and system level. I think the real meat of the insights is the Basic Selection Primitives. Followed by the Port Addressing Primitives.
    • [Tim] I think we want to show one of the more desired solutions, but show the evolution in a matrix: Put the features in the columns and use the rows for the evolution. The desired solution will be one of the ones with the most crosses in the row.
    • [Ian] I think I can see that, but it may be something that we'd need to go through a few iterations before we're happy with it.
    • [Ian] I'm keen to see how this would look in the wiki, but I don't really want to detract from work on this presentation. But I think, Brad, you were now struggling a bit to see how we moved on from where we are now?
    • [Brad] Yeah, the system-level is a bit more of a struggle. I'd like to see the wiki start to show some of the things we've developed here. Maybe we can do as Tim suggested and introduce a problem domain first. Show all the interfaces you can end up with in a system, then show how the connectivity primitives address how you deal with the management of those interfaces.
    • [Ian] Maybe Tim would like to have a try at sketching out a first pass at the matrix?
    • [Tim] OK, I guess I can try. {ACTION}
    • [Ian] In the meantime, I can have a go at putting something onto a wiki page to see how that goes. {ACTION}
    • [Ian] That leaves Brad relatively free to work on the slides.
       
    • [Brad] I had a question for Michele: I've seen some emails on P1687, mainly from Al Crouch, referring to 'SIB' and 'NIB' - what is the difference?
    • [Michele] In the SIB, the control register and mux are right after each other, but in the NIB they may be in different parts of the chain. I think these are mainly Al's terminology.
    • [Brad] I saw something that said 'NIB is for new chains, SIB is for old chains'. I just wondered if we're missing something here?
    • [Michele] I'm not sure about that. These may not even be fully supported by P1687.

  3. Spring Newsletter
    • {2010_May.htm shared}
    • [Ian] This was a fairly rushed draft that I sent out over the weekend.
    • [Patrick] Surely we're into 'Summer' now.
    • [Ian] Well, I tend to look at this as a retrospective on the past three months, but the timing of the Newsletter does make it a bit ambiguous.
    • [Ian] There a couple of things that we said we'd do in the last Newsletter, so I though we ought to comment on those, as otherwise it looks as if we're not progressing. The first is the wiki which we've discussed.
    • [Ian] The other is the survey. At the beginning of March we completed our review of the results. That took us a few weeks longer than we'd planned. I'd hoped to get the charts onto a few webpages with some supporting discussion, but maybe we can grab a few charts to include in the newsletter to show that we did something?
    • [Brad] That sounds OK, but it'll be hard to choose which results to feature. Maybe we can spend a little time now to go over the charts to see which we could use?
    • [Ian] OK, I'm happy to do that.
    • {q1_2009_4.pdf shared}
    • [Ian] There won't be anything worth showing from the first few sections.
    • [Brad] 3.9 might be interesting, if only because of the 100% agreement!
    • [Ian] Yes, but it did make me wonder if the question had been properly understood by everyone.
    • [Brad] Well, you could mention that in the newsletter article.
    • [Brad] 4.2 was somewhat interesting.
    • [Ian] Yes, it shows a bit more breadth in the range of system complexities than I had expected.
    • [Ian] 5.8 and 5.9 are interesting to compare since one relates to the board level while the other is the system level.
    • [Ian] 6.2 is interesting because it really has a lack of a result! This was where we added a diagram to aid with understanding the layers and interfaces but it doesn't seem to have helped people here.
    • [Brad] It definitely shows there was confusion.
    • [Ian] OK we've got a few things here now that I can use to supplement the newsletter a little. I'll do some rework and recirculate through this week. We'll probably have to do the approval via email, since we won't meet again until June 7th. {ACTION}
    • [Brad] On the section on the wiki, I wonder if you can give a taster of the primitives?
    • [Ian] Probably. Was there some you particularly had in mind?
    • [Brad] Well, the slide with the ISW, OSW, etc. on it, and maybe the path selection bypass block.
    • [Brad] I was hoping you could put the core primitives horizontally with the bypass maybe centered below them?
    • [Ian] OK, I can try. I'll need to do a bit of resizing images, so we'll need to see how presentable they are after doing that.
    • [Ian] Are there any other suggestions for the Newsletter?
    • {Silence}
    • [Brad] Maybe the links on the articles have been flip-flopped?
    • [Ian] Yeah, I cut'n'pasted a link in while editing and must have then amended the wrong one. I'll need to fix that.

5. Schedule next meeting

No meeting on May 31.

Schedule for June 2010:
June 7, 2010
June 14, 2010
June 21, 2010
June 28, 2010

6. Any other business

The motion on signal naming conventions from the meeting of May 3rd remains tabled.

7. Review new action items

  • Tim: Draft matrix of SJTAG features against evolving solution options.
  • Ian: Make initial attempt at migrating some presentation material onto Wiki.
  • Ian: Update draft Newsletter with sample primitive graphics and sample of survey responses.

8. Adjourn

Eric moved to adjourn at 11:30 AM EST, seconded by Brad.

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.