Minutes of Weekly Meeting, 2016-01-13

Meeting called to order: 11:09 AM EST

1. Roll Call

Ian McIntosh
Carl Walker
Heiko Ehrenberg
Tim Pender
Adam Ley
Michele Portolan
Peter Horwood (joined 11:13)
Bill Eklow (joined 11:32)

By Proxy:

Eric Cormack
Brian Erickson

2. Review and approve previous minutes:

  • 01/06/2016 minutes (draft circulated 01/06/2016).
    • No corrections noted.
    • Heiko moved to approve, seconded by Carl, 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 - For ETS2, propose possible example SJTAG applications with associated problems that are commonly encountered. Ongoing.
  • All - Post thoughts on what things ought to be addressed by our initial PAR, either to the forum thread (http://forums.sjtag.org/viewtopic.php?f=3&t=740) or by email to the group. Ongoing.

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 - Possibly no longer relevant?

5. Discussion Topics

a. VTS.

  • {Peter joined}
  • Bill Eklow offered us an invited talk slot at VTS; Michele said he would be there and offered himself as presenter.
  • Ian suggested that since this is an invited address and Michele volunteered to represent SJTAG, we should leave it up to him to decide on a topic, but would be happy if Michele chose to include his iJTAG Engine in some way.
  • Michele felt it would be important that SJTAG is the focus of the talk, but that the engine could be presented as an example of a way forward.
  • Michele will ask Bill what session we would be in and then Michele will propose a presentation to this group for review / discussion.

b. ETS2.

  • Ian had created a forum topic for this but there had been no follow up during the past week (http://forums.sjtag.org/viewtopic.php?f=3&t=744).
  • Submission of the abstract (only) is due by the end of this month.  Michele proposed setting aside 50% of the time for discussion, although the time allocated was not known. Michele will enquire.
  • Ian had previously suggested in-field programming as an example use case, but also noted that trying to terminate JTAG signals to suit both board level and system level (multidrop) scenarios can be challenging. Ian had hoped that some other suggestions would be forthcoming.
  • Need to set time aside in next week's call to get a draft abstract put together. Ian will try to prepare a very rough draft as something talk round next week.
  • Carry-over action item for everyone to think about topics / questions for our ETS presentation {continued ACTION}.

c. Close in on PAR scope and purpose.

  • Ian reviewed forum posts on this topic (http://forums.sjtag.org/viewtopic.php?f=3&t=740). He had hoped to collate the bullet points onto a single slide but had not had time before the meeting.
  • We seem to be honing in on hardware for an initial specification. Michele asked if we should not also consider at least a hardware description and noted that under 'hardware' we could be looking at electrical aspects or architectural aspects.
  • Peter commented that vectors could be delivered by any interface and then distributed using the 4/5 wire bus, but maybe you don't want to have a gateway on every board.
  • Michele felt we also had the question of "what is a system?"; Did this include System on Chip, because it is very similar? Peter noted that SoC was different because it would be heavily tested and debugged before being added to the design, unlike the selection of devices that are aggregated in a traditional design; it is a known entity with known test vectors. Michele responded that IP may have built in DFT and features that the IP licensor may not want to reveal. Ian noted that this was almost identical to the case of integrating COTS boards into a system design.
  • Ian felt that both SoC and COTS boards were important aspects, but niche cases, possibly "dot extensions" rather than part of the core standard. 
  • Adam made the point (on the forum) that the PURPOSE is no longer required on the PAR form, and if omitted does not appear in the standard. Additionally, the PURPOSE can be more general ("the big picture") and the SCOPE should narrowly define what we want to define in this particular specification.
  • {Bill joined}
  • Adam felt that we may be looking at 'SJTAG.1' - the first in a family of related standards but not necessarily one that "fathers" all the others; the first in a line of "children". That first issue does not then need to anticipate all the others.
  • Ian agreed and noted that the need to break away from trying to identify all the future paths was commented on late in 2015, but Ian hadn't made the connection at that time that this implied a dot1 "child" standard.
  • Adam remarked that 1149 was set aside as a family of testability standards and that was congruent with our circumstances where we don't have a specific family tree in mind.
  • While 'hardware' seemed to be our preferred focus, we would still need to narrow down what that means. Ian felt that elecrtrical specification, such as signal levels, was too detailed and too much of an application specific area to be useful, and thought that architecture might be more valuable.
  • Bill considered that being an extension to 1149 might make the PAR a little easier and wondered if there were anything that makes it hard to use the 1149.1 bus.  Ian replied that it was mainly down to acknowledgement that other buses could be used, something like 1687 limiting themselves to 1149.1 initially but now looking at other serial buses. Bill noted that there were now several examples of people figuring out how to exploit different protocols and fit them into the 1687 architecture.
  • Start with more simple architectures and then have people add features. Give 'the consumer' a way to add in features without compromising the base standard.
  • Michele felt that 1687 was too much of a closed field and that SJTAG needs to be more open.
  • Given that some people have still to respond to the forum thread, and the discussion has moved on a little, Ian will keep the thread open and continue the action until next week {continued ACTION}.

6. Topic for next meeting

  • ETS2 draft abstract.
  • Close in on PAR scope and purpose (continued).

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

  • Next meeting January 20, 2016, 11:00 AM EST.
    • Heiko and Michele anticipate being absent.
  • January schedule:
    •  20, 27.

10. Any other business

  • None.

11. Review new action items

  • No new actions: The two actions from last week are continued.

12. Adjourn

  • Bill moved to adjourn seconded by Tim. Meeting adjourned at 11:59 AM EST.

Thanks to Heiko for providing additional notes.

Respectfully submitted,
Ian McIntosh