Minutes of Weekly Meeting, 2017-02-27

Meeting called to order: 11:05 AM EST

1. Roll Call

Ian McIntosh
Brian Erickson
Bill Eklow (left 11:27)
Eric Cormack
Carl Walker
Brad Van Treuren

By Proxy:
Peter Horwood


2. Review and approve previous minutes:

  • Approval of February 15 minutes (updated draft circulated on 02/22/2017)
    • No further corrections.
    • Brad moved to approve, seconded by Eric. 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.

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.

  • {Brad shared the spreadsheet that was created during the previous meeting}
  • Brad noted that he had not thought of anything to add to the table since the last meeting.  Ian suspected that we'd find some of the interfaces to be of limited use to us.
  • Brad related a discussion from the 1687.1 meeting where he had tried to describe our intent to use "dot releases" to define how we were leveraging each standard. The 1687.1 team felt it was more important to do things in the core standard as appendices, as this avoids going through the entire PAR process with TTSC each time.  Brad felt that might mean we needed to prune down our list.
  • Ian agreed that the main interfaces were those derived from 1149.1 plus I2C and SPI. Brad started to mark a new column in the spreadsheet to show the interfaces deemed to be most significant.  This was mostly 1149.1 related standards but Brad remarked that this did not account for volume and other interfaces may actually occur more frequently.
  • Brad wondered, with regard to I2C and SPI, whether we intended to support only 1687.1 or also legacy implementations. Ian wasn't sure but thought that there were a lot of I2C and SPI devices already around and, with SPI in particular, a lot of different ways of using those buses. Ian felt that if the interfaces could be described generally enough to cope with those variations then 1687.1 would be covered anyway.  Brad though that ought to be possible for the AccessLink and we didn't really care about what the data is.
  • If the AccessLink for 1149.1 is supported then that probably also solves for 1500, 1687, etc.  Ian suggested that we maybe need to show what interface are derived or inherited from another standard. Brad added a further column to the table to show this.
  • Peter Horwood, by email:
    • In relation to the access link, the specification of 4 wires at a specified voltage standard would be generic and cater for 4 wire standards such as 1149.1, SPI and multiple instances of  2 wire standards I2C , 1149.7
    • The user can then build a system as required for that implementation.
  • Ian commented that in his experience I2C and SPI interfaced devices were almost always connected to a FPGA, PLD or Microprocessor - generally something on the board needed to access the data for the device, so the interface had no need to be presented externally. Brad noted that this was a proxy - indirect control via a programmable controller. This also led into the realm of emulated control via the BSR.
  • Brad noted that in modern designs you will always find something that is doing board management - monitoring temperatures, bringing up power, etc., and it is often the FPGA that needs that temperature and health data. Ian wondered how this would impact on SJTAG. Brad suggested that such emulated control might include a JTAG to I2C bridge, or a memory mapped controller or a built-in engine implementing an AXI Bus interface.
  • Brad thought this might mean that we'd need to provide a PDL type of interface where you describe simple reads and writes for the commands that need to be sent to the indirect controller.
  • Brad also noted that this was the "top end" and we still need to define  the low level support.
  • Brad noted that the following were probably key takeaways from today's discussion:
    • Many interfaces are inherited from the "core" standards, so may have de facto support.
    • Support for indirect and emulated control is a value add for tool vendors and not necessarily part of our standard. May be a "dot" standard.
  • Although hardware usually becomes available before software, software that is part of the product could be leveraged as it will often talk through the indirect interfaces. Ian remarked that he found firmware or software was often used to support tests long before any formal manufacturing tests for the hardware were ready. Brad noted that was usually only the case where the product was a development of an existing one and not a "bleeding edge" new product.
  • The current spreadsheet is available on the File Manager here: http://files.sjtag.org/Brad/StandardsTable20170227.xlsx.

b. Process for going to TTSC/Study Group.

  • {Not discussed due to lack of time}

6. Topic for next meeting

  • Process for going to TTSC/Study Group.
  • Building Blocks - table of standards.

7. Key Takeaway for today's meeting

  • Many interfaces are inherited from the "core" standards, so may have de facto support.
  • Support for indirect and emulated control is a value add for tool vendors and not necessarily part of our standard. May be a "dot" standard.

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 March 6.
  • March schedule:
    • 13, 20, 27.

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

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

Respectfully submitted,
Ian McIntosh