Minutes of Weekly Meeting, 2010-03-08

Call to Order: 10:35am EST

1. Roll Call

Excused Absences:
Michele Portolan
Ian McIntosh

Roll Call:
Eric Cormack
Patrick Au
Adam Ley
Carl Walker
Brad Van Treuren
Peter Horwood
Tim Pender
Heiko Ehrenberg

2. Review and approve previous minutes:

Approval of March 1 minutes (Updated draft sent 3rd March):
Mover: Brad
Second: Eric
Approved: yes

3. Review old action items

4. Discussion Topics

  1. 2009 Survey
    • Review of submissions from Q9.3 onwards
    • Eric shared the survey results
    • Q9.3:
    • [Brad] companies building commodity type products probably won't want to add extra cost to support SJTAG on their boards/systems,
    • [Ian, P] The second comment could do with some explanation as I'm not sure what this person was really trying to say: The "capability" exists, but it can be complicated for some of the reasons we've previously discussed, like backplane netlists not meshing with board netlists. Typical ATPG tooling can cope with the gateways, so they're not really an issue.
    • Q9.4:
    • [Heiko] "no" answer: security issues? missing infrastructure? no configurable devices?
    • [Eric] I'm surprised only one respondent answered "we already do this"
    • [Adam] at the board-level you would probably see more "we already do this" answers
    • [Ian, P] If security is an issue here for anyone then it'll also be an issue in Q9.9 for updates. Some of the "No" answer may just be, as the comment suggests, that the types of design don't feature parts that really need that kind of support or if it is required then it's done through some "more convenient" interface like SPI or I2C that often already exists on a microcontroller or is easily dropped into an FPGA.
    • Q9.5:
    • no surprises
    • Q9.6:
    • no surprises
    • Q9.7:
    • [Heiko] this question was referring to board level self-tests, such as MemBIST between a JTAG enabled device (CPU, ASIC, etc.) and a discrete memory device? And/or to embedded self tests at the board level?
    • [Brad] and to built-in vector creation within devices on a board, enabling board self test as part of diagnostics
    • [Ian, P] Unless people read ahead in the survey then this one may have had some confusion. Q9.11 deals with POST and I don't think we really highlighted the difference. For example, I would use JTAG to access BIST features, but probably only as part of POST or maybe as an externally driven test when the system was on test bench. It'd be easy to see 9.11 as duplicating 9.7.
    • Q9.8:
    • no surprises
    • Q9.9:
    • [Brad] this diagram seems to indicate that the respondents basically fall into two camps: one group sees SJTAG as mostly concerned about the test infrastructure and test applications, while a second group sees SJTAG mostly as a means for system configuration and field upgrades; we'd need to look at other answers from the respective respondents in more detail to see if there is a correlation supporting the theory of such "camps"
    • [Ian, P] I don't know if it's really the two camps Brad mentions. The "Yes" answers could include people who currently program at the board level, and simply haven't thought much about programming at the system level, or they do all the system level reprogramming through a mission bus, and aren't really too worried about the need to have a JTAG emergency recovery option. The "No" answers likely cover people worried about security.
    • Q9.10:
    • [Heiko] this diagram matches the result for 9.8
    • [Brad] this can be expected
    • Q9.11:
    • [Brad] I'm a little surprised about the number of people that answered "Do";
    • [Carl] I'm surprised too; implementing and managing POST is not a trivial task;
    • [Eric] we could probe deeper to see who said "yes" and find out what/how they do it;
    • Q9.12:
    • [Brad] I'm surprised with this result, as was Ian; I would have expected more people to respond with "Do"
    • [Carl] I agree; this result is kind of counter-intuitive to some other answers;
    • [Brad] yes; in 9.11, for example, we have twice as many "Yes" answers
    • Q9.13:
    • [Brad] I'm a little surprised with this result; I'd have expected more people to already do this;
    • Q9.14:
    • [Brad] again, I'm a bit surprised about the comments related to the "No" responses; "IPMI" has a limited level of detail, especially when not set up properly and carefully; BScan seems the only means to monitor signal states consistently and conveniently (with reasonable effort);
  2. White Paper Volume 3 Review
    • What are the "big topics" for system JTAG architectures?
    • from last meeting:
    • Ian listed the following to get the discussion started:
      • Gateways. The issues with tooling, features on gateways, etc. will be something we'll no doubt talk a lot about.
      • Using OEM boards or mezzanines. For some there will be no issue here as everything will be designed in-house. Others will make extensive use of OEM parts.
      • Results storage and retrieval in embedded applications. May or may not be an issue.
      • Design Security. Can you make use of design security features and retain adequate access for test, update etc.?
    • additional topics:
    • [Brad] maybe the whole issue of test reuse;
    • [Heiko] storage/application of test vectors in embedded applications
    • [Tim] preconfigured vs. non-configured devices (FPGA's) - different BSDL
    • [Brad] need to see if we can put these ideas into an outline that works for volume 3
    • [Tim] we need to classify differences in Gateway architectures and protocols
    • [Brad] and also the similarities
    • [Heiko] ACTION - create forum entries for what we have so far for further discussions / details; ALL to review / comment in preparation for upcoming meetings

5. Schedule next meeting

Monday Mar 15, 2010, 10:30 AM EDT, 14:30 GMT
expected absence: Carl
March schedule
22 10:30 EDT, 14:30 GMT
expected absence: Peter, Tim
29 10:30 EDT, 15:30 BST
expected absence: Peter, Carl

6. Any other business


7. Review new action items

8. Adjourn

Adjourn 11:30am EST

Best regards,
Heiko Ehrenberg