Minutes of Weekly Meeting, 2007-12-17
Brad Van Treuren
Meeting was called to order at 8:11am EST
1. Roll Call (See list above)
2. Review of meeting minutes for 12/3/2007
Motion to approve 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 (http://www.mcintoshuk.plus.com/sjtag/) (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)
Brad: Reminder we need to create a scope and purpose for this discussion group. Proposed scope and purpose from ITC 2006 slides as a bases to work from. The Group is to review and comment towards the formulation of the goals and scope and purpose for SJTAG on ATCA.
- Contact Guoqing regarding alternate meeting time process (Brad) (Done)
- Set up Use Case categories for forum discussions (Ian) (Done)
- Volunteers needed for Use Case Forum ownership (All)(Ian-Fault Injection, Heiko-Structural Test, Brad-POST, Need more volunteers!)
- Send Ian list of volunteers for Use Case champions (Brad) (Done for those responding)
4. SJTAG Email reflector overview postponed since Carl Walker did not attend
5. Discussion Topics
- SJTAG Value Proposition - Forum groups on specific use case alternatives
- Fault Injection:
- Ian: physical modifications (wires, extender cards, ...) may be needed to insert faults (current way of doing this at our company), but this may not allow simulation of real faults, also, it changes the environment (systems cannot be sealed, temperature changes, etc.); problem with JTAG is that putting a device into EXTEST takes all of its pins out of functional mode; The benefit of JTAG is we don't have to break the circuit physically to perform the test.
- Heiko: I have found the biggest problem with JTAG Fault Injection is I have to bring the device into EXTEST which takes it out of functional mode
- Brad: jumpers, wires, etc. seem to be unreliable; Fault Injection mostly used for design-proving software/firmware
- Brad: there are ways (some patented) to make individual pins controllable for fault injection (FPGAs, ASICs, PLDs); taking a device out of functional mode not necessarily needed; These techniques allow for a single pin or a group of pins on a device to be asserted with a fault condition
- Brad: Bill Eklow, Cisco, presented a paper a couple of years ago at the Board Test Workshop on using simulation in place of physical fault insertion;
- Ian: Simulation seems to be a rather expensive way to go, in particular for low-volume type applications; The return on investment (ROI) seems to be very dependent on production volume
- Heiko: maybe FPGA / PLD vendors could be approached to implement device features to support fault injection;
- Brad: discussed that with FPGA vendor before, they seem not interested in doing this, rather provide debug tools for device internal functionality; They feel Fault Injection is a System Test problem and not their problem. The reality is that it is a System Test problem requiring device level features to support it.
- Brad: extender cards and similar physical modifications also degrade performance of the system by changing the characteristics of the nets. This is especially impacting as speeds of the signals increase
- Ian: absolutely; time consuming and expensive effort to try to achieve best possible signal integrity for such physical modifications;
- Ian: We use a pinless connector system for that reason. Even wires/probes near a signal cause problems.
- Ian: We even use floating wires to pick-up (measure/detect) signals
- Heiko: (jokingly) why don't we use the same method to inject faults?
- Ian: possible but not very controllable
- Heiko: you'd need to open the system again, and you'd not know where exactly the signal is radiating / coupling
- Ian: Even if you use this wire to inject a fault, you don't know where it is radiating.
- Adam: Also, this would be an AC type signal instead of DC type
- Brad: What about transient faults? Switches and wires all model stuck-at faults. Boundary Scan is too slow to rely on pattern changes to cause transient faults; The dot-6 mechanisms reveal a possible way with how a non-DC signals could be controlled with JTAG
- Ian: Traditional fault injection methods only for stuck (DC) type faults; for transient faults respective functions in firmware can be implemented
- Brad: Relying on Firmware changes means the faults inserted do not happen at asynchronous times, but occur at planned times. This change does not actually run the true software/firmware used by the system in the field. Some people take advantage of a multi-tasking operating system and run a separate process that asynchronously changes the value of registers in devices to inject faults, but this could damage the board if the changes done are outside the scope of operation. This is not a very smart thing to do.
- Ian: boards delivered to customer are not exactly the same as those used for fault injection; systems are not the same when using wires and extender cards for fault injection; Further, we only perform fault injection on engineering model boards. Most times these engineering board designs end up not representing what ultimately ships out to the customer.
- Brad: Cooling conditions may be different when running with a physically modified board that could adversely affect the way a board operates.
- Ian: Many times, the boards modified for Fault Injection do not represent the real world operating environment for the board because required conformal coatings must be removed in order to gain access to the fault sites.
- Brad: Fault injection is usually only done on engineering samples; even when you use Boundary Scan to inject faults, you don't want to ship those boards to customers anymore;
- Ian: experience shows factor of 10 (approximately) in cost difference between engineering modules used for fault injection and production modules (production modules less expensive). Again, the volume of production plays a big role in the cost differential. We have low volume runs so all boards are not inexpensive.
- Ian: another advantage of Boundary Scan (or some other method not requiring physical modifications) for fault injection is the reusability: faults can be "reused" or changed in the future without physical modifications;
- Ian: JTAG lets you come up with future fault models that you can try without needing to modify the board.
- Ian: Traditionally, fault injection looked at a single fault scenarios.
- Brad: Some of our customers are now explicitly requiring fault injection verification on specific signals as part of an acceptance test (requirements in contracts)
- Ian: I suggest we continue this discussion on the Forum site.
6. Next meeting scheduled for 1/7/2008 at 8:15am EST
7. Review new action items
- Continue discussion of Fault Injection on SJTAG Forum.
8. Other business.
- Ian has volunteered to champion the Fault Injection Use Case analysis
- Heiko has volunteered to champion the Structural Test Use Case analysis
- Brad has volunteered to champion the POST Use Case analysis
- WE NEED MORE VOLUNTEER CHAMPIONS!
Meeting adjourned at 9:16am EST
Many thanks to Heiko for supplying his notes to assist in recording the meeting.