Minutes of Weekly Meeting, 2008-01-28

1. Roll Call


Brad Van Treuren
Adam Ley
Ian McIntosh
Heiko Ehrenberg
Peter Horwood
Guoqing Li

Email Proxy on the POST Use Case Discussion:

Guoqing Li - sent some corrections of a pre-release draft for his comments that were added to the minutes below

2. Review and approve 1/23/2008 minutes

minutes were approved with changes proposed by Ian and comment by Peter (moved by Ian, second by Heiko)

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)
  • Provide feedback of more use cases not yet identified to Brad (All)
  • Review tables (Goals vs. use case matrix) on slides 38-41; (All)
  • Register on new SJTAG web site (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)
  • Contact Guoqing regarding alternate meeting time process (Brad)
  • Set up Use Case categories for forum discussions (Ian)
  • Volunteers needed for Use Case Forum ownership (All)
  • Send Ian list of volunteers for Use Case champions (Brad) (Only Ian responded to request)
  • Continue Fault Injection/Insertion discussion on SJTAG Forum page (All)
  • Continue Structural Test use case discussion on SJTAG Forum page (All)
  • Send additional sub topics to Heiko for the continued Structural Test use case discussion for 1/14/08. (All)
    • Guoqing's list is a very good start
  • 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.

4. Discussion Topics

  1. SJTAG Value Proposition - Power-On Self Test (POST)
    • - [Brad] background info:
      • performing test just after power is applied and prior to the system coming into service
      • to detect any problems that would inhibit proper function of the system
      • Purpose of Boundary-Scan POST
        • Provide quantified test coverage
        • Improve diagnostic resolution
        • Provide parallel System Test
        • Automatically generated tests
      • Constraints
        • there is a limited time available for POST
        • Limited coverage if CPU involved in performing the test
        • must not stimulate outgoing signals
      • Cost
        • reusable (firmware) software elements between designs
        • Reduced test generation cost via automated generation from CAD data
    • [Ian] So POST is done at the module level and not at the System Level?
    • [Brad] yes, most of the time
    • [Heiko] time limit for POST was mentioned in previous calls typically to be in the 10 seconds range
    • [Brad] typically, yes, but it is application dependent
    • [Heiko] that seems to leave not too much time for extensive cluster testing, in particular for memory devices
    • [Brad] that also depends on the application, in particular TCK rate
    • [Heiko] So the dependencies would be chain size and TCK frequency?
    • [Brad] Yes.
    • [Heiko] how are the tests stored
    • [Brad] they are stored in flash on the unit
    • [Heiko] is it a dedicated test flash
    • [Brad] depends on the system. some have dedicated some share with system code
    • [Guoqing] test sequence is started by BSCAN or tests exec, is it BIST via FPGA?
    • [Brad] In some cases you could call it that.
    • [Brad] If there is a hardware processor this is done before any software is run., this brings up a constraint of changing state of core logic due to BSCAN, there must be mechanism's to be able to reset/reboot the board after BScan test and then to skip BScan at the new reboot
    • [Brad] Peter, you gave a presentation at BTW2002 describing one of your products performing this type of testing. Do you have anything to add?
    • [Peter] there are widely used methods to do this, there are even commercially available devices.
    • [Peter] Explained the JTS02 device the method of using the first execution to run tests/programming on the card then when the test is complete the PCB reboots and does not run the tests and the card come up.
    • [Brad] If Carl Nielson were here, I am sure he would also talk about the SystemBIST device his company markets. I have also heard about many internally developed solutions. There are many solutions showing up for ATCA using the Board Management Controller (BMC) for ATCA blades and the Module Management Controller (MMC) on AMC blades.
    • [Brad] Spoke of the IPMI controller (BMC, MMC)to bring up power , explained that he has seen this device implementing bscan testing sometimes in in a separate device or pure software etc.
    • [Brad] there are many different ways of doing this
    • [Brad] is there value in including Boundary Scan in a POST stream?
    • [Ian] it may be hard to see benefit by itself, but if Boundary Scan is implemented then it certainly makes sense to utilize it during POST (depending on application)
    • [Ian] If it becomes relatively cheap to implement because you use it elsewhere, the value is higher.
    • [Ian] We used to use system BSCAN in the past, but tooling was so poor and required hand generation of vectors. Now that the tooling is improved, we need to revisit this.
    • [Guoqing] POST needs to be designed for several modes as option, for example, Quick Start test, and Manufacturing Test (more time).
    • [Guoqing] "quick start" (limited number of tests) and. "complete start" (complete set of tests) POST are useful in both production test and in field test.
    • [Heiko] Do you require 2 types of POST: one quicker and one slower?
    • [Guoqing] Indicates that system start time should be as short as possible, but the bscan testing could be useful in factory system tests and in field test when you have more time in your hand to start the system.
    • [Heiko] so its possible to have 2 sets of tests one more complete than the other
    • [Guoqing] Request to designer should give 2 run modes a quick start or complete boot ie run all tests
    • [Guoqing] I would like to ask our designers provide 2 modes, at least meet production test needs.
    • [Brad /Guoqing] questions on when you run full /short tests during life time ie configure, system, etc.
    • [Guoqing] Memory plus other high speed links have to be tested. So if some BIST are designed in FPGA and ASIC, people have to trade off test time and test sequence.
    • [Brad] Understood that some tests will go over time budget and will be run as separate process
    • [Brad] asked Ian on the issue of tooling
    • [Ian] Tooling must handle all test generation needs for Power-on/Reset.
    • [Brad] Before we talk about the tooling, do we need to define inputs and outputs first?
    • [Ian] Yes.
    • [Adam] How do we see the FRU level POST being enabled by open-systems like ATCA?
    • [Brad] I believe it will be controlled by blade or boards, its up to vendor of the card to determine how this will work. The real question is how will the implementation be integrated into the COTS user's overall system test strategy? There must be a way to make vendor A solution look like vendor B solution to the system developer.
    • [Adam] That is one aspect, expecting vendors to implement the self test feature. How are the concerns to be handled regarding the time budget? The vendor's implementation may not meet the system designers time budget.
    • [Brad] Good point if end user is to write the test then that may compromise the IP from the vendor.
    • [Ian] How much is really given out as IP since the schematic content doesn't expose much since most of the IP is in FPGA codes?
    • [Ian] As we are talking about FRU then it should be part of the deliverables
    • [Brad] This is Ok, but for AMC type cards and plug-ins, how will this work?
    • [Adam] For ATCA application, I would look to have this included in the specification
    • [Ian] We must look at the totality of use cases to reveal value because cost may be trivial to none to use BSCAN for POST if you must use it for something else.
    • [Brad] The key is to get the hardware correct, then the software can follow, once the designer understand the benefits then designers are converted to its value.
    • [Brad] further topics for discussion: inputs and output for POST; tooling requirements;
    • [Brad] should data format for the system be defined by SJTAG or should it be left up to the system integrator? (should the data be made available in a generic ASCII readable format or in a fixed format defined in SJTAG?)
    • [Brad] looking for inputs-> outputs, tests should be in a more efficient form than svf or stapl
    • [Adam] would stapl byte code be efficient enough?
    • [Brad] Can we deal with this next week? jbc is not always the best solution, ie what operation need to be performed
    • [Brad] This is the whole reason we developed TFCL the way that we did so we could choose what format to use for an application. If we required STAPL for one task, then why not use it for others? I don't think people want to support multiple formats in the embedded environment, but certain formats are not good for some tasks. Does this address your question?
    • [Adam] No it does not, but leave for now.
    • [Peter] Should the tests be supplied in ACSII and reported back in ASCII? An ASCII format is restrictive to the hardware that has to be implemented on the PCBA (Clarification from Peter: What I was trying to get across is that a common binary format to execute on the embedded hardware can be restrictive to the hardware vendor companies implementations point of view. Also the tests being exported/imported from the test tools should be easily readable by the end users to aid diagnosis. In the case that there is an issue and the user needs to prove where the issue lies ... i.e., is it the vectors, is it the embedded vector delivery method or is it an issue on the PCB)
    • [Brad] indicated that this is what has been done on some products
    • [Brad] ask Guoqing: Does he want the ability to choose how to store the data in the system
    • [Guoqing] I would like that Test results are normally stored in block of flash, run structural test at Power-on/Reset for production or field. But not easy to choose format for storage
    • [Brad] How is the interoperability between tool vendors, how will it be done for multiple vendors. How do we unify the results???? Stay tuned for next week's discussion.

5. Schedule next meeting

Monday, 2/4/2008, 8:15am EST

6. Review new action items

Brad to redistribute 1/23/08 meeting minutes with changes

7. Any other business


8. Adjourn

meeting adjourned at 9:28am EST

Special thanks to Heiko and Peter for providing supplemental notes.

Respectfully submitted,