Minutes of P2654 Working Group Meeting No.93, 2021-01-18

Meeting called to order: 11:04 AM EST

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

The cumulative reference pack is located here: http://files.sjtag.org/P2654WG/P2654_Reference_Pack.pptx (updated Dec 31, 2020)

iMeetCentral site: https://ieee-sa.imeetcentral.com/sjtag-sg/ 

1. Roll Call

Ian McIntosh (Leonardo)
Eric Cormack (DFT Solutions) (left 11:29)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Richard Pistor (Curtiss-Wright) (joined 11:08)
Brad Van Treuren (VT Enterprises Consulting Services)


By email (non-attendees):

Bill Huynh (Marvell Inc.)
Terry Duepner (National Instruments)
Joel Irby (AMD)
Jon Stewart (Dell)
Louis Ungar (A.T.E. Solutions)
Carl Walker (Cisco Systems)
Tom Thompson (for IEEE)

2. Agenda

  • Eric moved to accept the agenda, seconded by Brad, no objections.

3. IEEE Patent Slides

  • {Slides 5-10}
  • Patent and Copyright slides reviewed without comment.

4. Review and Approve Previous Minutes

  • {Slide 11}
  • Meeting #92, January 11 (draft circulated January 11)
    • No corrections noted.
    • Brian moved to approve, Brad seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Inter-group Collaboration

  • {Slide 13}
  • None. 

7. Discussion Topics

7 a) Programmed vs unprogrammed - try to formulate in a way that can have rules

  • {Slide 14}
  • Bullet points presented as discussion starters.
  • Need to support both programmed and unprogrammed cases, but what is the effect of that?
  • Surely the standard provides a method for dealing with any configuration of the UUT and programmed and unprogrammed are just different configurations? i.e. the overall 'method' still applies but the input conditions change.
  • An assembled rack is likely to be programmed but boards may be unprogrammed or partially programmed during manufacture. However, even at rack level, some boards may be unprogrammed (or corrupt).
  • Should handling these different cases be left to the ingenuity of the tool providers? Let the standard provide a generic method that can be used for all cases.
  • Diagnostics and actions in response to a fault are for the application or operator to determine and outside the scope of the standard. P2654 only needs to report the result of each operation (which may include the data associated with the result).
  • Could have a case where a programming operation fails but test is possible via another route that could tell you that the access link used for programming is faulty.
  • In 1149.1, you can test the infrastructure (1149.1 chain) which will tell you whether you can move test data around. P2654 is essentially describing the test infrastructure.
  • There is a boundary between test conditions, e.g. whether on Test Equipment or in a deployed state.  Environment may affect how readily a test can be ported.
  • Even in an "unprogrammed" state it may be necessary to have partial programming applied, e.g. in order to get sufficient power on to allow further control and testing.
  • Test may differ on-line vs off-line.
  • Many of the points raised may not affect the application of the standard but should be signalled for awareness of the user/designer so they can consider how these might affect the implementation they choose.
  • What about dynamic changes to the configuration of the test subject - different board types exchanged or new boards added?  Is this also outside the scope of the standard?
  • Don't want to over complicate the standard by trying to deal with every corner case, and don't want to limit the scope for tool vendors to innovate in support of the standard.
  • Additional notes added to pack as slides 20-25.

8. Any Other Business

  • {Slide 15}
  • None.

9. Today's Key Takeaways

  • None. 

10. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • System Element.
    • System Resource.
    • 'System' needs the concept of a controller capability added.
    • "Filtering" may need to be defined.
    • "Translation" may need to be defined.
    • "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.
      • "Interface" is overloaded and requires disambiguation.
    • 1687.1: Transformation.
    • IEEE 1856: Sense - "Sensor" done, Acquire, Analyze not really defined.
    • Device - do we mean a packaged device? May be many devices in a package. "Device" is often used as a modifier, e.g. "device package", "device identification".
    • Use Case Context, Application Context
    • Legacy Infrastructure, SJTAG Infrastructure (placeholders for now, really for working group to define).
    • "Generators": May need to be qualified as "Test Generators" (used by the integrator/tester) and "Model Generators" (used by IP providers, interface designers, etc.).
    • AccessLink and DataLink descriptions will need to be revised.
    • See P1687.1's definitions on Slide 31 of the pack presented by Jeff Rearick on Jan 14, 2019.
    • "State", "Vector", "Sequence" and "Pattern" as proposed at April 8, 2019 meeting.
    • "Event", "Access Interface" as proposed at April 15, 2019 meeting.
    • 'Port' needs to be developed.

11. Schedule next meeting

  • January 25, 2021

12. Topic for next meeting

  • Return to considering what rules are possible to define.
  • Questions on today's discussion

13. Reminders

  • Reiterate: Michele Portolan has proposed a workshop at ETS 2021 - proposal accepted, now seeking participants.

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh