[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2011-08-01

Meeting called to order: 11:08 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Carl Walker
Adam Ley
Heiko Ehrenberg
Brian Erickson
Brad Van Treuren
Tim Pender (joined 11:15)
Harrison Miles (joined 11:15)

Excused:
Peter Horwood
Richard Foster

2. Review and approve previous minutes:

25/07/2011 minutes:

  • Draft circulated on 25/07/2011.
  • No corrections noted.
  • Eric moved to approve, seconded by Carl, 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] We'd got to the point of starting to consider bus structures just we were concluding last time. I sketched out a couple of things that we can maybe talk round today. I'm not sure how much more we can get out of the interconnect test use case, but I'll let the flow of the meeting decide that.
    • {Shared PowerPoint slides}
    • [Ian] I added two new slides to what we developed last week. One was to illustrate a simple bus, something that Harrison brought up, the other was to show a simple cluster test, with some non-scannable logic inserted between the scannable parts.
    • [Adam] Ian, I don't really understand the 3rd assumption here.
    • [Ian] Sorry, the text is legacy from the earlier interconnect slide I based this on; I haven't edited the text at all so it's still referring to the simple case where we had a fixed driver and a fixed observer.
    • [Ian] OK, so taking the bus construct, what additional attributes does this imply?
    • {Tim and Harrison joined}
    • [Harrison] Well, you have to deal with directionality now.
    • [Ian] I guess it's also worth saying that in many cases you may have bus transceivers taking IC1 or IC2 onto the bus; you then have additional direction and enable pins to control.
    • [Harrison] I think I'd be inclined to treat that as a kind of variation on the theme.
    • [Harrison] You have the notion of constraints, the notion of directionality. I think that covers the variations on a theme. Oh, and the notion of transparency: Directionality, Constraints and Transparency.
    • [Ian] Not a constraint, more a requirement, is to ensure that you exercise all the drivers on each bussed net.
    • [Harrison] Yes.
    • [Ian] OK, looking at the cluster, I suppose the first thing here is that you need to have some knowledge of the behaviour of IC3 to be able to construct a test.
    • [Harrison] You have the whole notion of a priori knowledge. For the devices that support BScan you get that from the BSDL, for devices that don't support BScan you need the human input. I think that 'transparency' and 'constraints' are still applicable here.
    • [Tim] Timing will come into this due to the changed propagation delay.
    • [Harrison] I see timing as maybe being kind of orthogonal here?
    • [Tim] There will be an increase in the propagation delay; that could affect the maximum TCK that you can achieve.
    • [Harrison] OK, maybe we can use the broader term 'latency' here. Everything take time in some way.
    • [Tim] OK. Ian, in any of your diagrams, did you show any passives, or was it just the active devices like IC3?
    • [Ian] I haven't considered passives up until now.
    • [Harrison] The question is how important are passives compared to active parts?
    • [Tim] You still need to have some model of the passives.
    • [Harrison] They're different: I guess there's no sense of directionality with passives.
    • [Tim] There are differences but also similarities.
    • [Harrison] Directionality is the only thing different.
    • [Tim] Could you show the passive on the diagram?
    • {Diagram edited}
    • [Ian] Does that capture it?
    • [Tim] Yes.
    • [Ian] OK, I've run out of any prepared material, is there anything related to interconnect test that we haven't touched on yet?
    • [Harrison] I'm trying to think...
    • [Ian] Is dot6 worth a mention here?
    • [Carl] It needs to be addressed somewhere. We've got the vendors with differing opinions of what the signal on the wire looks like.
    • [Harrison] Attributively, we have different BScan cells with dot6. And although it's been around for about 8 years, we've less than 5 years experience.
    • [Brad] Clearly, dot6 comes into a different, additional use case?
    • [Ian] Possibly. It's certainly not the traditional 1990's interconnect that we started talking about.
    • [Brad] There's a different protocol behind it. What you can have is the 1994 era differential lines that can be supported in dot1.
    • [Harrison] Are there other things that can be added to the list? SERDES is probably one.
    • [Tim] You can have some of the SERDES types of link that can be tested by dot1 if you have additional discrete transmitters and receivers between IC1 and IC2: You can have LVDS between the transmitter and receiver and TTL from IC1 to the transmitter and from the receiver to the IC2.
    • [Ian] Yes that works, but the downside is a loss of diagnostics.
    • [Harrison] Yes, that's where you're going with that.
    • [Harrison] In my mind it becomes a two-stage boundary scan; the dot1 and then the dot6. It becomes a unique use case as cells have additional attributes; extra steps can be inserted to recover some of the coverage.
    • [Ian] I can draw up the scheme that Tim described to go in here, but I think I'd need to do that off-line.
    • [Tim] I think it'd be better to keep all the SERDES stuff together.
    • [Harrison] Yes, it's more of a continuum.
    • [Brad] There are a couple more cases: A differential pair that is driven by a single scan cell, and a pair that has individual cells on the P and N. Then you get the hybrid where a link has a single cell at one end and a pair at the other end.
    • [Tim] That maybe brings in the case where a FPGA might need to be configured for a test.
    • [Harrison] That's where FPGAs get interesting! FPGAs are clever enough now that we have to worry about them.
    • [Tim] Starts to bring in complications. Suppose IC1 has a LVDS transmitter: Even if IC1 and IC2 are the same part, you might need to have different BSDLs. If the idea here was to bring out complications then LVDS is right where it starts.
    • [Ian] IC1, as an FPGA, may also need to be configured if the IC2 it's interfaced with is maybe an Ethernet Phy with a fixed IO configuration.
    • [Harrison] We're getting into the reasons behind some of the changes in 1149.1-2011. If we had P1687, then we'd already have the solution.
    • [Ian] But even if P1687 was an issued standard, it takes time for adoption. Especially if it needs to go into the silicon.
    • [Harrison] And 1687 could take longer to adopt than most. It's not just the silicon, there's all the tooling as well.
    • [Tim] Fast forwarding here, are you going to show a slide on SERDES?
    • [Ian] I imagine it'll actually be a series of slides.
    • [Harrison] Covering the differential and SERDES cases.
    • [Brad] Maybe it can be broken down into DC-coupled and AC-coupled?
    • [Harrison] That might be good.
    • [Ian] Yes, the DC-coupled cases can often be handled in a dot1 scenario.
    • [Brad] Although you have tooling issues when you have 2 cells at one side and only one at the other.

5. Key Takeaway for today's meeting

None.

6. Schedule next meeting

Next Meeting:
August 8th (11:00 AM EDT, 4:00 PM BST)

Schedule for August 2011:
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

Tim moved to adjourn at 12:00 Noon EDT, seconded by Eric.

Respectfully submitted,
Ian McIntosh

Copyright 2007-2009 The SJTAG Working Group
The SJTAG Initiative is "work-in-progress" and the views and opinions expressed here are subject to change without prior notice.