Minutes of SJTAG Fringe Meeting at ITC'11, 2011-09-21
Meeting called to order: 2:10 PM PDT
1. Roll Call
Brian Erickson (JTAG Technologies)
Ian McIntosh (Selex Galileo)
Anthony Sparks (JTAG Technologies)
Heiko Ehrenberg (Goepel Electronics)
Adam Ley (Asset Intertech Inc.)
Ian opened the meeting, deciding to dispense with a status report, since the attendees were in the main regular participants of the weekly conference calls.
It was noted that a small number of people had expressed some inclination to attend the Fringe Meeting, but had clearly found other conference proceedings to be of greater interest.
Ian expressed a personal frustration that almost a year after the last ITC Fringe Meeting, the group appeared, at least outwardly, to be no closer to establishing a PAR. Adam remarked that was maybe in the nature of online meetings, suggesting that it may take 100 online meetings to achieve the same results as one face-to-face meeting. Commenting on the scale of the SJTAG problem space, Adam proposed that we should establish the value proposition for our Dot0/Dot1: Who is going to benefit? Who is going to supply the conforming entities? Who is going to take delivery of the items? What value is derived?
Heiko noted that Adam's very early list of questions remained in the weekly meeting action list, and could be reviewed. Ian looked these up for reference, and Adam commented that in retrospect they were probably too general to be answerable.
Concern was expressed by Ian that the longer the group went without achieving a standard, then there was a risk that tool vendors and end users would eventually develop divergent and incompatible solutions to parts of the SJTAG problem. Adam remarked that it was common to get several solution to a problem but that simply meant that were examples to learn and cherry pick from. Brian felt that standards should precede solutions, although Adam countered that in general solutions precede standards. Ian acknowledged that he could think of several instances where that was certainly true. Adam added that not having a standard in another 10 years would not mean that there would no longer be an opportunity for a standard.
Ian felt that much of the work in implementing an SJTAG standard would likely lie with the tool vendors, and noted his opinion that many end users would probably like a "push button" solution for at least the more basic test and programming use cases. At the same time Ian acknowleged that some people may still want fine control. Brian compared this to the synthesis of an FPGA, where some people will want to hand optimize to get the most out of it.
Adam asked where the test would be employed or deployed - is it manufacturing test or debug? Ian replied that from his perspective, much of the value might come after system delivery, but that in the field there would also be BIT available.
Ian noted that his perspective was probably oriented towards high value, low volume products and wondered if there was some perspective needed from a volume manufacturer, but then concluded that high volume products could likely apply resources to provide custom test and debug solutions that may make SJTAG largely irrelevant. Adam remarked that custom fitted and high value solutions maybe SJTAG's prime sector, although Tim Pender's field may fall more into the volume/off-the-shelf market.
Ian asked the meeting to consider how we establish the core for a standard. Adam suggested that the most important question might be who is going to take delivery of items conforming to the standard, and that we should identify the key beneficiaries.
Anthony suggested that we should ask ourselves where the pain is. Ian picked up on this and wondered if in all the deliberations we had maybe forgotten what the key factors were that caused the formation of the group in the first place: That was probably the "pain" in 2005, but things have moved on and what was troublesome then may be less so today and vice versa. Ian thought that revisiting those early drivers might give some focus.
Adam opined that the challenges for SJTAG may be its ease of use, its efficiency and it's effectiveness: How quickly can we build a test solution? With how little effort? How well does it perform its task?
Anthony recalled that test patern re-use had seemed to be a big factor in the original discussion, and this led onto questions of interchange formats for both test and results, with Adam adding that SVF or better STAPL are what we currently have readily available for transferring tests although some format to transfer results back was needed, and that at least some tool vendors have already implemented proprietary formats for return transfer of test results. The first step may be to define the data format to return results to the environment that originated the vectors so that diagnostic processing can take place in that environment. Heiko added that the next step might be to somehow carry forward some information that will allow for diagnostics in another environment (i.e., not the environment that originated the vectors).
Adam thought tool vendors would be happy to implement standards if they exist.
Heiko commented that IJTAG has both ICL and PDL, although it should also be noted that it does not necessarily assume the use of 1149.1. Ian also noted that the 1149.1-2012 update proposals are also utilising PDL, and looked like it offerred a possible route to solving the "multiple BSDL problem" among other things. Ian also noted that while PDL may not prove to be the ideal solution, there was a logic in remaining consistent with P1687 and 1149.1 on language choice, Adam and Heiko agreeing.
3. Review new action items
There were no specific action items from this meeting, although Ian aims to carry forward some of the discussions into the weekly meetings.
Meeting adjourned at 13:08 PM PDT.