Minutes of Weekly Meeting, 2008-02-20

Meeting was called to order at 8:30am EST

1. Roll Call (Participants):

Brad Van Treuren
Carl Nielsen
Adam Ley
Patrick Au

By Proxy:
Ian McIntosh

2. Review and approve 2/11/2008 minutes

minutes were approved (moved by Carl, second by Adam)

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?
  • Establish whether TRST needs to be addressed as requirements in the ATCA specification if it is not going to be managed globally (All)
  • Register on new SJTAG web site (http://www.sjtag.org) (All)
  • All need to check and add any missing Doc's to the site (All)
  • Respond to Brad and Ian with suggestions for static web site structure (Brad suggests we model the site after an existing IEEE web site to ease migration of tooling later) (All)
  • Look at proposed scope and purpose from ITC 2006 presentation (attached slides) and propose scope and purpose for ATCA activity group (All)
  • Look at use cases and capture alternatives used to perform similar functions to better capture value add for SJTAG (All)
  • Volunteers needed for Use Case Forum ownership (All)
  • Continue Fault Injection/Insertion discussion on SJTAG Forum page (All)
  • Continue Structural Test use case discussion on SJTAG Forum page (All)
  • We will need to begin writing a white paper for the System JTAG use cases to provide to the ATCA working group (All) Most likely, champions will own their subject section and draft the section with help from others.
    This paper will be based on the paper Gunnar Carlsson started in 2005.
  • All: review how to use the forum
  • Brad will describe levels of self test in systems on Forum, everybody to review; [Done 2/19/2008]

4. Discussion Topics

  1. SJTAG Value Proposition - Power-On Self Test (POST) - continued from 2/11/08
    • [Brad] Gave an overview of the 4 POST levels as stated on the new "Test levels, constraints, and recovery procedures" discussion page on the SJTAG site.
    • [Adam] Initiated test may be outside of the scope of POST.
    • [Brad] You said "may be." Does that imply you feel there are conditions where these tests are needing to be applied during POST?
    • [Brad] Initiated tests are shared with POST sequences in most cases as a shared library of tests.
    • [Adam] A test in and of itself does not dictate a use case. POST shows the system is not fully operational, but initiated tests are performed while the system is operational.
    • [Adam] There are some opportunities for applying non-intrusive tests as well that can go even further as to when they can run as far as a system state is concerned.
    • [Ian] I think initiated test is an awkward term to define. In my vocabulary I have Power-on BIT, Initiated BIT and Continuous BIT: PBIT is generally the most intrusive, as it /can/ exercise circuits before they are functionally configured. CBIT is least intrusive - it is run cyclically throughout normal operation and /cannot/ cause any degradation in system performance. The scope of IBIT may be application dependant (maybe there are really two types here). It could be a time constrained test (to limit impact on operational availability, a sub-set of PBIT) run on demand as an extended health check, or it could be an extended test, without limitation, run as a diagnostic on demand, possibly following an error report from either PBIT or CBIT.
    • [Adam] A use case is orthogonal to a test. Every test is not pertinent to all use cases. Use cases help break down the types of tests that are appropriate at each state of a product life cycle.
    • [Brad] These are tests that may run after the Operating System (OS) is operational.
    • [Adam] Call it an OS level POST instead of initiated test then.
    • [Brad] An example of what I am referring to is a Carrier board test of the associated mezzanine interconnections being tested. It could also mean the testing of the mezzanine if the mezzanine does not include its own POST strategy, but must be tested during the POST process of the Carrier.
    • [Adam] It sounds like a flow chart needs to be developed to show the sequence of operations.
    • [Brad] I am hearing an additional issue surfacing in this discussion regarding defining the various states a circuit may be in and how that relates or constrains what types of tests may be applied.
    • [Adam] Great idea. We need to define these.
    • [Brad] Off the top of my head with what we have discussed I see:
      • On-line or active: fully functional and performing the intended purpose for what the circuit was designed for.
      • Off: Non-Powered state where nothing works on the board
      • Off-line: The board is not being used for its intended purpose at this time
      • Standby: Could be the same as Off-line or cold include cases where the circuit is partially unpowered (hibernating) as described by "Green Systems."
    • [Brad] Am I missing any or do you disagree?
    • [No response from group]
    • [Brad] I think this is why ATCA has the power sequencing scheme it employs to ensure it manages the overall power consumption of the running and booting system.
    • [Adam] The big advantage for ATCA is so not everything comes on at once. It also applies to thermal aspects as well.
    • [Ian] We often have CPLDs on our boards that manage the power up of the board, checking for over/under voltage on core supplies etc., shutting regulators down if faults are detected. This creates issues for BSCAN testing as we often need to know how to override these since some of the "switch-on" signals may not be present if the FPGAs haven't been configured. I think what I'm getting at is that sequenced power may mean that you need to be aware of how your scan chains are configured wrt the power scheme, so you don't have a broken chain because part of your circuit isn't switched on yet.
    • [Patrick] What is the issue of plug-in boards to a backplane?
    • [Brad] I could think of the issue of test management for that board if the test needs to be applied using a multi-drop interface or configurable star. This is why I presented a paper at ITC2005 regarding the extraction of test information using only JTAG.
    • [Brad] Another example is the testing of the interconnections between that plug-in board and other boards in the system. It is not known what the interface is from that board in the system. This is especially true for a new design in an existing system.
    • [Patrick] If a board is plugged in and tested in another system, what tests must be run on this board when it is installed in this system?
    • [Adam] Obviously, you could not perform on-line system POST because you cannot impact the system operation.
    • [Patrick] We are designing hot pluggable boards so we will hold the board from booting to do its own POST before coming on-line.
    • [Brad] What I am hearing is that there seems to be a difference between board states and system states regarding testing.
    • [Adam] ATCA should have a glossary of board and system states as part of its standard. We should base our glossary on these definitions.
    • [Brad] That sounds like a good action item for you and me to investigate, Adam.
    • [Ian] If people want to start proposing glossary terms, I'll make up a web page for them. We can develop and refine the definitions as we go - I don't expect we'll get them right first time!
    • [Brad] Are people bored with the topic of POST yet?
    • [All] Yes.
    • [Brad] Is there a proposal for the next topic and for a champion for that topic. Listed the remaining topics.
    • [Patrick] I would like to talk about AC testing - specifically 1149.6 for PCIe or other interfaces at a system level.
    • [Brad,Adam] We don't feel this topic is a separate use case, but falls within the Structural Test use case.
    • [Adam] It would be a useful discussion topic on its own.
    • [Patrick] I would like to discuss this specialized case when I can attend on a Wednesday meeting.
    • [Ian] I think 1149.6 raises a number of issues of it's own, so we do need to discuss it. I see it being most useful within a system-level test for checking board-board interconnects so it is pertinent to our discussions, although I don't see it as a "use case" - more a general topic within SJTAG.
    • [Brad] Adam, you and I had a discussion back in 2004 regarding the problems associated with the tooling supporting automated test generation for BIST since most people today are using ad hoc methods to trigger and observe BIST operations.
    • [Adam] That is indeed another interesting discussion topic.
    • [Carl] We have the same problem with ad hoc schemes in devices for our users.
    • [Carl] EST is an area I am interested in. I feel Carl Walker would also be able to participate will on this subject as well.
    • [Brad] I will open the request for a topic to the reflector to get a topic for next week.

5. Schedule next meeting

Monday 2/25/08, 8:15am EST

6. Review new action items

  • Locate ATCA glossary of board and system states (Adam, Brad)
  • Heiko - Need for a glossary of terms. POST would be a great candidate. Ian and Brad work on setting up a Glossary Page on the SJTAG site.
  • Continue POST use case discussion on SJTAG Forum page (All)
  • Brad submit an abstract regarding SJTAG Use Cases for ITC. Brad has an extension until Friday night.

7. Any other business

  • Patrick suggests we need a discussion specifically on the topic of AC testing (1149.6) with a system test perspective and how that is accomplished.
  • A discussion regarding who should be on the list of recipients for the draft minutes concluded that only people that have actively (joined the live meeting) in the past 4 meetings should receive the pre-release draft of the minutes to make comment on discussion and that non-active participants should not receive the minutes as a pre-release to make comment on (Proposed by Patrick, agreed with by Adam, Carl N. and Brad). Since non-active members currently do not respond, it seems like a reasonable policy by the group.
  • Patrick suggests that as part of the EST discussion we also include the topic of system-level burn-in testing since the are similar topics.
  • Patrick inquired whether there is going to be some closure on the use case discussion and his question was motivated by the point we need to have closure to show at ITC. This prompted a discussion on the merits of an ITC paper. The present members felt we should submit such a paper for presentation. Adam suggested we could apply for a Lecture Series or Industry Practices category instead of a formal paper that would present less restrictions on the paper. Brad will submit an abstract to ITC for review.
  • Guoqing sent me an email stating he was being reassigned in his company and that he would no longer be able to attend the SJTAG meetings. His alternate will try to participate in the meetings in the future.

8. Adjourn

meeting adjourned at 9:44am EST (motion by Adam, second by Carl)

Best regards,