Minutes of Weekly Meeting, 2015-12-07

Meeting called to order: 11:08 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Brian Erickson
Carl Walker
Heiko Ehrenberg
Tim Pender

By Proxy:

Adam Ley
Michele Portolan
Brad Van Treuren
Peter Horwood
Bill Eklow

2. Review and approve previous minutes:

  • 11/30/2015 minutes (updated draft circulated 12/03/2015).
    • No corrections noted.
    • Eric moved to approve, seconded by Heiko, 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. COMPLETE.
  • Ian: Locate and circulate PAR material from earlier this year. 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

a. ETS2.

  • The potential for an ETS2 presence had been raised in email by Adam
  • Ian noted that wasn't as pressing as he had thought since the submission deadline is actually in January for the ETS2 track. He also felt that proper discussion probably needed Michele to be on the call as he was most likely the person who would need to present the topic.
  • Adam had pointed out that the invitation encouraged presentation of problems for which there was not yet a solution.  Ian thought this might be a useful tack for SJTAG, as presenting the broad scale of the problem space may allow us to bring awareness to people who may not yet have considered the potential impact. That could help us grow membership to staff the "dots".
  • Heiko added that if it was similar to the last BTW session then it would just be presenting the problem and a lot of discussion will follow.
  • The group generally agreed with this approach.

b. Re-familiarise with previous PAR discussion.

  • Ian had circulated the link to the earlier PAR discussions from April 20, 2015 and associated material (http://www.sjtag.org/index.php/minutes/weekly-minutes-2015/364-meeting-minutes-2015-04-20).
  • Ian: I think we also need to take into account Adam's emailed comments:
  • Adam, by email: 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 certain time given a certain effort
  • Ian: The last two are the ones that will take some discussion.  The first just means we need to set aside everything else.
  • Brian: I second that motion.
  • {April 20 notes shared}
  • No-one in the group had re-read these notes recently.
  • Ian: I note I questioned whether we were trying to address all testing of a system or just the JTAG aspect of it.
  • Eric: We're not really test the JTAG are we, we're just using it to gain access.  When we consider things like stacked die, etc. we need to be careful about the scope.
  • One of the debates with 1687 was whether the standard was trying address something that was outside the scope of the PAR. I think it's OK for a standard to not address the full scope of its PAR but exceeding that scope isn't allowed.  So it's maybe OK to be a little bit vague or open on where your boundaries are.
  • Eric: We don't need something that's all-singing, all-dancing to begin with, it can be very basic; we don't want to look at all the branches, just a basic PAR and then deal with other things as extensions.
  • Ian: I see there's two ways to approach this: Either you go in semi-blind and hope your core standard extends well, or you try to work out all the hooks from the branches in advance.  Doing the latter is where we disappear down the rabbit holes.
  • Eric: Would it be wrong to propose a very basic hardware PAR with bare minimum software, maybe just saying we'll use ICL, PDL, or whatever existing languages there are?
  • Ian: I think if we consider the original 1149.1 then it didn't broach software at all.  BSDL came in later as an appendix, although I suppose it could have been a "dot extension".
  • Eric: I think that would help us with a PAR.
  • Ian: Getting a PAR approved sets a timescale for preparing the standard.  As Adam's remarks allude, that means you need to have a scope or objective that you can reasonably complete within that timescale.
  • Eric: Yes.  Now, how does that help us with ETS2?
  • Ian: I don't think it does. I think ETS2 needs to show the broader scope so people can see more of what SJTAG touches. That might attract some people with the kind of interest in software that Brad and Michele have and longer term we probably need a "software team". No disrespect to anyone in the group but I feel many of us aren't comfortable with that domain. There may be other specialist areas, like 3D, that might want to bring their own perspectives too.
  • {April 27 notes shared}
  • Ian: We also started to look at TAP signals; the pull-ups and pull-downs, and TRST use or misuse.
  • Ian: I guess this was the angle I was coming from a couple of weeks ago. If you're designing a system what do you need to have considered to make everything work? If you have TCK well terminated at the board edge to suit board level test, then if several such boards are plugged into a multidrop backplane then the signal will be over-terminated. Brad felt that kind of thing was better in a "best practice guide" and he may be right.
  • Eric: We can provide recommendations, but people don't need to follow them.
  • Ian: That's almost always the case; you can choose to conform to a standard or not.
  • Brian: One thing that's often not addressed is "why?" - "Why should I do it this way?"  I think if designers can see the explanations in a best practice guide then they're more likely to adopt the recommendations.
  • Ian: I've often seen questions asking why the TAP pulls are the way they are, and TRST is often misunderstood because the pull direction is different, has a different purpose, depending on whether you're considering the device in isolation or as part of a board. I've had questions about "what's wrong with just daisy-chaining all my boards?" so some very basic things can need explained.
  • Ian: We also discussed netlist formats. I'm inclined to say that something that should be left to the tools to handle.
  • Brian: As soon as pick a netlist format you'll get comments that "this format is better than that format". It also needs to be able to change: At one time a simple netlist would suffice but with testers that combine flying probe with JTAG you also need board level layout information.
  • Ian: Agreed. It wasn't so long ago there wasn't and ODB++ at all. Picking a format locks you into a particular point in time.
  • Ian: TCK rate was another topic. Maybe Heiko can remember why this came up, perhaps being defined by the board rather than the devices in the chains?
  • Heiko: I'm not sure I recall; that might factored in to it.
  • Ian: I know we often have boards where the maximum usable TCK is considerably lower than the slowest TCK declared by the BSDLs.  Maybe this points back to the need for a board level BSDL equivalent.
  • Ian: Other topics touching on power domains and numbers of simultaneously switchable cells are maybe similar, in needing a board level description.
  • Brian: The switching could also be something that changes: FPGAs used to have limitations due to internal ground bounce, but now they're fairly immune to that, so I wouldn't want that specified in the standard.
  • Ian: OK, but a board may still have limitations.  I wouldn't propose that the standard sets a maximum number of cells to switch simultaneously, but instead allows the board description to define what's permissible.
  • Brian: I think the main point that's coming out here is that we need a board level description that covers functionality and parametrics.
  • {May 4 notes shared}
  • Ian: At this point we're getting into rules for Access Links and Data Links - I think this where we started to get bogged down in definitions and detail. Probably nothing more we can usefully review.
  • Eric: I agree.

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

  • ETS2
  • Close in on PAR scope and purpose.

7. Key Takeaway for today's meeting

  • Need a board level description of functionality and parametrics.

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 14.
  • December schedule:
    • 14, 21.
    • Brad is not available 21; Eric is not available 21.

10. Any other business

  • None.

11. Review new action items

  • None
  • (Ian may try to distil concise glossary definitions from the previous discussions).

12. Adjourn

  • Eric moved to adjourn seconded by Tim. Meeting adjourned at 12:02 PM EST.

Respectfully submitted,
Ian McIntosh