Minutes of Weekly Meeting, 2012-01-16

Meeting called to order: 11:06 AM EST

1. Roll Call

Adam Ley
Eric Cormack
Patrick Au
Ian McIntosh
Brad Van Treuren
Richard Foster
Heiko Ehrenberg (joined 11:08)
Peter Horwood (joined 11:27)

Tim Pender

2. Review and approve previous minutes:

12/12/2011 minutes:

  • Draft circulated on 12/12/2011.
  • No corrections advised.
  • Insufficient attendees for approval.

01/09/2012 minutes:

  • Draft circulated on 01/10/2012.
  • Change 'ha' to 'has' near the top of section 4.
  • [???] to be replaced near bottom of section 4.
  • Insufficient attendees for approval.

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: 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

4. Discussion Topics

  1. Refresher on discussions from December 2011
    • [Ian] I wanted to briefly review the subjects we attempted to address at the end of last year.
    • {Heiko joined}
    • [Ian] At the December 5 meeting we tried to look at our primitives in the light of the forum thread we started on what we thought we wanted from an 'ideal' gateway. However, I don't think we really took anything much away from that.
    • [Ian] For December 12, partly on the back of an observation from Harrison in regard to P1687, we tried to look at how 'control' could be layered onto 'structure'. I was interested to see how P1687 went about that, or if there was any equivalence in 1149.7 that we could learn from. Unfortunately, that meeting didn't really have anyone with enough knowledge of P1687 on the call to really provide anything meaningful.
    • [Ian] I missed the December 19 meeting, but the aim there was to look at the languages that were identified during our 2009 survey and see which were related to 'control' and which addressed 'structure'. I think the conclusion was that most of the languages were about 'control' or flow, but perhaps Heiko can tell us more?
    • [Heiko] Well we noted that languages were either about control or structure; there wasn't really anything that did both.
    • [Heiko] But Tim raised an interesting idea that VHDL could be used to encapsulate a building block without exposing what is inside it.
    • {Peter joined}
  2. Extending the Primitives descriptions to address 2-wire topologies
    • [Ian] One thing that came out of a meeting in early December was a recognition that our primitives didn't address the 2-wire architectures.
    • [Peter] Yes, 2-wire should be included, but if you only run 2-wires then you won't be able to deal with things like the debug on some of the Intel parts that need more wires.
    • [Ian] OK. I know some of the Motorola/Freescale parts we've used have a BDM port that uses more than even the 4/5-wire interface.
    • [Ian] But that raises the question that I don't think we've fully resolved over whether we're looking to SJTAG to support current technologies or only future technologies. One of the things dot7 was intended to provide was a way to support debug.
    • [Brad] I remember seeing a presentation showing that 1149.7 can be a wrapper for external signals on top of 1149.1.
    • [Brad, post-meeting] The 1149.7 presentation I was referring to can be found at: http://btw.tttc-events.org/material/BTW06/BTW06%20Presentations/BTW2006-Swoboda.pdf - Slides 12 and 13 in particular.
    • [Adam] Yes, the 2-wire interface was specifically implemented with debug in mind, with enough signalling modes to avoid the need for sideband signals. It was one of the highly stated goals.
    • [Brad] I recall something of how an existing BDM could be folded into an 1149.1 TAP controller behind a dot7 interface.
    • [Adam] I'm the topic has come up several times before but it's worth repeating: Essentially dot7 is defined as an adaption layer to 1149.1 and signals that might be considered 'sideband'. Signals might be returned to the Debug and Test System but might follow something other than the dot1 architecture.
    • [Ian] OK, what I'm hearing is that the 2-wire descriptions are needed for completeness, but we shouldn't be assuming or mandating it's use.
    • [Peter] That allows customers to choose what suits their system.
    • [Ian] There are vast numbers of 4/5-wire devices in existence, and they're likely to remain around for a number of years yet.
    • [Brad] Ian, I think you're more likely to impacted by DSP changes: I think radars are quite similar to image processing.
    • [Ian] That's probably true. I guess some of images we get now are almost photo-like.
    • [Brad] We're going to be impacted by DSPs with 2-wire interfaces coming up.
    • [Ian] I don't know how long it will be before see any impact. Most likely it'll be driven by obsolescence of current parts.
    • [Brad] Yes, I was going to say that; no-one likes to change designs!
    • [Ian] That's true. We're looking towards reuse where possible.

5. Key Takeaway for today's meeting

  • [Brad] 1149.7 provides an adaption over 1149.1 that can include signals that would otherwise be considered 'sideband' to 1149.1 (e.g., "debug" signals such as EMU0, EMU1, HRST, SRST, etc.)
  • [Ian] Some technologies cannot be supported on a 2-wire interface.

6. Schedule next meeting

Next Meetings:
23rd January - Patrick will be absent.
30th January - Heiko may be absent.

7. Any other business

  • The Newsletter is scheduled to be issued at the end of January.
  • The reaffirmation of officers should be conducted in next few weeks.

8. Review new action items


9. Adjourn

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

Respectfully submitted,
Ian McIntosh