Minutes of Study Group Meeting, 2018-02-26

Meeting called to order: 11:05 AM EST

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/StudyGroup/SG_Meeting_25.pdf

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (Goepel Electronics)
Terry Duepner (National Instruments)
Bill Eklow (Retired)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM)
Jon Stewart (Dell)
Brad Van Treuren (Nokia)
Carl Walker (Cisco Systems)
Russell Shannon (NAVAIR Lakehurst)
Louis Ungar (ATE Solutions)

By email (non-attendees):
---

Excused:
Eric Cormack (DFT Solutions Ltd.)
Naveen Srivastava (Nvidia)
Mukund Modi (NAVAIR Lakehurst)
Sivakumar Vijayakumar (Keysight)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • February 12
    • Draft circulated 02/12/18
    • Amendment to remove "TBC" mark.
    • Brian moved to approve, seconded by Brad, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • [21.1] Brad: Supply Ian with glossary definitions used by 1687.1 for "transformation" and "retargeting".
    • These will be coming in the draft standard, maybe in 4 weeks or so.
    • ONGOING.

5. Discussion Topics

a) Work on refinement of what SJTAG is.

  • {Slide12 - headings}
  • Today's intent was to review and discuss the comments collected in recent weeks.
  • {Slides 13 - Study Group remit}
  • This is the group aim used in the TTSC sponsorship request for the current study group.
  • {Slides 14 - Relationship of System Test Access Management and "SJTAG"}
  • Consider "SJTAG" as a broader scope that encompasses "System Test Access Management" within it - related but not equivalent.
  • {Slide 15 - Collated comments}
  • Broadly felt that all the key points had been captured on the slide, although the section around the middle of the slide on access topologies and interfaces was maybe a bit weak - this was where the discussion of "boundaries" arose. That discussion had mainly been in email and was not mined in preparing this slide, which was assembled from the meeting notes and additional slides.
  • Not explicitly mentioned around "interface constraints" and "leverage the existing" standards but it should perhaps be about leveraging the existing testability within the design. Does that open up needing to deal with ad hoc or proprietary techniques? That's probably an implementation question.
  • Motivation to have a standard that requires a sub-assembly to make information available to the higher level; not motivated to have the other standards used more. Problem often is that there is no access to reach existing things like 1149.1.
  • Question may be "What are we managing?"
  • 1687 can be too complex to handle in an embedded situation so it doesn't get driven into the chip designs. On the other hand, 1149.1 can be getting to be too simple in many cases as you may have most of the functionality on a FPGA and need to run tests at-speed.
  • What's needed is a common communication and management interface between system and sub-system.
  • End goal is to stimulate a lowest level leaf. To do that, there is some compilation through the hierarchy with transformations that have to take place.
  • Assumes some omnipotent level of control to be able to cause that to happen - it's less likely that a COTS item will provide the information necessary to give that level of control.
  • It's possible that the Scope and Purpose could focus on the existing standards for now, while the Need could be wider. Perhaps leave a generic element for people to expand themselves.
  • The existing standards were developed to fill a void, mostly for device level test. There's value in getting re-use at board and system level but have not been able to do that because support ends at the edge of the chip. The return-on-investment is showing re-use of prior investment on incorporating those features.
  • One of the end user's needs is to test the boards in a box without opening the box.
  • System Test Access Management is part of a journey towards SJTAG. From the sub-system designer's perspective, there's a need to know that there's a standard to work to - focal point.
  • Seems like there are different "layers" being described that all fit the "System Test Access Management" label but are different:
    • At the bottom, there's nothing to define how (e.g.) a 1687 instrument can be used in conjunction with (e.g.) an I2C instrument in a test because neither standard has any knowledge of the other. Co-ordination between device level standards.
    • At the next "layer" there is the interface that allows communication between a sub-system and the system level. This seems to assume/require a certain level of functionality in the sub-system to be able to service the communication. This may (but need not) make use of the layer mentioned above.
    • At the top, there's a mechanism for applying tests to a complete system unit (whether externally applied, or run from embedded resources) and collecting results via a test connector or otherwise (ultimately some User Interface). Again this may (but need not) make use of the layer mentioned immediately above.
  • These may form a stack or pyramid describing SJTAG. This is similar to a poster SJTAG have used at ITC {Post Meeting note: In fact, this was actually a presentation for BTW in 2014: http://files.sjtag.org/BTW2014/Test_Managers_and_Controllers.pdf}.
  • Which layer is the current standard we are proposing intended to address?
  • The sub-system to system communication seems to be a similar concept to that addressed by 1149.5 which failed to gain traction (wasn't popular as it required too much resources in the target, used a very specific bus controller and protocol, etc.). However the requirement could be met without mandating a specific interface - Allow using one that exists for other uses (e.g. Ethernet) and simply define what types of information should be pushed over the interface. Board Management Controllers may have IPMI. There are interfaces, but there are also protocols, e.g. PMBus over I2C. Should also consider that there may not be a BMC as such, perhaps just a basic power sequencer.
  • Concern that much of today's discussion has been about interfaces to a board but not much about intra-board interfaces. There may not even be any 1149.1 but there may be I2C.
  • Note for discussion next time - query on "Board level BIST is more than a component access topology".

  • Reference slides (not used during this meeting):
  • {Slide 16 - Draft Scope}
  • This is draft text as proposed by the "Initiative group" (as are the following two slides).
  • {Slide 17 - Draft Purpose}
  • Red text is highlighted as it is a constraint that we might want reconsider, or at least discuss.
  • {Slide 18 - Draft Need}
  • The wording of this has already been pointed out to be deficient as it stands. It is probably too long anyway - the latter part has been greyed as it is largely just an expansion of the main points.

6. Today's Key Takeaways

  • {Slide 19}
  • SJTAG should provide a common communication interface from sub-systems to systems.

7. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • "Interface" is missing.
      • No obvious IEEE accepted definition.
      • 1687 has definitions for specialised forms: Device Interface and Instrument Interface.
      • We may need specialised forms for Software Interface and Hardware Interface.
    • 1687.1: Transformation, Retargetting.
    • IEEE 1856: Sense - "Sensor" done, Acquire, Analyze not really defined.

8. Topic for next meeting

9. Schedule next meeting

  • March 5.

10. Reminders

11. Any Other Business

  • None.

12. List New Action Items

  • None.

13. Adjourn

  • Brian moved to adjourn, seconded by Heiko.
  • Meeting adjourned at 12:06 PM EST

Respectfully submitted,
Ian McIntosh