Minutes of Weekly Meeting, 2011-08-15

Meeting called to order: 11:04 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Brian Erickson
Heiko Ehrenberg
Peter Horwood
Tim Pender (joined 11:20)
Harrison Miles (joined 11:21)
Brad Van Treuren (joined 11:31)

Carl Walker
Adam Ley
Patrick Au

2. Review and approve previous minutes:

08/08/2011 minutes:

  • Draft circulated on 08/08/2011.
  • No corrections noted.
  • 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
  • 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. Summer Newsletter
    • [Ian] The next newsletter is due at the end of this month, so once again I'm looking for suggestions of content. I guess with where this falls, there might be a forward look at ITC, to mention the poster and fringe meeting.
    • [Ian] I can probably take suggestions up until Monday 29th, but the sooner the better, so that we can have something to review at that meeting.
  2. ITC Poster
    • [Ian] After being out on vacation all last week, I came in to the office today to find an email from Bill Eklow advising that Poster material should be submitted today for inclusion on the Presentation CD-ROM.
    • [Ian] I got a couple of days grace for this but it means I won't really have the time to review the final form with the group prior to sending it in, so I'll just have to try to describe my ideas for now.
    • [Ian] I wanted to work from the basic form we had last year.
    • {2010 Poster shared}
    • [Ian] This is the 3x4 layout I used in 2010. I was going to keep the slides in green - the ones that show the progression from a single board into the various multi-board schemes, and the general text, with an update to the Fringe Meeting details of course.
    • [Ian] The big change I wanted to make was to remove the Primitives slides and replace them with a real world example from my own industry, probably an ESCAN Radar Antenna: A sort of imperfect worked example to help highlight the practical potential and the problems.
    • [Eric] Sounds like a good idea.
    • [Ian] My thought was that a few 3D CAD illustrations or maybe photos would give a bit more of a visual 'hook' to lure people in. But I wanted to make sure that by using something from Selex that I wouldn't be offending anyone else.
    • [Heiko] I wouldn't be offended but maybe you need to ask your own company.
    • [Ian] Yes, I mentioned to Bill that I'd need to get permission to use the material for ITC.
    • [Heiko] It's fine with me.
    • [Eric] It's a good idea.
    • [Ian] OK, assuming that I get the permission, I'll update the slides and I'll send out a preview around the same time I send the submission to Bill. {ACTION}
  3. Explore communication between a pair of devices
    - Continue simple diagram development
    - Select new Use case
    • [Ian] I haven't really fully caught up on where you guys got to last week. I saw several new slides on memory testing.
    • {Shared PowerPoint slides}
    • [Ian] And a couple of new ones on differential signals. Was there more to be discussed on memory testing?
    • [Heiko] In the case of fully buffered DIMMs you can't really do interconnect testing because you probably don't have the dot6 cells. What I'm saying is that what testing you can do probably depends on type of memory.
    • {Tim joined}
    • [Ian] Yes, the more modern memories like DDR2/DDR3 create some problems for BScan test; there are techniques around but they don't really fall into the category of simple tests, and can be very device specific.
    • [Heiko] On that last slide (Memory Test, socket) you could add that IEEE Std 1581 is now available for memory test.
    • [Ian] OK. Is this topic finished or is there more to be brought out?
    • {Harrison joined}
    • [Harrison] To be clear, is this slide referring to memory in a socket as opposed to being soldered to the board?
    • [Heiko] That was what was intended.
    • [Eric] There's also a dependency on the scan path access that is provided by the device vendor. They tend not to provide memories with scan access.
    • [Harrison] That is the dominant problem.
    • [Heiko] I don't know if it was mentioned, but some memory controllers may have a MBIST that might be a preferable way to test the memory.
    • [Ian] I think there may be something on the previous slide? (Memory Test, with BIST).
    • [Heiko] Yes, that covers it.
    • [Harrison] If the data and address lines are shared, then that creates an additional challenge.
    • [Ian] OK.
    • [Tim] In that BIST slide, if you're not using TCK then you have dependencies on the system clock.
    • [Harrison] A lot of clocks don't have a boundary scan control cell.
    • [Tim] I'm thinking of a free running clock; you set up the BIST command then wait for so long and it should be done.
    • [Ian] OK, I'm looking where I should add the comments about the provision of access and the sharing of lines. those probably want to go on the first Memory Test slide, but it's already a bit busy.
    • [Heiko] On that slide, should the 'Control' and 'Data' labels be swapped?
    • [Ian] Yes.
    • {Brad joined}
    • [Tim] The controllers may be driven by a shorter BScan chain for speed. I'm thinking of memory loading where you might need to generate a write a pulse.
    • [Ian] This is getting into Programming wich might be another use case.
    • [Brad] Generically, what you're talking about is performing a functional activity by boundary scan.
    • [Harrison] Up to now we've been talking about the interconnect test, now we're moving into what I'd call a functional test. It's related to how much of the system need to be operational for the test.
    • [Ian] It's 'functional' with a small 'f' as opposed to Functional with a capital 'F'! It's a term that often confuses - it depends on whether you're doing a factory test confirm that something is built properly, or a field test to confirm that it performs as intended.
    • [Harrison] Yes, and I'd see the test for being built properly as 'functional' with a small 'f'. But you still don't know that the design is right.
    • [Ian] Before you get into series production, I'd hope that you've completed your design proving and have some confidence that the design is good.
    • [Harrison] Yes, but I don't think that boundary scan is well suited to design proving.
    • [Ian] Agreed, I see it being a way to help bring a board to life to get the design proving activities started.
    • [Brad] A lot more people are implementing BIST strategies for external controllers to test memories. So boundary scan still has place, but it's more that SJTAG becomes an enabler.
    • [Harrison] Yes, it becomes an enabling technology. SJTAG can then be brought to bear at the next level of assembly.
    • [Harrison] Devices, well you're going to turn on some 'instruments' somewhere. You're getting back into diagnostics. That's in the firmware; it's not part of the application software.
    • [Ian] I think we're seeing more of a blurring now between the firmware layers and what's in the application. Certainly though, a lot of the diagnostics won't be expressed in a customer requirement, which what often define the 'application'; it's what we add just to make the product testable and supportable.
    • [Brad] It's Operation, Administration, Maintenance.
    • [Harrison] Looks like 'phone guys got it right!
    • [Brad] When I joined, Tim was talking about external controls - should we have a new slide for that?
    • [Ian] Possibly. I was wondering if that was a different use case. There's probably some crossover here though.
    • [Brad] There is crossover. Just now we need to get the ideas down and we can categorize things later.
    • {New slide, from Memory Test}
    • [Brad] Add a new GPIO under IC1, extend the bus arrow and copy the Data, Address and Control lines from IC1 onto GPIO.
    • [Tim] Should we be showing Data and Address on GPIO?
    • [Brad] Good point. I can see Address and Control.
    • [Harrison] Thinking about PCIexpress, there's memory mapped IO... I can see Tim's point that it's maybe just 'Control'.
    • [Brad] I'm thinking of older schemes where you might use a higher address bit as a memory block select.
    • [Ian] I can see that. We tend to have relatively small memory devices in comparison to the allowable address range on a processor, so simple schemes like that would work.
    • [Brad] Embedded applications are often relatively small.
    • [Ian] Yes, it's the user interfaces that drive up the program size.
    • [Tim] Maybe we could show a dotted line from the TAP to the GPIO to show that there may be a shortened chain there?
    • [Brad] We're keeping it simple. It could be that IC1 is actually several devices.
    • [Ian] I see what Tim's getting at; While IC1 may be several devices in a chain, there may be a case for a separate, short chain to the GPIO for speed.
    • [Brad] This then gets back to a previous discussion maybe three months ago, where I was talking about alternate loads on a FPGA to provide a short chain.
    • [Ian] I think I can cover that with a text note, I'll add that and some of the other comments we made offline, since we're running out of time here.
    • [Tim] IC1 also needs to be tristateable on the Address and Control lines.
    • [Ian] OK.
    • [Brad] And FPGAs? Maybe a new diagram?

5. Key Takeaway for today's meeting


6. Schedule next meeting

Next Meeting:
August 22nd (11:00 AM EDT, 4:00 PM BST)

Schedule for August 2011:
22, 29.
Patrick will miss 22nd,
Eric may not be able to attend on 22nd,
Brad's availability on next two Mondays is uncertain.

7. Any other business


8. Review new action items

  • Ian - Circulate preview of ITC Poster to group.

9. Adjourn

Brad moved to adjourn at 12:06 PM EDT, seconded by Brian.

Respectfully submitted,
Ian McIntosh