Minutes of Weekly Meeting, 2011-07-18

Meeting called to order: 11:05 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Adam Ley (left 11:56)
Richard Foster (left 11:47)
Carl Walker
Tim Pender
Heiko Ehrenberg
Brad Van Treuren
Brian Erickson
Harrison Miles (joined 11:07)

Excused:
Patrick Au
Peter Horwood

2. Review and approve previous minutes:

11/07/2011 minutes:

  • Draft circulated on 11/07/2011.
  • No corrections noted.
  • Eric moved to approve, seconded by Brad, 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 - Consider interconnect test
    • [Ian] At the end of the last meeting, the group seemed to conclude that we'd taken scan path verification as far as we could for now, and Brad suggested moving on to the interconnect test.
    • [Brad] That seemed to be next most likely use case for the group here to have some knowledge of.
    • [Ian] I'll share the diagrams from last week and we can modify from there.
    • {PowerPoint slides shared}
    • [Ian] I expect we can copy the last slide and then edit. I suppose the simplest interconnect test is where only one device is driving and only one device is sensing.
    • {New slide created}
    • [Brad] Maybe an assumption we need here is that both devices are controlled by one scan chain, otherwise you have issues of synchronization.
    • [Harrison] 1687 takes care of that - iApply!
    • [Tim] The logic levels should be assumed to be the same too.
    • [Harrison] Yes, the TAPs in the chain need to be the same logic level.
    • [Ian] I thought Tim was referring to the interconnected I/O between the devices.
    • [Brad] It doesn't hurt to expressly state that the TAPs need to use the same logic levels and that the I/O needs to use the same logic levels.
    • [Heiko] Should we consider constraints imposed by other components, or do we assume that we have no other components?
    • [Ian] I think we're to keep to the simplest arrangement first; we can add more complexity later.
    • [Brad] Do we need to note that the update and read isn't instantaneous or do we assume knowledge of basic 1149.1 operation?
    • [Harrison] I think that's lower level detail.
    • [Ian] Even without 1149.1, it's like any synchronous logic: Make sure you clock out on one clock edge and clock in on the other edge.
    • [Tim] What are we looking for now? The steps to carry out the test?
    • [Ian] Yeah, I think we want to express the process of an interconnect test.
    • [Harrison] Just so I know, what is the intent of these diagrams?
    • [Brad] This was following on from your suggestion of looking at pair-wise applications.
    • [Harrison] OK, well I agree with what you're doing here. I'd have a tendency to separate things out into categories here: What you have is probably the 1990's classic combinatorial logic. When you get to 'intelligent' devices like processors then they often need to be in a separate chain. The vendor can be sloppy about telling you that; maybe there's note on page 155 of a datasheet that tells you.
    • [Brad] An intelligent device in EXTEST will behave just like a combinatorial device.
    • [Harrison] Yes, mostly, but there can be some elements of non-compliance.
    • [Ian] We used the MPC555 where the BDM mode was non-compliant with JTAG. It also had an issue where if you weren't careful with reading the datasheet you could create a condition where you could kick it from BDM mode to JTAG mode but couldn't get it back again.
    • [Harrison] The older PowerPC parts had some non-compliance issues.
    • [Ian] Just on the subject of partitioning chains, there can be several reasons for putting devices into specific chains: It could be due to differences in TAP logic levels as we mentioned before, limitations on the maximum TCK frequency - to avoid one device slowing down a whole chain, or for emulation support - the need to use vendor tools which often don't like third party parts in the chain.
    • [Brad] One other thing that come to mind after the mention of the MPC555, is the condition of the device after power up. There are some processors that need to see 32 clocks to bring it out of reset, before you can do anything with it.
    • [Harrison] Yes, these are the sort of things that intelligent devices imply.
    • [Harrison] Then there's the question of what do you do with SERDES devices.
    • [Brad] We should probably keep to straight Dot1 for this example.
    • [Harrison] So what we have is more the straight from the 1990s interconnect test?
    • [Brad] Yes. Once we get into Dot6 we'll probably see a capacitor thrown in.
    • [Harrison] SOCs are probably another category.
    • [Brad] Can we enumerate these categories, for the minutes?
      1. '1990s' Dot1 combinatorial logic.
      2. 'Intelligent' devices, mainly processors and DSPs.
        • [Tim] Generally these are non-compliant with Dot1?
        • [Harrison] That was certainly a problem in the 1990s. Post-2000 they're mostly OK although there are some renegades.
      3. Soft Processors, as offered in the higher end Xilinx and Altera FPGAs.
        • [Tim] How are these different?
        • [Harrison] It's that they're typically recommended to be in their own chain due to some features or behaviours.
        • [Ian] I think the other thing than can come up with these is the option not just of the soft processor but of a soft TAP.
        • [Harrison] That's a good point. You could also include CPLDs here, although they tend to be going out of favor.
        • [Ian] Depends on the application; there are cases where you might want to avoid using a FPGA, but that's a different subject.
      4. SERDES devices.
        • [Harrison] There's a bit of an overlap now. It used to be that SERDES was in dedicated devices, but now we're seeing and overlap into SERDES appearing on FPGAs and processors - a kind of hybrid.
      5. SOC multi-core devices.
        • [Harrison] When I say 'multi-core' I'm not implying multi-processor, where different cores may be running different tasks. I'm thinking of cores where everything is working towards the same task.
        • [Harrison] There may be an embedded TAP that you want to take advantage of. It could be a complete function of the device.
        • [Tim] Are we talking about a multi-TAP device?
        • [Harrison] With Dot7 it starts to become important to know about the embedded TAP. It's a subtle distinction.
        • [Tim] So are we interested in the internal chip interconnect test or the external chip interconnects?
        • [Harrison] It could be both.
        • [Ian] I'm inclined to think of SOCs as a special case that we can consider later. From a hierarchical perspective, we could treat them as near equivalent to boards - perhaps think of them as daughter boards to the design they're used in.
        • [Harrison] That's probably a good summary of SOCs.
        • [Brad] Even many MCMs will be almost like SOCs.
        • [Ian] Yes, multiple distinct devices within a package.
      6. ASICs
        • [Ian] Largely because of our low volumes, we've pretty much abandoned creating ASICs now.
        • [Harrison] Yes, in many cases you could use FPGAs now and avoid the risk of costly mistakes.
        • [Ian] It's pretty much the cost of design and foundry masks versus the risk of error that have killed them for us.
        • [Brad] There are still plenty of people using them.
        • [Ian] Oh yes, for many manufacturers they make a lot of sense; just not for us.
    • [Brad] A lot of these categories look to be orthogonal to each other?
    • [Harrison] That may be, but it's a broad categorization. The orthogonality maybe doesn't matter too much.
    • [Ian] I think we'll have to leave it there for this week. The discussion seems to have flushed out a lot of thoughts on things that can influence architecture, even though we didn't develop the kinds of things I originally anticipated.

5. Key Takeaway for today's meeting

  • [Brad] Six device categories influencing architecture: 'Classic' combinatorial logic, Intelligent devices, Soft processors, SERDES devices, SOCs and ASICs.

6. Schedule next meeting

Next Meeting:
July 25th (11:00 AM EDT, 4:00 PM BST)
Adam expects to be unavailable.

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

7. Any other business

  • The SJTAG Fringe Meeting at ITC is now booked for Wednesday, September 21st, 2:00-3:00 PM (PDT).

8. Review new action items

None.

9. Adjourn

Brian moved to adjourn at 12:02 AM EDT, seconded by Tim.

Respectfully submitted,
Ian McIntosh