Minutes of Weekly Meeting, 2015-03-09

Meeting called to order: 11:06 AM EDT

1. Roll Call

Ian McIntosh
Brian Erickson
Carl Walker
Heiko Ehrenberg
Tim Pender
Brad Van Treuren
Bill Eklow (joined at 11:32 EDT)
Eric Cormack (joined at 11:53 EDT) 

Adam Ley
Michele Portolan

2. Review and approve previous minutes:

3/2/2015 minutes (draft circulated 3/2/2015):

  • |No corrections noted;
  • Tim moves, Brad seconds to approve;
  • No objections; -> minutes approved

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. Group officers - candidates for office and reaffirmation - continuation.

  • After considering offers by others (e.g. Michele, Heiko) to help with taking notes, and last week's discussion, Ian offers himself up as chair (perhaps to be considered acting or interim) until a new volunteer for the chair position is found;
  • Heiko suggested that the SJTAG group as a whole would very much appreciate Ian staying on as chair;
  • Brad asked if we should vote on the appointment of note-takers;
  • Ian said that that may not be necessary, as we probably don't need to create that as an "office" so long as we make sure that someone helps with recording the notes;
  • Brad agrees that it should be sufficient to record in the minutes that, Ian stands as acting chair contingent on another person filling the position as note taker;
  • MOTION: Brad makes a motion to approve Ian as acting chair for this year, Brian seconds; no objections; motion approved;
  • MOTION: Tim moves to approve Heiko as acting vice chair for this year, Carl seconds; no objections; motion approved;

b. Revisit draft PAR statements - continuation.

  • Ian poses the question whether the three headings we discussed in February provide enough contents for a SJTAG base/core standard:
    1. Address level immediately above 1149.1
    2. Include a transportable description of gateway type devices
    3. Accommodate alternative interfaces to 1149.1
  • Brad feels that there are things missing for what SJTAG needs to cover while 1 and 3 are related, both concerning access mechanisms where 1149.1 is simply the first example.  Ian suggested then that we should perhaps have the heading of "Access Mechanisms" instead to cover both 1 and 3.
  • Brad notes that there are configuration protocols required to set up an access link and there may then be subsidiary commands to use it.  Sub-standards then would need to address specific requirements for certain access mechanisms (such as IEEE 1687, or I2C, for example).
  • Tim sees I2C only as a control mechanism, not a data transport mechanism.  Brad notes that some people say the same about 1149.1. It was also noted that I2C limits the data in any frame to 8 bits so buffering would be needed to shift longer data streams, so perhaps a standard might only allow certain register topologies to be compatible with SJTAG.
  • Brad sees the other aspect of the core standard then to be the data link flow aspect of the transaction, just as 1687 has a state machine type flow using the capture-shift-update cycle.
  • {Bill joined}
  • A useful addition to 1687 was creating states where parallel IO could be inserted.
  • Brad notes that if SJTAG wants to be successful we will need to consider more than just 1149.1 / JTAG as allowable access mechanisms.
    1. Define minimum requirements for Access Mechanism
    2. Address level immediately above Access Mechanism
    3. Transportable description of gateway type devices
  • Brad states that we need to decouple the control/configuration flow (connection to the data register) from the data transaction flow (transmission of data into the data register) {Key Takeaway}. Each Access Mechanism may behave differently {Key Takeaway}; we need to define the concept of Access Mechanism in the core standard and then have sub-standards define the actual protocols for the various access mechanisms.
  • Ian wondered if the core standard could address an abstract, generalised form for all interfaces.  Brad felt you could describe an abstract operation but each would be controlled differently.  The control protocol is what needs defined and that could be done in "dot" standards.
  • Bill agrees that defining the documentation is the key of an SJTAG standard (analogous to 1687, but not the same).
    • Define protocol/architecture to help avoid problems,
    • User documents protocols and resources used to program instruments,
    • Document the paths and what is done.
  • Brad notes that we may not always be able to define the complete path between point A and point B, but perhaps sometimes only define point A and a channel that leads to point B (e.g. if point B is a 1687 network, for which there is already documentation).
  • We should be able to look at 1149.1 or 1687 as a protocol, just like SPI.  Bill felt it might be challenging for tooling to work with multiple interfaces although it wouldn't be too bad for the user. Tim added that you needed to understand the topology as there may be multiple SPI devices and you need to be able to select the correct one.
  • Brad consider that we need to configure a particular interface then there is some behavioural function to use that to operate on an aggregate of instruments.
  • Ian wondered if it might be simpler if the core standard addressed only singular instruments, but Brad felt that did reflect reality.  Ian then suggested considering only a single interface within any one "time slot", but again Brad felt that he may have sensors that aren't 1149.1 that he needs to use concurrent with 1149.1 tests.
  • Bill suggests to model a basic system and work through how all of this might work, walking through the different issues.
  • Ian shared the "Board Example" slide (slide 7 in 2013 slide deck). Adding more detail would make such an example drawing very large / complex, but it currently only shows SPI/I2C bridges to the 1149.1 network: A more typical case might be to have I2C or SPI masters within the FPGA driving instruments that used functionally within the design but are then also available for test.
  • Brad notes that this an issue of "indirection" as the FPGA may be controlled via JTAG and this is not covered by any of the existing standards {Key Takeaway}.
  • For Bill's benefit, Brad also notes that we had created templates in the past where we defined examples of different arrangements for SERDES interface tests.  Ian will provide links {ACTION}.

6. Key Takeaway for today's meeting

  • Need to decouple the control/configuration flow (connection to the data register) from the data transaction flow (transmission of data into the data register).
  • Each access mechanism has its own command flow to establish the access.
  • Indirect access to instruments is not addressed by any existing standards.

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • Next meeting March 16. Michele likely to be absent through March.
  • March schedule: 23, 30.

9. Any other business

  • The newsletter is due. Brad is still finding limited time to work on the Green Paper.
  • ITC: Nothing to add.  Bill remarked that the website crashed on final day of submissions

10. Review new action items

  • Ian: Send Bill links to existing material on SJTAG Templates.

11. Adjourn

Bill moved to adjourn at 12:07 PM EDT, seconded by Brad.

Thanks to Heiko for providing the majority of these notes.

Respectfully submitted,
Ian McIntosh