[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-08-17

Meeting called to order at 10:51 AM EDT
(The meeting was delayed to allow anyone who had attempted to use the old meeting number to rejoin)

1. Roll Call

Ian McIntosh
Brad Van Treuren
Carl Walker
Eric Cormack (joined 10:54)

Excused:
Patrick Au
Tim Pender
Heiko Ehrenberg
Peter Horwood

2. Review and approve previous minutes:

8/10/2009 minutes:

  • Draft circulated on 10th August:
  • As there were insufficient members in attendance, approval was deferred until the next meeting.

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)
  • Adam review ATCA standard document for FRU's states
  • All to consider what data items are missing from Data Elements diagram
  • 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/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • Harrison: Virtual system exploiting Configuration/Tuning/Instrumentation and Root Cause Analysis/Failure Mode Analysis Use Cases. - Ongoing
  • Brad: Virtual system exploiting POST and BIST Use Cases. - Ongoing.
  • Ian: Virtual system exploiting Environmental Stress Test Use Cases. - Ongoing
  • Ian/Brad: Construct new langauges/layers question(s) based on Brad's previous graphic to replace Q3.5. - CLOSED (See discussion topic).
  • All: Test at least part of the draft survey form and provide comments through forums. - Ongoing.
    http://www.sjtag.org/survey/forms/form1.html
    http://forums.sjtag.org/viewtopic.php?f=32&t=83.
  • All: think about topics for upcoming SJTAG newsletter. - Ongoing
  • [Brad] I've had no time to think about the action on Question 3.5; maybe we can do that dynamically?
  • [Ian] Since we have such a small group on the call this week, and we're late starting, that might be a good use of our time.

4. Discussion Topics

  1. 2009 Survey - Languages and Interfaces questions
    • [Ian] Question 3.5 is the one where we basically list a lot of languages might be used in some connection with BScan. I think we were trying to see how these related to the interface layers in Brad's diagram.
    • [Brad] I'm just trying to open the form.
    • [Ian] I found it quite quickly today. I'll just try to share my Browser.
    • {Eric joined}
    • [Brad] The question was raised during the meeting of 27th July.
    • [Ian] Most of the languages we have listed probably apply at the application layer; From Test Program and Test Step Flow Control and below we really only have SVF and STAPL.
    • [Brad] My graphic is on the website, in the BTW 2006 Presentation (http://files.sjtag.org/BTW2006/BTW2006-Van-Treuren.pdf) slide 8 and expanded in slide 9.
    • [Ian] This shows only SVF and STAPL, and those may not do enough for us.
    • [Brad] For Scan Operations, the question is how you interface to them. There are primitives that are common between SVF and STAPL: These are what Gunnar termed his Leaf Functions.
    • [Brad] I think we need get the user's perspective and ask what a language needs to do for them. Then we can formulate more questions around the layers.
    • [Ian] Maybe we shouldn't expect people to understand the layers here?
    • [Brad] So we ask a simpler question that lets us know the level of sophistication of the user.
    • [Ian] I think there was something similar elsewhere - in 6.1 we ask about levels and interfaces.
    • [Brad] OK, so in Section 3 we maybe just go for the very basic "Do you feel SJTAG needs a standardized language for JTAG in a system?" with 'Yes', 'No', 'If No, why not?' responses.
    • [Ian] Do we still need a question like 3.5, that lists a whole raft of languages?
    • [Brad] I had something like it in my 2006 survey, but I didn't find it very useful. I got a whole spread of answers that didn't really tell me anything.
    • [Carl] I agree. What is the objective of the question? Is it to find what we might need to interface with.
    • [Ian] I don't think it was even that; just to find what people were using, but with so many options and a relatively small number of users, we'll likely not learn anything worthwhile.
    • [Brad] Over time, I've been thinking differently about this. I get wary with using pure SVF and even STAPL users have issues in terms of concurrency, which is why Gunnar created his STAPL++. I may be more sophisticated than many other users because I've been doing it longer, but I think it's the way the industry will go. The current languages are going out of date.
    • [Carl] Some of those languages just don't relate to BScan or don't offer any more in terms of concurrency. I'm not aware of Perl having any construct to support concurrency.
    • [Brad] There's a question of whether concurrency is inside or outside of SJTAG? The same thing came up in P1687; whenever concurrency was mentioned, I was told it was an SJTAG issue.
    • [Carl] Concurrency seems fundamental to SJTAG.
    • [Brad] But could that come from some other standard. We can maybe only achieve standardization of interfaces and the languages themselves.
    • [Ian] That maybe make sense for the tool vendors who may have invested heavily in their own languages.
    • [Brad] The Simplified Wrapper and Interface Generator (SWIG) was discussed in P1687, which allows C/C++ to interface with virtually every other high level language.
    • [Brad] Maybe another question is "Is it sufficient to only standardize Interfaces for each application layer?"
    • [Ian] OK, but isn't that asking the user to know what the application layers are? This may better in Section 6.
    • [Brad] I see what you mean. Yes this should be the lead-in to 6.1.
      • [Brad] Maybe the simpler question to ask is "What languages are your BScan applications written in?" From that we can tell something of the sophistication of the user.
    • [Ian] OK, those choosing a), b) or k) are basically just using the output from their tools, the other are trying to do a bit more.
    • [Brad] Maybe there should be an option "whatever my tooling provides".
    • [Ian] Isn't that what k) is?
    • [Brad] Almost. I don't know any engineer who'd admit to not knowing what language his tooling uses.
    • [Ian] So you're suggesting we remove the "I don't know" element from k) to reduce any embarrassment factor?
    • [Brad] Yes, that would do.
    • [Brad] Maybe we should strike HSDL from the list, and add another question to ask if the user has a description for the circuit under test. Most tooling seems to have some sort of description, although some will extract the information from the netlist.
    • [Brad] Another question is "Do people have a way of describing the assembly of modules?"
    • [Ian] That's something we've raised before; that the system assembly is usually outside of CAD, so there's no netlist to import.
    • [Brad] Even in HSDL you don't get that information, just the scan connectivity.
    • [Ian] I'm just checking what questions we have now. Brad, was the last question a development of the previous one?
    • [Brad] No, I think there are two questions there. The latter gets to the dynamic aspects and the instances of boards: That this reference to IC6 actually means the one on the third board. One of the problems with the way people are implementing HSDL causes problems in handling multiple instances as you include more modularity.
      IC6, as a member of a board module, might not really be unique enough when multiple instances of that board are assembled into a system or sub-system with some implementations.
    • [Brad] I just though of another: "Do you feel we need to support modularity of data (re-use of assemblies, boards within boards, etc.)?"
    • [Ian] Wasn't that why we were thinking in object-oriented terms?
    • [Brad] It doesn't need object-orientation to deal with the instances: CAD creates instances of devices without needing to use objects. The real problem domain is in the collection of other assemblies.
      In netlists, we have device types defined that represent commonality of devices or reuse of information and device names to provide instance delineation. A netlist[NOTE 1] is not really an object-oriented format, but the information provides the partitioning of information into collections as such.
    • [Ian] OK, do feel we have enough for today?
    • [Brad] Well, have we enough to say we've closed the action?
    • [Ian] That's six questions; I think it's enough to close it.
       
    • NOTE 1: Editorial comment: netlists are really serialized representations of circuit databases that provide human/machine readable forms. It is the relations established that the tools are interested in (e.g., set of pins associated with a net; attributes of a device, port, or net; constraints).

5. Schedule next meeting

Schedule for August 2009:
Monday August 24, 2009, 10:30 AM EDT
Monday August 31, 2009, 10:30 AM EDT

Expected absences: Heiko 24th, Peter 31st.

6. Any other business

None.

7. Review new action items

None.

8. Adjourn

Brad moved to adjourn at 11:43 AM EDT, seconded by Carl.

Respectfully submitted,
Ian McIntosh

Copyright 2007-2009 The SJTAG Working Group
The SJTAG Initiative is "work-in-progress" and the views and opinions expressed here are subject to change without prior notice.