The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-02-04

Meeting was called to order at 8:20 am EST

1. Roll Call (Participants):

Brad Van Treuren
Adam Ley
Heiko Ehrenberg
Carl Walker
Ian McIntosh
Peter Horwood

2. Review and approve 1/28/2008 minutes

minutes were approved with changes requested by Peter (moved by Heiko, second by Ian)

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)
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)
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

SJTAG Value Proposition - Power-On Self Test (POST) - continued from 1/28/08

[Brad] - test and diagnostic data formats - ASCII or binary,
- interoperability between tool vendors,
- presentation of test data from different module/board vendors;
[Brad] ASCII not really sufficient for test and diagnostic data; binary more efficient, more compact; maybe even compressed binary;
[Ian] I agree that binary is preferable; format needs to be defined in SJTAG to make transport between tools work;
[Brad] yes, format definition is needed for tool vendor interoperability;
[Ian] we need to standardize the interface, but the implementation should be up to the designer;
[Brad] what do the tool vendors say?
[Heiko] I would assume that more processing work is necessary to process ASCII then binary. More storage is required for ASCII. We each have our own diagnostic databases. It is easier to process binary diagnostic information then ASCII.
[Adam] Most vectors for us are processed from an ASCII base. They are processed to a binary stream to the hardware. Some exceptions are SVF that is precompiled. The key difference between PC tools and embedded environments are resource constraints. Embedded environments are highly constrained.
[Brad] usually we use ASCII vectors from tools and then convert them to binary ourselves; for diagnostics the boundary between user and tool vendors may not be as well defined;
[Brad] Can we agree that SJTAG should standardize or select an ASCII format for test data?
[Ian] I think this should be done, a user/designer would then take the ASCII format and convert it in any way needed for his implementation; but diagnostics would be a much bigger issue;
[Ian] What do we report back out?
[Brad] where should the boundaries for hand off be drawn for ATPG tools to where its stored for embedded flow is at vector boundary. So the boundary should be at test vector perspective but the issue is the association of result information. My paper given 2005/2006 BTW, one of those, shows some basic diagnostics. How can these results be presented back to the ATPG tools in a standard manner.
[Heiko/Ian] agrress that svf asci is ok and then designers do conversion
[Adam] SVF and STAPL are suitable and reasonable choices. There are some cases (memory access verification and FLASH programming) where they may not be suitable because of the sheer data volumes involved.
[Ian] Agrees but if talking about POST then these will not be covered by POST test. These cases described exception cases.
[Adam] Do we have a formalized list of the required TAP Actions for POST?
[Brad] We need to spend some time on it.
[Adam] Concerning diagnostics, how important is it to be able to generate diagnostics in the embedded environment v.s some form of representation that could be reviewed later for detailed diagnostics?
[Peter] Is the flow as we did at EBTW with Firecron and Asset?
[Adam] Yes
[Brad] We don't always get access to the system to be able to extract information stored in the system.
[Brad] having it embedded is advantageous as we are locked out by customers, so we would be limited to receiving just a console message for what the failure was both for functional and boundary scan POST tests
[Brad] We usually run the diagnostics on the system to ensure we have "test anywhere" capability that is consistent in any place the product is placed.
[Adam] Do you only need FRU indictment?
[Ian] POST is only run at power-up. So if there is a problem there, the board is going to most likely be replaced. [Adam] puzzled as FRU identified faulty which will be sent back to repair shop, where failure can be run off-line
[Brad] Some of the tests show multi FRU's faulty and further information required to single it down (e.g., missing required signals from external boards that are SAMPLED as part of POST as assertions for operation)
[Ian] Agrees that you want to get FRU failure down to 1, if you need to do more can the shelf manager make the decision as to what FRU should be pulled?
[Peter] If you are moving test diagnostics from FRU to shelf manager, is the logical extension of this to do it off-line as Adam described
[Brad] If you have 16 mezzanine cards on a single carrier board, then being able to diagnose the failing AMC will add value - especially during system installation. Most people don't factor in the installation costs.
[Adam] In the example as described, is the AMC not an FRU?
[Brad] some software packages will treat the whole combined carrier as the FRU, The whole arena of where is the FRU boundary becomes blurred....In some earlier systems, an FRU was 5 PCB's
[Adam] In term of diagnostics what level are you requiring?
[Brad] For interconnect tests, people want failing pin and net names reported. This is useful after assembly stage before functional test also to reduce handling problems that occur during transfer
[Brad] FRU can mean different things to different users
[Adam] so assuming that you need more than "POST passed" or "POST failed", would net-level diagnostics be sufficient?
[Brad] for interconnect test, yes
[Adam] sounds like taking failure information and displaying it in a structural way, which should be achievable with look-up tables;
[Brad] yes
[Brad] Look at evolution of PC tools. Initial tools had basic failures and then built on that, looking to provide more information than pass fail.
[Carl W.] What level of diagnostics is required depends on the application
[Carl W.] I will inquire internally for more details
[Brad] seems like we are in agreement to use an existing ASCII format to transmit test data from tool vendor to system integrator / user
[Peter] requirement for detailed diagnostics may add cost to the hardware (board/module)
[Peter] Indicated that inter connect tests were structured correctly pass fail can be identified to each FRU i.e., run 1 for each module thus identify the failing AMC by putting mandate of diagnostics support on the card will have cost impact on cards. Some cards many not be able to take this cost.
[Brad] having carrier, modules, and mezzanine cards from different vendors makes generating tests between them difficult, requires respective structural information from the respective module vendors;
[Ian] would it be possible to describe such a board in BSDL?
[Adam] not really, since BSDL does not provide for multi-chip or hierarchical descriptions, but a special description for such information could be defined;
[Adam] In the strictest sense, BSDL is constrained to describe a single component. In theory, it is possible to take symbols of each element and wrap them in some other suitable description format (e.g., HSDL or others). We could chose a variant of BSDL that is not compliant to 1149.1 as well.
[Brad] this is the same problem that other standard committees are working on now, we do have 1 aspect that is different which is the dynamic that things change in a slot
[Adam] True but SOC often has power management that might shut down/power up cores
[Brad] True but the cores will be defined where AMC 's could be different
[Adam] This might happen in SOC also i.e., shut down 1 element and power up another P1687 /P1149.7 trying to establish from work at top level of SOC to obscure the complexities of the multi cores. No interest to do this at PCB level, however vendors will want to protect IP. If POST is present vendor may not want to provide netlist information
[Brad] issues here that POST can provide level of abstraction as long as certain level of diagnostics can be reported back to shelf manager etc, for AMC some additional capabilities are required so that end user can add diagnostics
[Adam] POST level the vendors may have concern at level of diagnostics reported in, it would be possible to obtain netlist of card if netlist name given along with other connecting nets
[Adam/Brad] Possible to identify chips on board with no real knowledge
[Brad] Looks like the achievement is that SVF/STAPL should be used as hand off point from tool vendor and embedded domain.
[Brad] we will still need to spend further time on this as we have not covered all items
[Adam] As list is defined we may end up with cases where SVF/STAPL is not practical
[Adam] module vendors may not want to provide net or pin level diagnostics; tools can only work with the information given to them;
[Brad] discussion to be continued at next meeting

5. Schedule next meeting

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

6. Review new action items

7. Any other business

should "proxies" be eligible for voting? [raised by Ian]

[Adam] They must be present for the vote if we vote during a live meeting
[Ian] Propose all ballots of significance be done electronically.
[Adam] Question on representation in the minutes. I have a concern if we count them as active participants, that raises the bar on the definition of a quorum. Two levels become overly complex. Thus, all ballots would have to be conducted electronically and all meetings are just for discussion. Two levels: live meeting membership and electronic membership.
[Ian] I will send email out to the group for continued discussion on the forum site.

to be discussed further on the SJTAG forum

8. Adjourn

meeting adjourned at 9:42am EST