Minutes of Weekly Meeting, 2015-12-14
Meeting called to order: 11:09 AM EST
1. Roll Call
Brad Van Treuren
Bill Eklow (joined 11:11)
2. Review and approve previous minutes:
- 12/07/2015 minutes (draft circulated 12/08/2015).
- No corrections noted.
- Eric moved to approve, seconded by Brian, no objections or abstentions.
3. Review old action items
- All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? See also Gunnar's presentation, in particular the new information he'd be looking for in a test language (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
- Ian: Add the previously discussed lists to the 'master' template. Ongoing.
- Some sections need further expansion that may take time to develop.
- Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
- Establish consensus on goals and constraints
- What are we trying to achieve?
- What restrictions are we faced with?
- Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172
- The Newsletter was due at the end of July. Brad probably has one topic left on his list.
- Try to get Al Crouch on call re 1687.1 - Possibly no longer relevant?
5. Discussion Topics
- Since Michele likely will be the one presenting for SJTAG, if we participate, we wanted to wait for Michele to be on the call before we discuss ETS2 in much detail.
- Ian asked Michele to remind him of the deadline for submission of abstracts. Michele replied that it was the end of January.
- Bill suggested that if it was like BTW then there may be no deadline for "Industry" related presentations (as opposed to research papers).
- Michele added that the deadline was for abstracts only.
- Bill noted that if we wanted to get more content into ETS then we could also consider a paper that was more from the "research" side. Michele responded that the deadlines for both abstract and paper submission on that track had already passed.
- Last week's discussion had leant towards a broad view of SJTAG, with a view to trying to interest more people to participate. Ian felt that was needed to strengthen the team in places such as software where he felt many of the team weren't comfortable.
- Adam's emails had indicated that presenting an open problem was an acceptable topic. Michele felt it was important to get people to understand the problem and the "open problem" approach was best for that.
- Bill added that the usual scenario here was to say "I have a problem" and then people throw out solutions. We could use that kind of forum and maybe an industry session too. In a topic like "System Test" it might be possible to squeeze something in if the topic is short of papers (Bill is a topic chair for ETS).
- Ian felt that, whatever we did, it was important to show all the strands that SJTAG might reach into.
- Ian remained concerned about the timescales, as the holiday period was upcoming and most people thoughts would be elsewhere. Perhaps all we can do in the meantime is try to collect any thoughts, either on the forums or through email.
b. Close in on PAR scope and purpose.
- Ian has transferred the brainstorming thread started by Michele's email to the forums(http://forums.sjtag.org/viewtopic.php?f=3&t=740).
- Ian: Last week we went over our PAR discussion from April. I probably should have bulleted the list of things we concluded:
- The core PAR should be for something fairly basic
- Add to the core through extensions
- Don't try to solve everything in advance
- Brad: What worries me is that we don't have a handle on how to leave a hook to the extension.
- Heiko: I don't know that we need to, for the PAR. While we need to specify that in the standard itself, our PAR may just need to hint at just requirement (defining such hooks as being part of our scope), avoiding to have to put too much detail into the PAR, considering that we don’t know yet what those hooks might look like.
- Ian: Michele's email from last week pointed out that 1687's PAR wording was too vague in some places and too strict in others.
- Brian: We've got people here with experience of PARs, so I'm sure we can use their experience.
- Ian, Brad: So did 1687!
- Bill: Adam would be key for the PAR. He's been on several groups and has a very good background on all the IEEE1149.x type standards, and was a key contributor to the 1149.6 PAR.
- Ian: In a previous discussion with Rohit, we were tending towards our own number. Since we envisage dot extensions, Rohit wasn't keen on "double dots" (1149.x.y).
- Brad: If you drew a Venn diagram, SJTAG would be a superset of the other standards. 1687, for example, is non-compliant with 1149.1 due to the variable register length, but we need to encompass both.
- Bill: You have an architecture which aggregates the 1149 family but also things outside of that.
- Bill: Once you have your PAR, you have a fairly long time to get something done. But there are still challenges there.
- Ian: I think we'll need to deliver something of value in relatively short time, much less that the nominal 10 years.
- Brad: Yes, given that we've running for almost that long industry would expect something quicker.
- Bill: There is precedence for a short timescale (e.g. 22 months) but probably more precedents on going over.
- Ian: The problem we have within this group is that everyone's time is limited outside of these meetings.
- Bill: Getting a PAR can draw in people. If you have the right people you get consensus pretty quickly. The PAR gives you perspective on what is going to be in the standard.
- Brad I still see confusion on what is going to be in the base standard: Is it minimalist, based on 1149 and treating access paths and data paths as extensions?
- Bill: It's possible that you don't define the interfaces in the PAR, especially if you have a lot of interfaces.
- Ian: I think's where we saw the "dot standards" coming in.
- Michele: For the PAR, there are maybe some ways in which you can abstract any access interfaces; maybe it is not possible, but that can only be decided when doing the standard. Part of this software so may be solved in software but looks difficult from the hardware side.
- Brad: If we have a generic base standard and make 1149.1 support a dot standard, are we committing to having two parallel standards in development?
- Michele: I think you can start from JTAG. We need to find the right wording.
- Brad: Ambiguous wording in 1687's PAR was a problem.
- Ian: This is where we could use the help of Adam.
- Brad: Something originating from the JTAG domain but exclusively that.
- Bill: I can see if Ken Parker can dial in - he's good at problem solving. Ken and Adam may be able to add some valuable comments.
- Ian: Adam has previously remarked that some statements we've arrived at were close to the essence of a PAR, the bullets we put on the poster we used at ITC for instance. They were only one-line comments though.
- Brian: I would appreciate participation from Ken and Adam.
6. Topic for next meeting
- ETS2 (continued).
- Close in on PAR scope and purpose (continued).
7. Key Takeaway for today's meeting
8. Glossary terms from this meeting
- 'Instance' (or a more specific version of the term) may require definition in future.
9. Schedule next meeting
- December 21 call cancelled due to several expected absences.
- Wednesday proposed for meetings commencing in January. This seemed to suit everyone and was preferable in a few cases. In particular, it should allow Adam to join more regularly.
- Next meeting January 6, 2016, 11:00 AM EST.
- January schedule:
- 6, 13, 20, 27.
10. Any other business
11. Review new action items
- (Ian may try to distil concise glossary definitions from the previous discussions).
- Eric moved to adjourn seconded by Brad. Meeting adjourned at 12:04 PM EST.
Thanks to Heiko for providing additional notes.