Minutes of P2654 Working Group Meeting No.92, 2021-01-11

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/P2654WG/P2654_Meeting_92.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) (joined 11:16, left 11:46)
Terry Duepner (National Instruments)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (Digital Development Consultants Ltd)
Joel Irby (AMD)
Richard Pistor (Curtiss-Wright)
Jon Stewart (Dell)
Brad Van Treuren (VT Enterprises Consulting Services)
Louis Ungar (A.T.E. Solutions)
Carl Walker (Cisco Systems)

Tom Thompson (for IEEE)

By email (non-attendees):

Bill Huynh (Marvell Inc.)

2. Agenda

  • Brad moved to accept the agenda, seconded by Terry, 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 #91, January 4 (draft circulated January 4)
    • No correction noted.
    • Brad moved to approve, Terry seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

  • {Slide 12}
    • [91.1] Ian: Check with Tom Thompson on using deputies to support Secretary role.
      • Some WGs have a Recording Secretary that handles only taking and distributing meeting minutes, with all other tasks handled by the Administrative Secretary.  Tom will enquire further.  Not clear if both need to be IEEE-SA members.  ONGOING
    • Action Item Register: http://files.sjtag.org/P2654WG/ActionItemRegister.xlsx

6. Inter-group Collaboration

  • {Slide 13}
  • Michele Portolan has proposed a workshop at ETS 2021 - proposal accepted, now seeking participants.
  • P1581 is scheduled to hold it's first meeting on January 13 at 10 AM Eastern.  Interested potential participant from JEDEC has raised the issue of replacing Master-Slave terminology (JEDEC have adopted a policy on this). 

7. Discussion Topics

7 a) Are we supporting an unprogrammed board/system or one with intelligence already operational in it?

  • {Slide 14}
  • Bullet points are presented as discussion starters.
  • Could have case where item is programmed but programming is corrupt - still need to be able to test in that case. Could also be that a hardware fault stops the software/firmware running.
  • Some equipment may only be programmed just before shipping, or simplified software/firmware is used during manufacture to support tests, in-service programming may not provide the same (or any) test support.
  • Net effect is that even where the same types of test are possible in both programmed and unprogrammed states, the transformations involved may be quite different and even the data paths (interfaces used) may differ.
  • This is clearly relevant to P2654 - does it have any relevance to 1687.1? Yes.  A 1687.1 part could feasibly be programmable and/or dependent on the purchased IP for the device.  Potential for multiple transformation for a single device.
  • SPI implementation may not be the "gold standard" implementation, so need not always be consistent.
  • Implications for 1687.1 DPIC as the notion of a single AccessLink may be invalid.
  • As a product moves through manufacture and into the field the test cases will change, likely altering the transformations required.  This impacts on portability of tests at different stages. But for a given test case, the transformations ought to be essentially static - are there circumstances where this would not be true?
  • Security, IP protection, etc., have been discussed previously and will impact on what testing is possible (theoretically could end up as "none").  All we can do try to make sure that decisions on locking access are taken in an informed manner of the consequences for test.
  • JTAG is quite open and can offer ways past security and expose design IP.  P2654 could offer similar, but more controlled, access to test features through other interfaces while avoiding some of the IP exposure.  This was part of the notion of having a way of querying for capabilities (even if by pulling in an external file).  Publish a list of ports, functions that can be enabled or provide a quick read of an input without going through all the initialisation steps.  Aim might be to check that the system is connected up correctly rather than necessarily performing a full, functional system test.
  • Decouple "tests" from "infrastructure" (e.g. TFCL) - Tester doesn't need to know what interfaces are being used, eases re-locating where a test is "hosted".
  • Tests may be applied in a "sanitised" form (not requiring in-depth knowledge), but the test developer will likely need to have knowledge of P2654. That may be asking a lot unless there's flow up through design hierarchy levels where each level exports a package that the next level can use. Easy where one entity is in charge of the whole design, but where does that leave COTS integrators? Will they have the same/similar exported packages to work with?
  • Additional notes added to pack as slides 16-19.

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 18, 2021

12. Topic for next meeting

  • Programmed vs unprogrammed - try to formulate in a way that can have rules.

13. Reminders

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

14. List New Action Items

  • None.

15. Adjourn

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

Respectfully submitted,
Ian McIntosh