Minutes of Weekly Meeting, 2017-03-27

Meeting called to order: 11:08 AM EDT

1. Roll Call

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

By Proxy:

Heiko Ehrenberg
Bill Eklow

2. Review and approve previous minutes:

  • Approval of March 20 minutes (draft circulated on 03/20/2017)
    • Eric noted that the first date in the April meeting schedule should be April 3.
    • Brian moved to approve, seconded by Carl. 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.
  • Heiko - Raise AOB item at TTSC meeting to express our interest in forming a study group and enquire what material we would need to support the request. Ongoing.
    • Ian will leave this action open until after the TTSC meeting.

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
  • Possible invitation for Al Crouch to talk about Parallel SIBs.
  • Python Netlists (SKIDL) suggested by Brad for discussion.

5. Discussion Topics

a. Building Blocks - "Middleware".

  • Ian noted that the sub-title here was simply a reminder of where we left off: That there may be a Command/Response behaviour that may sit either above or independently of a CSU cycle. Ian had also mentioned the case of polling an instrument repeatedly for data without ever sending a command.
  • Brad noted that there could be "commands" in the problem domain and "commands" related to the physical interface and they are not necessarily the same. We may need glossary definitions for both of these.
  • Ian felt that, just as we had described that the CSU cycle may have null or ignored capture or update data, the command/response cycle may have a null command (the instrument polling mentioned above) or even have a null response.
  • Brad wanted to share some slides that showed some things that were being considered by the 1687.1 group as they may have a bearing on how we viewed things {slidepack shared}.
    • Hardware implementation from code
    • Example grammar - shows four opcodes, two are:
      • SWC - Shift, With Capture
      • SNC - Shift, No Capture
    • TMS pattern from IEEE1149.5 for SWC and SNC
    • Slide showing an embedded TAP master controlling the target device
    • Jeff Rearick adaption of this to replace the TAP master/TAP controller with a 1687 network TDR.
  • Brad asked if SJTAG was providing the AccessLink and DataLink without knowing anything about the data, just knowing when something needs to be sent and when something needs to be read. Do we ignore the "intent"? Ian thought it would be difficult to determine the intent - where would it come from? 
  • Brad suggested that there could be attributes for the interfaces, e.g. what is the fixed width of data that can be absorbed by the interface? Width is not necessarily fixed and both Ian and Brad pointed to 1149.1-2013 as an example, and the width needs to come from somewhere else; the "state" of the device would need to be tracked. Brad described this as dealing with sub-networks, not just an interface.
  • The TDR and the SIB could have attributes that describe what length to use. In 1149.1 this becomes a proxy, so you could have a proxy talking to a proxy!
  • Brad suggested trying to record the commonalities between 1149.1, I2C and SPI, and open a new spreadsheet for this {shared}.
  • Once this had been populated a little from suggestions, Ian remarked that what it maybe showed was that there were reasonable similarities between 1149.1 and SPI but that I2C seemed to be almost the opposite of the other two. Without thinking about it, Ian had expected I2C and SPI to be most similar. Brad suggested that this was because I2C was patterned after a bus architecture while 1149.1 and SPI were patterned after a serial protocol.
  • Brad suggested that SPI might adhere to the CSU cycle but Ian wasn't convinced that there was any fixed rule about latching or capturing data prior to clocking out, and thought that the data from an AD7888 ADC may vary depending on how quickly it read out after the conversion was triggered. In any case, the point was that SPI had a less rigorously defined protocol that either I2C or 1149.1.
  • {Peter joined} Brad summarised the table for Peter and suggested that he could look it over once the notes were circulated. Peter asked if we were talking about translating from one interface to another, and Ian explained that we actually considering what (and if an) abstraction of the interface was possible. 
  • The new spreadsheet is available on the File Manager: http://files.sjtag.org/Brad/CompareContrast20170327.xlsx.
  • Emailed comments on the spreadsheet from Peter:
    1. I2C fixed data width: from the spec there is no restriction on the data transmission:
      "Byte format
      Every byte put on the SDA line must be eight bits long. The number of bytes that can be transmitted per transfer is unrestricted. Each byte must be followed by an Acknowledge bit. Data is transferred with the Most Significant Bit (MSB) first (see Figure 6). If a slave cannot receive or transmit another complete byte of data until it has performed some other function, for example servicing an internal interrupt, it can hold the clock line SCL LOW to force the master into a wait state. Data transfer then continues when the slave is ready for another byte of data and releases clock line SCL."
    2. Bus Architecture: Using a Gateway device you can create Multi-drop buses on the 1149.1 bus.
    3. Parallel Protocol Architecture: Using a Gateway device you can access all or selected groups of devices on the 1149.1 bus.
    4. Variable Data Width: For 1149.1 we have specified TDI and TDO which do not vary so question the X here, it should be in the Fixed Data width row. Yes, for SPI there are variants, single bit, Dual, and Quad access.

6. Topic for next meeting

  • Building Blocks - Abstraction, translating from abstract to a specific interface.

7. Key Takeaway for today's meeting

  • Physical interface commands and problem domain commands may be different.

8. Glossary terms from this meeting

  • Carried over:
    • Definition of "interchangeability" required.
    • 'Instance' (or a more specific version of the term) may require definition in future.
    • 'Master through Slave Mode'
    • 'Master to Master Mode'
    • Need a refined definition of "system" for the purposes of the PAR.
    • 'Priority' - may relate to 'frequency' and 'urgency' in distinct definitions.

9. Schedule next meeting

  • Next meeting April 3.
  • April schedule:
    • 10, 17, 24.
    • Heiko and Brian are out April 3.
    • 17 is Easter Monday but does not appear to affect attendance.

10. Any other business

  • Ian hopes Michele will be able to provide a fuller report on the TESTA tutorial in due course.

11. Review new action items

  • None.

12. Adjourn

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

Respectfully submitted,
Ian McIntosh