Minutes of Weekly Meeting, 2011-06-27

Meeting called to order: 11:03 AM EDT

1. Roll Call

Ian McIntosh
Brad Van Treuren (left 11:29)
Eric Cormack
Patrick Au
Tim Pender
Heiko Ehrenberg
Adam Ley

Excused:
Brian Erickson
Harrison Miles
Carl Walker

2. Review and approve previous minutes:

06/20/2011 minutes:

  • Updated draft circulated on 06/23/2011.
  • No corrections noted.
  • Eric moved to approve, seconded by Patrick, 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?
  • 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: Condense gateway comments and queries into a concise set of questions. - Ongoing
  • All: Forward text file to Ian containing keywords from review of meeting minutes. - Ongoing.
  • Carl/Brad: Get annotated keyword worksheets to Ian by Wednesday Close of Business. - Ongoing
  • All: Consider how a keyword can be used to define the chain configuration for a given test step, and what that keyword might be.

4. Discussion Topics

  1. Explore communication between a pair of devices
    - Avoid the problems of hierarchy for now
    • [Ian] Last week, Harrison suggested looking at communication between devices. I have to admit that I didn't quite follow what really being suggested, as I was too busy just trying to keep up with note taking, but I think Brad got a much clearer idea.
    • [Brad] If we try to work on examples that are just one or two devices it may be easier to work out what the problems are and what the tooling issues might be. It similar to when we worked on the primitives - I thought that the team participated more then.
    • [Brad] Trying simple and small is better than jumping right into the deep with a complex, comprehensive system definition. My suggestion is that perhaps we start with scan path verification and interconnect test; What are the things we want to achieve in those use cases? What features do the devices involved in these use cases need to provide?
    • [Ian] That's what I was wondering - should we tackle this on a per Use Case basis?
    • [Brad] I think it should head that way. It'll help to flesh out our White Paper and give us something for our Volumes 3 and 4.
    • [Heiko] So the purpose of this discussion would be to define a simple system for which these use cases apply?
    • [Brad] Yes, starting with the most simple structure with no hierarchy and then building on top of that.
    • [Ian] How do we want to approach this discussion?
    • [Brad] Some drawings, building up a system from the most simple case.
    • [Heiko] So basically starting with a simple board?
    • [Brad] Even simpler than that - The most simplistic system possible, a single device, for example. I was taking the inspiration here from your group's 1581 demonstration.
    • [Brad] In a single device, we need the 4 or 5 wire TAP signals plus power and ground.
    • [Brad] The first diagram should cover the scan path verification, with the flow of TDI through TDO. What do we test? If the device has an IDCODE, we can read it and identify the device; if the device doesn’t have an IDCODE, the bypass register could be used to verify the scan path is essentially working.
    • [Brad] Then there could be more than one flavor of the device, for different vendors or different versions. So a system with one device still has a lot of issues.
    • [Heiko] You need a connector or some way to probe the TAP signals.
    • [Brad] That should be on the diagram, too.
    • [Ian] we can try using the whiteboard in Webex to capture these ideas.
    • [Brad] I thought you'd maybe have more tools in PowerPoint.
    • [Ian] PowerPoint can play up on my machine just now.
    • [Adam] The whiteboard allows everyone to add to it, not just the presenter.
    • {Ian started drawing a diagram on the Whiteboard, attached}
    • {Brad left}
    • The bulk of further discussion took place as group contributions to the diagram; the following are brief key notes:
      • TAP connector.
      • Assume IEEE 1149.1 compliant device, with or without ID Register.
      • Power to be supplied for the device.
      • If ID Register is present, multiple ID Codes must be supported (as vendors change or device versions change).
      • If UserCode is present, read it.
      • These steps verify TDO, TCK, and TMS.
      • UserCode is only readable if there is an Device Identification Register and it contains a device IDCODE.
      • To verify TDI, one can scan additional bits ("overscan") to see pattern shifted in to TDI to come out on TDO.
      • An Instruction of all 1s is no longer a preferred opcode for EXTEST although some devices still implement that.
  2. [Ian] The Whiteboard isn't very good for editing, but I can at least export a PDF from it, which I'll send out with the draft minutes {ACTION}
  3. To be continued...

5. Key Takeaway for today's meeting

  • [Eric] Keep things simple, at least to start with.

6. Schedule next meeting

Next Meeting: July 11th (11:00 AM EDT, 4:00 PM BST)
There will be no meeting on July 4th.

Schedule for July 2011:
11th, 18th, 25th.

7. Any other business

None.

8. Review new action items

  • Ian - Circulate Whiteboard diagram from today's meeting to the group.

9. Adjourn

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

Thanks to Heiko for supplying additional notes.

Respectfully submitted,
Ian McIntosh