Minutes of Study Group Meeting, 2018-04-09

Meeting called to order: 11:05 AM EDT

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

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (GOEPEL Electronics)
Eric Cormack (DFT Solutions Ltd.)
Bill Eklow (Retired)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM)
Mukund Modi (NAVAIR Lakehurst)
Richard Pistor (Curtiss-Wright) (joined 11:08)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell)
Brad Van Treuren (Nokia) (joined 11:08)
Carl Walker (Cisco Systems)
Russell Shannon (NAVAIR Lakehurst)
Craig Stephan (INTELLITECH Inc.)
Louis Ungar (ATE Solutions) (joined 11:06)
Sivakumar Vijayakumar (Keysight)

By email (non-attendees):

Terry Duepner (National Instruments)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • March 26
    • Updated draft circulated 04/04/18
    • No further corrections.
    • 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.
    • ONGOING.
  • [27.2] Legacy Initiative Group to propose definition for "SJTAG".

5. Discussion Topics

a) PAR - Refine PAR Purpose text.

  • {Slide12 - headings}
  • {Slide 13 - Draft Purpose}
  • There main points raised during the previous meeting were summarised.
  • Brad created an editable copy of the slide to collect comments {shared, http://files.sjtag.org/StudyGroup/SG_Meeting_30_bgvt_single_slide.pdf}.
  • Remarks noted during the discussion:
    • Does "STAM" need to be expanded here? "STAM" won't appear on the PAR here, just "Purpose". The proposed title for the standard will appear in full elsewhere in the PAR. We may choose a different title other than "System Test Access Management" for the standard, STAM is just a "working title" for this study group.
    • The red text is to be struck out, as previously agreed.
    • Should "destination registers" simply be "destinations"? Destinations may include registers, but not always. But we really only have access to what controls the destination and that is usually a register; e.g. to turn on a specific LED we can only access the latch that controls the LED driver. So we have an expectation that all cases have registers.
    • We should really talk about "destination interfaces" as the registers are defined by other standards (the standards we are leveraging). STAM describes how to talk to the interfaces rather than the registers.
    • Are there any cases where there is no register? There could be the case where something is managed through its state. Arguably, the state is a "register", it is just set indirectly. What about an analogue summing junction? Then the observed "result" has to be some kind of register, maybe a 1 bit register for the output of a comparator or a digitised measurement value.
    • There has maybe been a tacit assumption throughout that everything we're dealing with ends up in the digital domain - this is probably an important point.
    • Some of these points probably affect the Scope so we should mark those to consider when we re-check the Scope later.
    • Are we including RF interfaces? No particular reason we shouldn't include them, or optical interfaces for that matter. Would these have registers? Almost certainly - generally there's a shift-register action in there at each end so that data gets moved serially across the interface.
    • When we talk about interfaces should we say "interface standards"? Probably not - we can't assume that all interfaces are "standard". Some may be described by IEEE standards, others by industry standards, and some be device or vendor specific.
    • Purpose should provide a uniform way to define and access various interfaces.
    • This then ties in with SJTAG as we use the data register as the intermediary register to manipulate what goes into the register from various interfaces like we use 1149.1 to get into test data registers. Is there really an intermediate register? In 1687 you have a "Portal Register" and can have a virtual register where it looks like you're accessing a register but none physically exists.
  • The amended version of this slide will be posted to the forums for comment {Post Meeting Note: Now posted here: http://forums.sjtag.org/viewtopic.php?p=1322#p1322}.
  • Reference slides (not used during this meeting):
  • {Slide 14 - 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.
  • {Slide 15 - Collated comments}
  • Yet to be considered.
  • {Slide 16 - Draft Scope}
  • No need to agree on text right now, wait until we've considered the other sections.

6. Today's Key Takeaways

  • {Slide 17}
  • Need to ensure destination register is explicit and explain that it is part of the leveraged interface.
  • Assumption is that all data can be represented digitally.
  • Interfaces may not conform to a formal standard.
  • STAM should provide a uniform way to define and access the interfaces it uses. 

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.
    • SJTAG: Discussion on forums - http://forums.sjtag.org/viewtopic.php?f=3&t=782

8. Topic for next meeting

9. Schedule next meeting

  • April 16.
    • Heiko expects to be out.
    • Ian expects to be out on 23rd, Russell expects to be out on May 7th.

10. Reminders

11. Any Other Business

  • TTSC meeting on 18th, Heiko expects to be on the call and Brad also aims to join. Ian will propose a status update.

12. List New Action Items

  • None.

13. Adjourn

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

Respectfully submitted,
Ian McIntosh