Minutes of Weekly Meeting, 2015-07-06

Meeting called to order: 11:05 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Peter Horwood
Carl Walker
Heiko Ehrenberg
Brad Van Treuren
Brian Erickson (joined 11:07)

Adam Ley
Michele Portolan
Tim Pender

2. Review and approve previous minutes:

  • Approval of June 29 minutes (updated draft circulated 7/1/2015):

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.

4. Reminders

  • 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

5. Discussion Topics

a. Definition for Instrument.

  • Michele had previously proposed that an Instrument was "anything that can perform an operation".  Ian had since posted that the Glossary already contained two definitions for "Instrument"; a general one and one specifically for 1687 {forum post shared}.
  • Ian: How do we want to tackle incorporating the definition of Instrument we came up with last week? Do we still want that, or do we want to refine the one we already have in the glossary?
  • Brad: I wonder if we need to have a general definition for "instrument" and then a definition for a "IEEE 1687" instrument in its various forms.
  • Ian: Does anyone remember if the current 1687 definition we have is our own or was from the IEEE 1687 standard document? 
  • {Brad provided Ian with the definition from the 1687 standard document}
    • instrument: Any on-chip circuit for test, debug, diagnosis, monitoring, characterization, configuration, or  functional use that can be accessed by, configured from, or communicated with by an on-chip network  described in Instrument Connectivity Language (ICL) that connects to an external device interface. An  instrument is typically in a module that has only a client interface. 
  • Ian: So, this definition for "instrument" in our glossary is a derivation of our own and not from the standard.
  • Brian: I’d move that we update our definition for a 1687 instrument with the wording used in the 1687 standard. 
  • Brad: but not our definition for a general instrument, right? 
  • Brian: yes, that’s what I meant.
  • Brad: I don’t have a problem with our definition for a general instrument. 
  • Ian: I don't think the general definition in the wiki which talks about capabilities for monitoring or control and Michele's are really very different.
  • Brad: The problem I see is that if an instrument is just something that performs an operation, sometimes it may take several actions to perform "an operation". 
  • Ian: So you are proposing not to change our definition for general instrument and only to update the 1687 definition in our glossary? 
  • Brad: Yes, that’s what I would propose. 
  • Brad: So, what would people think of a power manager in regards to being an instrument? 
  • Ian: I’d think that’s a collection of instruments. If we were to consider the suggestion that external instruments could be included then a Power Supply would be similar; it has monitoring and control aspects. 
  • Brad: That is an example of an instrument that needs multiple operations for it to do what the user wants it to do.

b. Clarify terminology related to dynamic scan path configuration devices.

  • {Forum post shared}.
  • Michele had started an email discussion on terminology for these devices:
    • "We had some nice discussion about dynamic elements, but I think we need some clear glossary definition to go on. 
      As of now, I see three terms being used:

        - "Boundary Scan Linkers", from the board testing background;
        - "Scan Muxes" or "SIBs" from 1687
        - "crossroads", from my own terminology and that is used I believe by one person only

      Even though I like mine, I would propose we use the generic term "Linker" for dynamic elements, as it is familiar to most people in the domain, but without being too close to a specific solution. So I propose this entry:

      Linker: any element able to modify the topology of the system depending on its internal state."

  • Ian: Brad responded with an email that noted that some people also use Router as a term for this functionality. 
  • Ian: I checked our glossary again and noted that we already have definitions for Selector and Gateway for this type of device functionality. This probably came out of the development of the Example Diagram where we separated these functions.
  • Ian: I feel that "Selector" implies choosing only one chain, while "Linker" implies one or more.
  • Peter: We call our devices "Gateways". Do we want to define something that is completely different from specific terms used by certain vendors? (using vendor independent terms); something like "SJTAG Infrastructure Device".  Or is that too wordy?
  • Brad: People can be lazy and want a simple term to use. But if we look at networking, Router, Switch and Hub do similar, but slightly different things, and people get confused over why they need them all.
  • Peter: Perhaps, like 1687's SIB, we can have a longer term but use an acronym.
  • Ian: We have JTAG Switch Module (JSM) but I infer that selects only a single chain.
  • Brad: Yes that's right.
  • Ian: We did distinguish between Gateway and Selector in our example drawing as having different functions and therefore needing separate definitions; these terms may make sense to us but people who don’t know the difference may use them interchangeably, thinking they are the same thing. It's difficult to impose new "rules" on previously established usage.
  • Heiko: Why do we need to define a new term? Is it to combine Gateway and Selector into one term? 
  • Ian: Maybe we don’t need a new definition and just need to make sure the definitions are clear enough for people to understand the differences. "Router" is defined in the Glossary as a generic term for both.
  • Brad: If we make the definition clear enough we may be just fine with Selector. We don't want to deal with each separately as multiple definition implies multiple interfaces and we want to have just one interface.
  • Ian: One distinction is that one of these interfaces the upstream chain (Gateway) and the other interfaces the downstream chains (Selector).
  • Brad: Possibly only the TI LASP presents a problem by combing the gateway selection and chain selection in the same step; for most other devices that requires separate actions.
  • Ian: The designer probably won't be aware of how the selection gets carried out, so won't appreciate the difference between a Gateway and a Selector. 
  • Brad: The same argument could be applied to the Brocade with the I2C configuration. In fact the designer won't care, as it's the Test Engineer who will deal with the issues.
  • Heiko: Why don’t we change the definition for Router to allow also to be used for devices that includes both the Gateway and Selector functionality?
  • Brad: Make it refer to Gateway and/or Selector.
  • Ian: Yes, that was probably what was originally intended anyway.
  • Brad: We want to fit in the reference to "upstream" and "downstream" in revising the definitions.

6. Topic for next meeting

  • Try to identify pictorially what we mean by our Scan Operation.
  • Start defining what activities need to be done during pre-conditioning.

7. Key Takeaway for today's meeting

  • None.

8. Glossary terms from this meeting

  • Instrument (general) - A device or feature within a device that provides a capability for monitoring or control, e.g. monitoring of device temperature or tuning of a SERDES link. See also Hierarchical Instrument. {Unchanged}
  • Instrument (IEEE 1687) - Any on-chip circuit for test, debug, diagnosis, monitoring, characterization, configuration, or functional use that can be accessed by, configured from, or communicated with by an on-chip network described in Instrument Connectivity Language (ICL) that connects to an external device interface. An instrument is typically in a module that has only a client interface.
  • Gateway: A device used as part of a chain selection mechanism and that provides an interface to the upstream topology, typically to selectively provide access to the scan chain(s) of a board from a multi-drop bus.
  • Selector: A device which provides an interface to the downstream scan chain(s) and links one or more scan chains into a chain accessible by the SJTAG Control System.
  • Router: From the SJTAG perspective a Router is a generic term describing devices that offer the functionality of a Gateway and/or a Selector.

9. Schedule next meeting

  • July 13
  • July schedule – 13, 20, 27

10. Any other business

  • None.

11. Review new action items

  • None.

12. Adjourn

  • Brian moved to adjourn, seconded by Eric.
  • Meeting adjourned at 11:58 AM EDT

Thanks to Heiko for providing extensive notes.

Respectfully submitted,
Ian McIntosh