Minutes of Weekly Meeting, 2011-07-25

Meeting called to order: 11:11 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Carl Walker
Heiko Ehrenberg
Brad Van Treuren
Harrison Miles (joined 11:17)

Excused:
Adam Ley
Patrick Au
Brian Erickson
Tim Pender

2. Review and approve previous minutes:

18/07/2011 minutes:

  • Draft circulated on 19/07/2011.
  • One correction: Change 'Whne' to 'When' in the 5th item of Harrison's list of categories.
  • Brad moved to approve with the above correction, seconded by Eric, 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
    - Continue simple diagram development
    - Expand interconnect test diagram and description
    • [Ian] Last week we had something of a digression from where I thought we were going to be headed, although it a useful digression. What I had expected was that, like the scan path verification case, we would start to build up the steps need for a working interconnect test.
    • [Brad] That seems like it would be useful.
    • {Harrison joined}
    • [Ian] I'll try to share the diagram from last week.
    • {PowerPoint slides shared}
    • [Ian] We added in the assumptions we made, so now we can add notes on a fairly high level description of what and interconnect test does.
    • [Harrison] Maybe the better approach would be to get all the intrinsic stages defined first; the stages that you need for a boundary scan test.
    • [Harrison] I think of those categories we talked about as 'containers' and each container may require specific stages. A board is a 'vessel' and what's inside are the containers.
    • [Harrison] If we can agree those stages here, where have a pretty good representation of the industry, then we effectively have buy-in from the industry.
    • [Ian] OK, but I guess I'm not seeing why that's key just now. I think what we have here is just the classic 1990s interconnect scenario. We were starting very simple.
    • [Harrison] OK, I wasn't being clear. I was thinking about a bus test, where additional constraints might be applied.
    • [Brad] I think it's important that we concentrate on 'Container 1', the basic combinatorial logic, first. We may find a lot of overlap as we go through things, but the idea was to simplify the discussion to begin with.
    • [Ian] Yes, we've got ourselves caught up in solving specific problems before and possibly missing the bigger picture.
    • [Brad] It may be important to emphasise that this a point-to-point test, looking at continuity, opens, shorts, stuck-at-1 and stuck-at-0. It is a structural test.
    • [Ian] Last week we asked if it was important to comment that the test wasn't instantaneous. I dismissed it then but I now question wonder if it might be more important to note.
    • [Harrison] What do you mean by it not being instantaneous?
    • [Ian] In that IC1 has to update its outputs before IC2 can capture its inputs.
    • [Harrison] Ah! That wasn't possible back then. There are what you might call 'temporal components' in the devices.
    • [Brad] Its the state machine for the TAP - In the DR scan you go through Capture-DR before you get to Update-DR.
    • [Brad] Another thing that might be worth noting is that we can have only one driver on a net but there may be multiple observers.
    • [Brad] Another thing that used to cause problems was a shared Output Enable cell with a single control cell for multiple pins, which limited what drivers you could use.
    • [Brad] Do we want to get into the patterns of 1s and 0s that need to be applied to provide the diagnostics?
    • [Ian] I think that may be getting too much into the implementation detail.
    • [Harrison] Back to the previous point, that's maybe implied; I don't know that it's too important to note here. It's something of a 'period piece.'
    • [Brad] Yes, but it's just that it's something that the tooling companies struggled with early on.
    • [Harrison] It's maybe out of context. It was more to do with the lack of appropriate design rules, and it can still be a problem today because those design rules are absent.
    • [Brad] This was constraint on which drivers you could use.
    • [Harrison] I still consider it a period piece. It's a problem that is being removed from devices.
    • [Brad] A lot of processors still have that architecture. Maybe that line should be indented to show that it is commentary on the preceding line.
    • [Brad] So we wanted IC1 to be the case of the driver and IC2 to be the case of the receive?
    • [Ian] Yes. Are we maybe getting to where we need expand using a new diagram?
    • {Copy of Interconnect slide created}
    • [Ian] Do we want to start changing the directionality of some of these signals now?
    • [Brad] I don't know that we need to do that just yet, for the bus test.
    • [Harrison] What we need are the intrinsic properties - who can drive and when. There is more than one device that can potentially drive, so now we have some idea of constraints. We need to know more about the devices, and this is where the BSDLs become more important, so that we can create a test that will not cause damage.
    • [Brad] For the situation drawn, a Wagner or walking/counting test is sufficient. A bus test still uses the same vector algorithms but has to be smarter to walk the driver round all the possible drivers.
    • [Ian] I think we're on the verge of another rush of comments but I'm aware of the time, so I think we need to continue this next week.

5. Key Takeaway for today's meeting

  • [Brad] Driver control adds to the complexity of interconnect tests on bus structures.

6. Schedule next meeting

Next Meeting:
August 1st (11:00 AM EDT, 4:00 PM BST)

Schedule for August 2011:
1, 8, 15, 22, 29.
Ian will miss 8th,
Heiko will miss 29th,
Brad's availability on Mondays is uncertain.

7. Any other business

None.

8. Review new action items

None.

9. Adjourn

Eric moved to adjourn at 11:58 AM EDT, seconded by Brad.

Respectfully submitted,
Ian McIntosh