Minutes of Weekly Meeting, 2012-05-14

Meeting called to order: 11:06 AM EDT

1. Roll Call

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

Excused:
Patrick Au

2. Review and approve previous minutes:

04/30/2012 minutes:

  • Draft circulated on 04/30/2012.
  • Two corrections noted:
    • [Brad] ... e.g. with SVF or STAPL the intent of the vector is lost;...
    • [Heiko] addressing of agents, data for diagnostics, recording of results - ...
  • Brad moved to approve with above corrections, 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)
  • Heiko to prepare overview of proposed updates for 1149.1 - Ongoing.
  • Heiko expects to have an overview ready for early June.

4. Discussion Topics

  1. Can existing system services provide the identification required by JTAG test?
    • [Ian] It sounded like there was enough discussion last time to continue with this subject.
    • [Ian] My initial thought was that using system services fits better for embedded test situations than for externally controlled tests.
    • [Brad] Yes but externally controlled tests are more like the situation where the agents on the board are not available.
    • {Tim joined}
    • [Harrison] That doesn't sound like online testing.
    • [Brad] There is a subset of things that would be done by an external tester; state of the system is probably not as important for an externally controlled test compared to embedded test.
    • [Harrison] The thing that's not obvious is that typically the test is written to validate the applications.
    • [Brad] With fault tolerant hardware you can do JTAG tests on the inactive sections.
    • [Harrison] Current system test applications are typically not JTAG oriented. Maybe use built-in self-test.
    • [Brad] But we shouldn't prevent the ability to run JTAG tests.
    • [Harrison] The BKMs aren't that way.
    • [Brad] You can't make that blanket statement; that depends on the company.
    • [Carl] We do JTAG based testing/configuration in out-of-service mode: We can test/update a card in a running system, and then bring that card back into service.
    • [Harrison] I'd like to see a presentation on that.
    • [Brad] There are plenty already in ITC: Ericsson has presentations on it. We've got presentation on it. Carl's company has presentations on it. It's just a fact that fault tolerant systems are going to be more testable.
    • [Harrison] But it's a nonstandard method.
    • [Carl] Exactly right - too much is ad-hoc and that why SJTAG is here. Different companies, even different business units, do the same thing in different ways, reinventing the wheel and hoping it comes out round.
    • [Harrison] The first point of common ground is rallying around P1687.
    • [Brad] are you proposing, Harrison, that EXTEST is recast as a P1687 instrument?
    • [Harrison] In essence, yes; ICL could be used for module description beyond silicon.
    • [Brad] Doesn't that override what is being done with current IEEE P1149.1 and BSDL updates?
    • [Harrison] Not really. The dot1 development seems to be market pressure because P1687 seems to take too long or seems to be too complicated.
    • [Brad] I'm not convinced that ICL can describe our boards and system components and architecture.
    • [Harrison] Yes - there would be some language on top of that.
    • [Brad] We do have examples, Carl has some, I have some and Gunnar has some, where we've been able to provide information to the tooling to get test we can use in the system.
    • [Harrison] And that's good, but it's not enough to drive the industry towards SJTAG.
    • [Brad] If you were to align with P1687, how would you fit the test generation into that approach? Do you envision that this could help us resolve the issues we are seeing with dynamic system configurations and test generation thereof?
    • [Harrison] I think it is doable, just look at the direction FPGA vendors like Altera and Xilinx are going in their roadmaps with migration towards SOCs. By the time SJTAG is there in paper and ink the silicon will be ready.
    • [Brad] if we are dealing with devices that are only 1149.1-2001 'aware'/ compliant, and with respective tools, how do we want to support that if we say SJTAG is P1687 centric/based?
    • [Harrison] P1687 doesn't exclude 1149.1.
    • [Brad] There seems to be lots of votes in P1687 about not supporting legacy. The hierarchy has only the SIB.
    • [Harrison] That's a problem with all standards - how far back to want to reach? I just think that by the SJTAG is a standard that it won't be as big a problem as you think it is just now.
    • [Ian] I'd be very nervous about making SJTAG P1687 centered, if just from my own company's position and looking at the lifecycle of devices we are working with. I can't see enough 1687 parts being in a design, making an SJTAG standard based on it useless to me for some time.
    • [Heiko] I agree, I wouldn't want to make SJTAG purely based on P1687 - that would limit its use dramatically, I think. We can take ideas from P1687 for SJTAG, and P1687 needs to be supported in SJTAG, but I think our standard should be IEEE 1149.1 based and should support standards such as P1687 as well.
    • [Ian] Yes, P1687 needs to be supported in SJTAG, along many other device standards. I worry that some smaller JTAG devices will never see a need for 1687, and I worry about allowing the FPGA vendors to seem to lead; after all Xilinx seem to struggle to implement the basic TAP 16-state state machine according to the standard.
    • [Brad] P1687 is a tool in the toolbox but it isn't the only tool.
    • [Ian] With instruments at device level, there's the same problem of coordinating instruments just as there is with devices in EXTEST.
    • [Harrison] P1687 is solving the problem in the silicon, it's not solving the problem at the chip edge yet.
    • [Ian] I can see that P1687 is recovering some of the BIT that we would have designed into ASICs. When we moved to use more FPGAs for flexibility then we lost that incentive to add BIT to the designs.
    • [Harrison] The x86 has a whole bunch of stuff that runs in the microcode. If you don't get through that then it gets difficult. P1687 solves a lot of that problem, so 1687 will be adopted there. In certain segments adoption will be a lot slower. The 1149.1-2012 updates work if the device isn't too smart.
  2. Excerpts from iNEMI survey (if available)
    • {Harrison hopes to be working on the slides this week}

5. Key Takeaway for today's meeting

None.

6. Schedule next meeting

Next Meeting:
21st
No meeting on 28th due to Memorial Day.

June schedule:
June 4 (may be a problem for Ian; holiday in the UK), 11, 18, 25

7. Any other business

None.

8. Review new action items

None.

9. Adjourn

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

Thanks to Heiko for providing additional notes this week.

Respectfully submitted,
Ian McIntosh