Minutes of Weekly Meeting, 2015-07-13

Meeting called to order: 11:05 AM EDT

1. Roll Call

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

Adam Ley
Michele Portolan

2. Review and approve previous minutes:

  • Approval of July 6 minutes (draft circulated 7/6/2015):
    • Correction in Glossary definition for 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".
    • Eric moved to approve as amended seconded by Peter, no objections or abstentions.
    • New forum thread on definition of "Instrument" (http://forums.sjtag.org/viewtopic.php?f=13&t=730) - discussed in 5a.
  • {Tim joined}

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.

  • {Brian joined}
  • Further email exchanges had taken place regarding the definition for the general case of 'Instrument'.  These have been added to the existing forum thread (http://forums.sjtag.org/viewtopic.php?f=13&t=730).
  • Since Michele was one of the main participants and not on the call, Ian felt that while it would be nice to close this out it would be better to let the discussion continue "off-line".
  • Tim asked if the instruments were slaves only or if they could be masters?  This was a good question. Ian wondered if it actually made any difference to us. Brad felt it could, with regards to what access link you used.
  • Brad noted that there are a lot of cases where the target instrument is not directly accessible; an example is an instrument that is controlled via I2C Master, which in turn is driven from an AXI Master off an FPGA. That cannot be described by ICL or a BSDL Package per 1149.1-2013, so it is outside the scope of what current tools can handle.
  • Ian described driving an SPI or I2C device directly from an FPGA's IO pins - effectively using the BSR as a virtual Master. Brad added that he'd also done that and created custom BSRs for large FPGAs where it became slow due to the large number of cells. All of this is different to what a typical device tester would do and we need to support and describe it.
  • We can define the above as the Master but we also need to define the Target. We can have a certain target that is maybe I2C, but an I2C Master can talk to multiple targets.  This is key to getting reuse.
  • Brad likes Python because it defines APIs through protocols - behaviours and methods.  Define an I2C instrument but then use it as a Black Box.  You can have an algorithm that is target specific and a Master level that sends to that target so that you don't have to re-write that top-end for every target.
  • Important to note the use of BSR as a Virtual Master as it could be the basis of a Flash Writer, I2C Master or SPI Writer.
  • Brad wondered if we should be modelling Protocol Bridges in a similar manner to Gateways.

b. Try to identify pictorially what we mean by our Scan Operation.

  • Brad noted that we were starting with the three blocks "Pre-conditioning", "SJTAG Operation" and "Post-conditioning".
  • Start by defining what we mean by SJTAG Operation:
    • JTAG cycle (IR or DR) - can be a specialised operation for 1687 or 1149.7 command level.
    • Support for I2C or SPI (plus others) - specialised into e.g. SMBus, PMBus.
  • Brad wanted to compare with how 1687 iApply handles parallel IO.
  • {Diagram shared}
  • The 'Parallel I/O time frame' is equivalent to our 'Pre-conditioning', the 'Scan time frame' is our 'SJTAG Operation'.  There isn't really a 'Post-conditioning' here - it's kind of in the backward loop at the bottom of the diagram and another iApply can be performed.
  • The shift sequence is Cature-Shift-Update with permissible No-Ops (Nop): Non-standard sequences can be performed by looping the sequence and using the Nops.
  • Our diagram is unlikely to be as simplistic as we have more protocols to deal with.  Decomposition may be the best approach in the document, to draw people in gradually.
  • Ian asked if this kind of diagram was what Brad had in mind at the outset. Brad agreed it was. Ian noted that while it was possible to create diagrams like this with greater complexity, they soon become difficult to read. Brad felt many things could be abstracted to higher level "bubbles"; the specialisation can be added as you dig deeper.
  • Even though you work bottom-up you can expand as you get into more detail, e.g. an I2C operation can be specialised into PMBus or SMBus.
  • We can try to start diagraming this for the next meeting, possibly starting from the "Pre-conditioning", "SJTAG Operation" and "Post-conditioning" blocks. Can probably come up with something representative of the JTAG Sequence: Even though we might not have a Capture that takes place it might be simpler because we still have to go through the Capture state.  We'll possibly end up with the TAP state machine!  For I2C we'd define the addressing and data frames.
  • Brad offers to try and draft some diagrams {ACTION}.

6. Topic for next meeting

  • Try to identify pictorially what we mean by our Scan Operation. (Continuation)
  • Start defining what activities need to be done during pre-conditioning.
    • Brad: Chain selection is probably what will be in pre-conditioning.  Need to define ways the tooling can understand what needs to take place, including for I2C, SPI, etc.  Diagrams will probably look identical to the SJTAG Operation diagram.

7. Key Takeaway for today's meeting

  • None.

8. Glossary terms from this meeting

  • None.

9. Schedule next meeting

  • July 27
  • No meeting July 20: Ian and Heiko out, Brad may also be unavailable.

10. Any other business

  • ITC needs to be considered.  Probably a Poster is the only option we have now.
  • Michele's paper has been turned down and he has the option of presenting a poster instead. Would overlap with our poster so looking for ways to use our poster and tie it into his demo.  Follow this up in future meetings.

11. Review new action items

  • Brad - Draft diagram(s) to illustrate the SJTAG Operation.

12. Adjourn

  • Eric moved to adjourn, seconded by Brad.
  • Meeting adjourned at 12:02 PM EDT

Thanks to Heiko for providing additional notes.

Respectfully submitted,
Ian McIntosh