Minutes of Weekly Meeting, 2009-10-19

Meeting called to order at 10:38 AM EDT

1. Roll Call

Eric Cormack
Carl Walker
Brad Van Treuren
Brian Erickson
Ian McIntosh
Tim Pender
Heiko Ehrenberg
Adam Ley (joined 10:45)

Excused:
Patrick Au

2. Review and approve previous minutes:

10/12/2009 minutes:

  • Draft circulated on 12th October:
  • Four corrections noted:
    • Roll Call: Delete '(joined 10:37)' after Heiko's name
    • In 4a, change 'you should neer receive a faulty part' to 'you should never receive a faulty part'
    • In 4a, change 'Ecklow' to 'Eklow'
    • In 4b, change 'Oh, that for test' to 'Oh, that's for test'
  • Brad moved to approve with the above amendments, 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
  • Harrison: Virtual system exploiting Configuration/Tuning/Instrumentation and Root Cause Analysis/Failure Mode Analysis Use Cases. - Ongoing
  • Brad: Virtual system exploiting POST and BIST Use Cases. - Ongoing.
  • Ian: Virtual system exploiting Environmental Stress Test Use Cases. - Ongoing
  • All: Review draft survey form. Specifically consider where "tooltip" help may be required. - COMPLETE - See discussion topic 4b.
  • All: Review "tooltip" help, especially considering the placeholder items in section 7. - Ongoing - See discussion topic 4b.
  • Brad: Supply details of BTW paper on Fault Injection simulation - COMPLETE
  • Ian: Review use of the terms 'JTAG' and 'Boundary Scan' throughout the survey and add interpretation on use to survey landing page. - COMPLETE

4. Discussion Topics

  1. 2009 Survey
    • [Ian] From last week's action, I went through the survey form and removed all the references to 'boundary scan', replacing it with 'JTAG' throughout. I also made sure that all 1149.1 references were in the same form, then updated the Landing Page with explanations. Heiko spotted some typo errors in the edits I made, which I've now fixed.
    • [Ian] Are there any further comments on the Landing Page?
    • [Tim] Can the 'Proceed to Survey' link be made bolder or turned into a button? It's not really obvious right now.
    • [Ian] I can do something with that. I may be able to make it a button.
    • [Ian] I had a thought that we needed a helper on question 7.5, and I thought of giving an example of a noncompliant operation, but now I think there are too many possible examples for that to make sense.
    • [Brad] That is the thought I was having.
    • [Ian] Is it even the case that this needs any help?
    • [Brad] As the author, I tried to word it so that it was restrictive in how you answered; that either you really wanted it to be dot 1 compliant or you didn't care.
    • [Tim] ASPs - they're not 1149.1 compliant?
    • [Brad] They are scanning in stable states - I'd say compatible, but not compliant.
    • [Tim] So, compliant is like the TI linker?
    • [Brad] Something like the ScanBridges. But then you have link bits and resynchronization bits.
    • [Tim] I don't care as long as it's transparent!
    • [Brad] Architectures using ASPs can have an advantage in that at the system level you can have the same chain topology available as you do at the board level.
    • [Brad] These are the kinds of thing we need to bring out in Volume 3.
    • [Tim] What about the newer TI gateways?
    • [Brad] The LASPs? They have an extended ASP protocol, so they're similar to the ASP and compatible on the same multidrop backplane.
    • [Ian] OK, I'm hearing that we don't need help on question 7.5. Can we drop help from question 7.6 too?
    • [Brad] For 7.6 it may be worth giving an example of what gets inserted: There are two points of insertion, and these make modelling hard for the tooling.
    • [Ian] OK, can we come up with some wording here?
    • [Brad] I'll try to write something up offline and send it to you, then you can 'wordsmith' it! {ACTION}
    • [Ian] That was the last thing I had any issue with. How does everyone else feel the survey reads? Any questions or answers that need improved?
    • {Silence}
    • [Eric] I think that means it's just about ready to 'rock and roll'.
    • [Ian] Yeah, if we sort out the help for 7.6 then we're ready to publish.
  2. White Paper Review - Volume 3
    • [Ian] It's some time since we looked at Volume 3. The last would be early this year when Harrison reviewed this with Carl and proposed some additions in respect of 'small form factors'; I wasn't sure where that was headed, though.
    • [Carl] Yeah, that's right. It's been a long time, so it's difficult to reconstruct the thoughts. We were just trying to describe the merits of the different interconnection schemes without trying to be restrictive, but as we went through that, I wasn't real happy about the way it was turning out. I think Carl Nielsen felt the same way.
    • [Ian] I remember I had the feeling that there were too many headings. There's a whole Glossary/Abbreviations section that we can move out into the 'global' glossary; I'm happy enough to do that.
    • [Carl] That would help clean things up a bit.
    • [Ian] Looking again maybe there aren't too many sections, just wrong ones. I don't think I like 'Rules' at this stage.
    • [Brad] The patterning in here looks like it was following after P1687, where they were drafting out rules.
    • [Carl] That is the case.
    • [Ian] Maybe like the Use Cases we should have Benefits and Consequences?
    • [Brad] A similar structure to Use Cases maps out quite well, I think: The Description, Value Proposition, and Consequences. The schemes are alternates so we don't need Alternative Techniques.
    • [Brad] Maybe we should say where each can be used, e.g. board-to-board, parent-to-mezzanine, backplane-to-board. There's the potential that we might want to allow for IEEE 1500 or later P1687.
    • [Brad] Right now I'm unsure how we map out the flow.
    • [Ian] I'm wary about simply reusing diagrams from five years ago without taking time to think about them. A while back, I reworked the XBST-EBST diagram to show a third, intermediate case because I felt the two-case version was inadequate.
    • [Ian] I wonder if Embedded and External are different enough that they should really be treated seprately?
    • [Carl] That is something I was wondering about, too.
    • [Brad] There will be some overlap; that's what Ben and I found when we discussed this: What resides in the Test Controller, what resides in the Test Manager.
    • [Brad] Maybe what we need to do is to look at the architectural elements; there will be delineations that become apparent. Then put the document in terms of those architectural elements.
    • [Brad] It's a bit like that diagram we have in the survey, although that's similar to an ISO stack showing the software interfaces. Here we'll have a hierarchy of control.
    • [Brad] What we have here right now is the basis for the description sections.
    • [Brad] The actions items that we had, and Harrison too, might come in here. It may not be a bad idea to do a walk-through with a virtual system to show the reader what we mean. It would be a natural follow on from Volume 2.
    • [Ian] That makes sense.
    • [Brad] Then we can see what the common elements are in the virtual systems.
    • [Brad] We learned a lot from Volume 2. We can now look at Volume 3 in light of those insights, and I feel more comfortable with that now.
    • [Carl] Maybe we need a higher level look at this.
    • [Brad] The content is there. It's good material, we just have get it in a form that people can take it in.
    • [Ian] That's why I wanted to have a quick look at the Contents: We're probably dropping in too soon onto the detail, without explaining what's driving those schemes.
    • [Brad] The virtual systems only need to be block diagrams. Black boxes for gateways, etc., without trying to describe them in detail.
    • [Ian] Do you think a single virtual system will do?
    • [Brad] I envisioned one system example for each Use Case. Clearly, in the case of POST what you can do external is very different from embedded.
    • [Ian] That sounds like a lot of work.
    • [Brad] Well, you didn't expect it to be easy!
    • [Brad] Maybe we want virtual systems we can take through two of the Use Cases to begin with, then we should get a feel for the task, how much black box detail is necessary to fulfill the need.
    • [Ian] Should we be picking the two 'big hitter' Use Cases? To my mind that would be Structural Test and Programming/Updates.
    • [Brad] Yes, but there's overlap. Your EST case will overlap with Structural Test, as will POST.
    • [Ian] So we should continue with the subjects of the old actions?
    • [Brad] I think you and I should continue this offline, maybe on the forums.
    • [Ian] OK. There's a heading already there for Volume 3. {ACTION}
    • [Brad] I'd like to know if the rest of the team agree with this plan.
    • [Carl] I think it's a reasonable approach.
    • [Brad] Will it address what the reader needs to get out of it. What about the tool vendors - this might determine what support the tooling will need to provide for SJTAG?
    • [Heiko] I don't really have a better suggestion.
    • [Tim] What about signal integrity, pull-ups, etc.? Should that be in this volume?
    • [Ian] It probably should. It does no harm to remind people about proper termination and so on. The JTAG side of things is often an afterthought once all the functional design aspects are in place.
    • [Carl] Perhaps each section could have Hazards and Recommendations.
    • [Brad] Fanout is another thing.
    • [Tim] Multiple pull-ups: You put a 10k pull-up on a board, but if you have several boards in a multidrop that 10k could become 1k. Or pull-ups on the board and pull-downs on the backplane, etc.
    • [Ian] OK, we're not going to make much more progress until we have the virtual systems to talk round.

5. Schedule next meeting

Schedule for October 2009:
Monday October 26, 2009, 10:30 AM EDT (2:30 PM GMT)

Schedule for November 2009:
Monday November 2, 2009, 10:30 AM EST
Monday November 9, 2009, 10:30 AM EST
Monday November 16, 2009, 10:30 AM EST
Monday November 23, 2009, 10:30 AM EST
Monday November 30, 2009, 10:30 AM EST
  • [Brad] I see conflict on 9th; I have another meeting that could take most of the day.
  • [Tim] I probably won't make 23rd, as that's Thanksgiving week.

6. Any other business

  • [Ian] I circulated a copy of the progress report I supplied to Rohit.

7. Review new action items

  • Brad: Supply draft wording for pop-up help for Question 7.6
  • Ian/Brad: Prepare 'virtual systems' to support walk-through of two Use Cases.

8. Adjourn

Eric moved to adjourn at 11:39 AM EDT, seconded by Tim.

Respectfully submitted,
Ian McIntosh