Minutes of Weekly Meeting, 2017-04-17

Meeting called to order: 11:12 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Brian Erickson
Heiko Ehrenberg
Brad Van Treuren

By Proxy:
Peter Horwood

Excused:
Carl Walker

2. Review and approve previous minutes:

  • Approval of April 10 minutes (draft circulated on 04/10/2017)
    • No corrections.
    • Brian 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 - Use Case of a simple Interconnect Test.

  • Ian had prepared a diagram for an 1149.1 interconnect test {shared - circulated by email, Apr 14}
  • Brad suggested that he could easily model the devices in HDL as they had only 12 cells, but noted that using the BSR did not represent an "instrument" as such. Further, it did not capture that there may in fact be 36 bits once input bits, output bits and control bits are accounted for.  Ian added that choosing two 12-bit devices may not have been wise as it meant the overall vector length would be a multiple of 8 bits which was convenient for I2C but would hide what needed to be done if 8-bit alignment wasn't possible.
  • Brad proposed a register in the core logic of the LH device that would output through its right edge and another register in the RH device that would capture inputs through its left edge. Brad felt that from this it should be readily possibly to translate to I2C and SPI interfaces.
  • {Peter, by email} This is a valid example for a programmable device i.e. embed the register in the core. However devices may or may not have the capability for the programmable implementation (you may only have the 1149.1 I/O). This goes back to the cloud model that we had showing the input data and the target device and vendors providing the transport layer between.
  • Ian noted that there was no self-documentation of how register bits or physical pins related to bits in the serial data. Brad added that 1687.1 was having a similar discussion and talking around a PDL or ICL description that would define an order of bits corresponding to the mapping.
  • Brad suggested that we may only know about the pin interface (for clarity: the pins of the interface, not the pinout of the entire device). Ian wondered if that meant that we didn't need to know about the mapping. Tools could deal with the device description and SJTAG would then only need to get the resulting data to the right place at the right time.  This would align with a view we had taken some time ago.
  • Brad commented on having previously created a number of 1-bit devices to test features of BSDL.
  • Brad's myHDL could be used for SJTAG as it provides bit bang interfaces for DR scan and IR scan to the simulated 1149.1 hardware.  For the 1687.1 PoC, similar DR scan is available via the I2C and SPI interfaces for comparison testing purposes.  Brad proposes this can be leveraged for SJTAG simulation as well.
  • Ian was worried about where the description would come from. For 1687/1687.1 devices, the vendor may well provide them but there are many small/cheap SPI/I2C devices around and little incentive for the vendors to provide an SJTAG description. Brad suggested that tool vendors may provide the descriptions. Ian could see that but felt that portability would suffer. Brad responded that SJTAG could help to standardise the form of the description.
  • Brad noted that there is no low level register definition for I2C: Is it just "I2C"? Are registers Read Only, Write Only or Read/Write? Are these attributes that we assign to registers?
  • Brad observed that we may be starting to overlap with BSDL here, but that User Instructions are out-of-scope for 1149.1. Ian suspected that 1687 must already be overlapping with BSDL through PDL. Brad agreed but pointed out that one is structural and the other behavioural.  Ian would not be concerned about overlap if we were only considering I2C and SPI, but we want a generic description that also encompasses 1149.1 for our abstraction. Brad responded that this was where his comment about User Instructions came in.
  • Brad assumed that there was still a need to support traditional 1149.1 operations. Would we be able to describe that kind of connectivity through a board for an interconnect test using I2C or SPI?
  • Ian considered the value of including small/cheap I2C/SPI devices in an interconnect test against the effort involved. It may not be clear. Typically, each device may only add a couple of nets of "coverage". However many of the designs that Ian sees have only one 1149.1 device, usually a large FPGA, with several I2C and SPI peripherals. Since interconnect test opportunities with a single device are limited, there may be greater value in the small devices, especially if the can be used to form loopbacks, e.g. a DAC connected to and ADC, and testing does not need firmware loaded. Brad has also been asked to provide some RF testing before firmware has become available.
  • Ian felt the meeting had covered a lot of ground and maybe revealed a few "rabbit hole entrances", and Brad summarised:
    • Need an architecture that is applicable across interfaces, with Test Input and Test Output registers.
    • Need to support "legacy" 1149.1 BScan operations.
    • There is a hybrid of the "legacy" alongside Test Input/Test Output registers. 
    • Automation of tests involving smaller devices around a "common core". Brad initially proposed this as a "fourth case", but Ian felt it was perhaps a specialisation of the third case, above. After Brad remarked that it was really a functional test, Ian suggested that it was probably the third case, but in a different Use Case altogether.

6. Topic for next meeting

  • Building Blocks - Use Case of a simple Interconnect Test - continuation.

7. Key Takeaway for today's meeting

  • Test scenarios defined for Interconnect Test Use Case.

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 24.
  • May schedule:
    • 1, 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

  • None.

12. Adjourn

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

Respectfully submitted,
Ian McIntosh