Minutes of Weekly Meeting, 2008-05-19
Meeting was called to order at 8:25am EDT
1. Roll Call (Participants):
Brad Van Treuren
Proxy feedback provided by:
2. Review and approve minutes
- 5/12/2008 minutes approved (Carl N. moved, Heiko second)
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 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
- Locate ATCA glossary of board and system states (Adam, Brad)
- Continue POST use case discussion on SJTAG Forum page (All)
- Adam review ATCA standard document for FRU's states
4. Discussion Topics
- SJTAG Value Proposition – Configuration and Tuning
- [Brad] Did not want to drop the conversation since there were a lot of proxy feedback statements
- [Heiko] P1149.7 group right now is also discussing language issues to try to describe feature and structure. What do 7 introduces is the addressing mechanism for the star configuration. With a 2 pin or 4 pin interface, the addressing scheme uses a TAP controller address needs to be specified on a reference designator context. Each instance of a device must have its own TAP controller address. Thus, the address cannot be part of any standard BSDL description because the information is different per instance. They are proposing using a separate file for address assignment to device reference designators on the Unit Under Test and BSDL Extensions for common dot 7 features.
- [Tim] Doesn’t it also use bidirectional TDI and TDO?
- [Heiko] Yes.
- [Tim] What about devices that have multiple cores in a device?
- [Heiko] Each core would have to have its own TAP controller, I think. Not their own TAP Pins, but TAP Controller.
- [Heiko] Dot 7 does not specify how you obtain the addressing definition
- [Brad] Was the discussion on this use case helpful for people and did you find you were able to gain a better understanding of what can be done with dot 1?
- [Heiko] The discussion helped me get a clearer picture of this use case
- [Ian (P)] The dot 7 issue raises the point I mentioned in a previous e-mail: Should SJTAG concentrate on current technologies or embrace new (future) technologies. I think dot 7 might be an "all or nothing" step, and therefore possibly a step too far. Nevertheless, the concept of being able to explicitly address individual devices is appealing, whether for config/tuning, programming or anything else.
- [Brad] Some cases that I see the 1149.1 interrogations useful for are:
- Trending same failures on boards indicating a manufacturing problem, design problem, or possibly thermal hot spot problem in a chassis design
- Same failure of a device – especially the same code response from BIST operations. This is good to identify if a failure is isolated to a particular lot of devices.
- The ability to dump the contents of a device configuration to identify if a configuration changed causing the failure. I had an example of an older Xilinx FPGA a while ago that was failing as the device would just stop working. Xilinx had us attempt to dump the contents of the FPGA programming using 1149.1 as much as we could to identify if a failure occurred in the configuration. With the data we captured, Xilinx was able to identify a process problem in a new foundry that was making that lot of devices and resolve the rather obscure problem fairly quickly. This was a good story about how a device vendor understood the importance of good tooling and how to leverage it and design for its use.
5. Schedule next meetings:
Wednesday, May 28, 2008, 8:15am EDT
6. Any other business
- Postpone Ian’s proposal for membership until he is available. He is presenting an SJTAG paper today at a European conference.
- IJTAG is organizing a set of tiger teams to discuss a couple of language proposals. There is an invitation to people outside the IJTAG working group for those interested. The language options proposed are:
- Alcatel-Lucent’s NSDL (Based on VHDL syntax with new instrument statements to define instrument hierarchical structure and instrument procedures which also support looping and variable language constructs)
- HDL/PLD (HDL defines the instrument hierarchical structure/PDL defines the functional definitions for each instrument) (HDL based on HSDL)
- iPI (Instrument Programming Interface) (XML description of instrument hierarchical structure with a C programming interface to libraries for the iPI interface)
7. Review new action items
- Send Brad email of your interest in the IJTAG tiger team attendance (all)
8. Adjourned at 9:16am EDT
(moved by Tim, second by Heiko)
I want to thank Heiko for his assistance in writing these minutes.