Minutes of Weekly Meeting, 2015-11-30

Meeting called to order: 11:06 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Brian Erickson
Michele Portolan
Brad Van Treuren
Peter Horwood
Heiko Ehrenberg
Tim Pender (joined 11:34)

By Proxy:
Adam Ley

Excused:
Carl Walker
Bill Eklow

2. Review and approve previous minutes:

  • 11/23/2015 minutes (updated draft circulated 11/23/2015).
    • No corrections noted.
    • Brian moved to approve, seconded by Eric, no objections or abstentions.

3. Review old action items

  • 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: Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.
  • All: Be ready with availability on other days, possibly nearby times. Ongoing.
  • All: Bring ideas for small, easily managed PAR scopes. COMPLETE

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172
  • The Newsletter was due at the end of July. Brad probably has one topic left on his list.
  • Try to get Al Crouch on call re 1687.1

5. Discussion Topics

  • Ian chose to deal with the subject of meeting scheduling first.

b. Schedule for future meetings.

  • The reason for considering an alternative day was to offer Adam and perhaps Bill a better opportunity to join the calls.
  • Ian assumed that the present meeting time was the only one reasonably satisfactory given the range of time zones involved. Those present gave their availability on alternative days as:
    • Ian: Any day except Friday
    • Eric: Any day except Thursday
    • Peter: Any day except Friday
    • Brad: Only Wednesday
    • Heiko: Only Wednesday
    • Michele: Only Wednesday
    • Brian: Only Wednesday
    • Tim (email): Any day
    • Adam (email): Wednesday (at the same time) is OK
  • Wednesday looks like a reasonably viable option, pending responses from those not on the call: Adam, Bill, Tim, Carl. Those people may respond by email.
  • Heiko noted that moving the SJTAG call to Wednesday would allow him to join the 1149.10 meeting as that also interests him.
  • Even if agreed, Ian suggested that the change would not take place until after the year end.

a. Proposal for deadline for entry into PAR.

  • Ian had been in touch with Bill who wasn't able to join the call until the 14th, but had provided some suggestions for the discussion:
    • My first piece of advice would be to focus on the PAR.  In this case, you won¹t need to get into detailed, technical conversations.  If Adam Ley is in the meeting he can help direct the discussion with respect to the PAR.
    • The PAR is supposed to be a high level proposal and absolutely should not get into technical details.  I believe you have a template from quite a while back.  If you can't find one, I should be able to send you our 1149.6 PAR. 
    • Try to keep the language and discussion the same as is in the PAR.  I would advocate that until you get a PAR, you should not have any technical discussions regarding the outcome.  The PAR is mostly to suggest the viability of the proposal - whether this should become a standard.
  • Ian: I'm not too sure what Bill meant by "not having any technical discussions regarding the outcome".
  • Eric: I think he means we should stop doing what we've been doing!
  • Eric: Form memory, I think we started going through a good deal of the PAR then came across a couple of definitions we needed and then dived into the technical side of things.
  • Brad: That sounds right.
  • Eric: I think we had an honest intention to park the PAR discussion only while we looked at those definitions and then pick it up again.
  • Eric: I think Bill intends that we shouldn't dive into the technical detail, and the PAR itself shouldn't be too technical.
  • Ian: Mainly what the PAR records is the "Scope" and "Purpose".
  • Heiko: By keeping the PAR not too technical, it doesn't then lock you in to a particular solution.
  • Eric: I think we need to bring up the old documents we had on the PAR.
  • Ian: I agree, but I don't think I can manage that in time to be useful for this meeting. I'll get a pointer to the previous discussions and any additional material we were using {ACTION}.
  • Ian: I think we all agreed that SJTAG was too big a subject to fit in a single standard and I came up a notional breakdown at one point.  That wasn't a fixed view and it was just for discussion of how a hierarchy might look. What general direction do you think we need to be considering for a first PAR?
  • Brad: I saw something that you'd written where you proposed looking at hardware as the software aspects were complex.
  • Ian: Yes, that was in last week's notes.  The reason I'm thinking of that is because of the way I first got involved with SJTAG: This may not be PAR material, but I was seeing boards being designed with ASPs and ScanBridges and with a notion that they'd help make the system reprogrammable, but the practice was proving more difficult because there wasn't any "joined up thinking" on how everything should work together.  So I came looking for some kind of best practice guidance.
  • Brad. I came into it in a similar way.  SJTAG is an easier sell to the hardware guys and the software side can be done later.
  • Brad: Leverage the re-use we can achieve: There's a lot of e-documents on the web on best practices for the manufacturing side, not so much for the system.
  • Ian: Yes that's where we were - the designs were good for manufacturing test and board diagnostics but not really usable in the system.  But as I say that might not be a PAR subject.  
  • Brad: I can see on one hand how that might be useful but it may be better in a common best practice guide.  Something like I wrote for µTCA was easier because we knew the interface was 3.3V; why you need these signals, what they should look like.  It's simpler than a standards document for SJTAG.
  • Peter: You have to have hardware understand the benefit when software comes along otherwise they could say "I could do that with a couple of jumpers". They're often looking at the raw component cost and don't see the whole lifecycle.
  • Ian: That's probably true Peter. I think my organisation is probably quite alert to the through life cost aspect, but many designer's are probably driven by the unit production cost of the individual board.
  • Peter: SVF, and maybe STAPL, are still the only "portable" formats for tests.  Tool vendors might like you to use multiple TAPs because then tests are harder to export.  So there are reason to promote portability and reasons why some people might resist it.
  • Brad: There are always trade-offs and justifications for those trade-offs.  There are more possibilities for trade-offs as you go up the system hierarchy, and no two companies will have the same priorities.
  • Ian: Or even between business units within the same company.
  • Brad: I thought we were looking at a progression of "dot releases" of the hardware specification, just like 1687; a generalised perspective and then specific elements, such as I2C, addressed by a "dot" standard.
  • Michele: Are we thinking there would be a description like ICL?
  • Brad: I'm thinking more like the original 1149.1 which didn't have BSDL - it just looked at the signals, the cells, etc.  BSDL came along later.  1581 is doing something similar, the description is coming along in a "dot release".  It's a model that seems to have worked in the past.
  • Ian: I think that's as much as we can usefully address today.
  • Adam, by email: It looks like your discussion made some progress towards a PAR! I see the next steps as:
    1. commit that the PAR is first and top priority
    2. define the Purpose (essentially the “Why we need the(se) standard(s)?”) as broadly as possible and with full consensus
    3. define the Scope (essentially the “What is THIS standard?”) such that it’s fully congruent with the purpose and is achievable within a time certain given a certain effort

c. What are the alternatives to PDL and ICL that could carry preclusion descriptions?

  • Not discussed.

d. How does an instrument know its own instance?

  • Not discussed.

6. Topic for next meeting

  • Re-familiarise with previous PAR discussion.
  • What are the alternatives to PDL and ICL that could carry preclusion descriptions?
  • How does an instrument know its own instance?

7. Key Takeaway for today's meeting

  • None.

8. Glossary terms from this meeting

  • None.
    • 'Instance' (or a more specific version of the term) may require definition in future.

9. Schedule next meeting

  • December 7.
  • December schedule:
    • 7, 14, 21.
    • Brad is not available 7, 21; Eric is not available 21.

10. Any other business

  • None.

11. Review new action items

  • Ian: Locate and circulate PAR material from earlier this year.
  • (Ian may try to distil concise glossary definitions from the previous discussions).

12. Adjourn

  • Eric moved to adjourn seconded by Peter. Meeting adjourned at 11:51 AM EST.

Respectfully submitted,
Ian McIntosh