Minutes of Weekly Meeting, 2017-04-24

Meeting called to order: 11:04 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Brian Erickson
Carl Walker
Brad Van Treuren
Heiko Ehrenberg
Peter Horwood

By Proxy:

Bill Eklow

2. Review and approve previous minutes:

  • Approval of April 17 minutes (updated draft circulated on 04/19/2017)
    • No further corrections.
    • Brian moved to approve as amended, 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 - Use Case of a simple Interconnect Test - Continued.

  • As a follow-up on Peter's proxy comment on the previous notes, Ian agreed that the diagram presented last week was correct for a conventional 1149.1 case while Brad's suggested alteration may not be possible in many 1149.1 devices and so asked if Brad's intent was to have a model that could be applied to all three interfaces even if not necessarily in all cases. Brad responded that this was the hybrid case, a mix between pure 1149.1 and instrument accesses. A retargetter would need to know that the BSR is being used rather than an instrument as it is really a different AccessLink.
  • Ian also wondered if perhaps our earlier discussions of the interface attributes had maybe missed that for 1149.1, data is output at the same time as data is input to a device. That was different from I2C where reads and writes are always separated in time.
  • Peter added that his comment covered more than mentioned above: In the "Cloud Model", we'd previously talked about having data and that we want it to end up at some place and what happened in the "cloud" in between was up to the vendor - this did not seem to be what was now being described.  Peter went on to talk about IP protection (the "black box" approach) and asked if you'd always want another vendor to be able to generate your vectors.  Ian was unsure that IP was necessarily exposed by revealing how registers were accessed but was prepared to accept that there may be cases where the operation of device needed to be obscured and "pre-packaged" vectors supplied to achieve some particular end-result. Brad referenced an example of a device where SPI commands are used to program registers, but the vendor no longer supplies the commands but instead supplies libraries of function calls that perform particular operations. The point was that a vendor could supply some form of executable in order to protect their IP. Ian felt that an "executable" wouldn't be very portable and something that could be interpreted or compiled for the particular host would be better for the end user, but acknowledged that a binary form better protects the vendor's IP.
  • Brad noted that this leads to something that may not run in a PC type of environment and may need some kind of service. Do we need that kind of client-server proxy interface?  Our abstraction will probably allow us to deal with it at a higher level but we haven't really talked about it so far.
  • Brad discussed having firmware to support interfaces to devices hanging off of a FPGA: Could you then just call the firmware functions (this is line 26, "Functional Test SW Commands Control" in the Standards Table spreadsheet http://files.sjtag.org/Brad/StandardsTable20170313.xlsx)?  Ian felt this was really something driven by the Test Designer - while modern tools could support this it wasn't in the scope of the ATPGs.  Heiko commented that at least a config file of some sort would need to be provided. Brad felt it was no different to models used for e.g. a memory to allow tools to generate tests.  Ian considered that the testing of a memory was fairly well defined and the devices commonplace, so it was easier for tool vendors to offer libraries of models.  A comparable model for a firmware interface would probably be end-user created.  Brad responded that the model for any particular Flash devices has to be re-written for another vendors tools, as each vendor uses their own formats. The standardised description could be translated into existing tool formats.  This was in line with Brad's push for the PDL in 1687 to have been translatable into the native language of the tools rather than being inherently executable.
  • [Peter, post meeting note] PDL has been the only mentioned interchange format, as described it can be used to act as a wrapper to provide a method to input vector sequences to tools which will then compile to native formats for execution. However in most cases the these tools will also import SVF/STAPL and translate to a native format (or execute directly which has the same effect). However there are tools out there  that do not support PDL, that just use the current industry standard interchange formats of SVF and STAPL and execute the vectors. Are we being restrictive by only talking about PDL, which would limit the possible tool support.
  • It was agreed that the discussion above was something of a digression, but a subject we may need to return to. To continue with the topic in hand, we should probably concentrate on Input and Output registers.  Then we can look at how we might fit something with a BSR into that.
  • Brad was hesitant to offer to prepare some architecture diagrams to talk around as he didn't feel he could spare enough time. A couple of block diagrams might be possible. Ian felt something like that was needed in order to progress. Brad agreed to try to get a couple block diagrams (maybe one structural and one functional) for the next call {ACTION}.  Brad's concern was what the aims were - to develop algorithms, establish attributes of the registers? Ian thought we needed to keep sight of what the Use Case was, and walk through what it took to perform the interconnect test. 

6. Topic for next meeting

  • Building Blocks - Use Case of a simple Interconnect Test - continuation.
    • Work around block diagrams.

7. Key Takeaway for today's meeting

  • None.

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 May 1.
  • May schedule:
    • 8, 15, 22, 29.
    • May 1 is a UK holiday but unlikely to affect attendance.
    • May 29 is Memorial Day in the US and a UK holiday.

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

  • Brad: Draft up block diagrams for next meeting.

12. Adjourn

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

Respectfully submitted,
Ian McIntosh