Minutes of P2654 Working Group Meeting No.37, 2019-10-07

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/P2654WG/P2654_Meeting_37.pdf

1. Roll Call

Ian McIntosh (Leonardo)
Eric Cormack (DFT Solutions)
Heiko Ehrenberg (GOEPEL Electronics)
Brian Erickson (JTAG Technologies)
Peter Horwood (No affiliation)
Bill Huynh (Marvell Inc.)
Joel Irby (Arm)
Richard Pistor (Curtiss-Wright)
Jan Schat (NXP Semiconductors)
Jon Stewart (Dell)
Brad Van Treuren (No affiliation)
Louis Ungar (A.T.E. Solutions)
Carl Walker (Cisco Systems)


By email (non-attendees):

Terry Duepner (National Instruments)

2. Agenda

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

3. IEEE Patent Slides

  • {Slides 5-9}
  • Patent slides reviewed.

4. Review and Approve Previous Minutes

  • {Slide 10}
  • Meeting #36, September 30 (draft circulated September 30)
    • No corrections.
    • Eric moved to approve, Carl seconded, no objections or abstentions → minutes approved.

5. Review Open Action Items

6. Discussion Topics

6 a) SCSI/SASI API and Security

  • {Slides 12}
  • Forum thread: http://forums.sjtag.org/viewtopic.php?f=3&t=825.
  • Peter talked through his suggestion on how elements of SCSI could be used by P2654. Reference was made to the framework of SCSI standards shown in the first graphic in the forum thread.
  • Aim is re-use. This is a method of packetizing data, which a requirement for many of the target interfaces anyway. Takes advantage of an existing API.
  • Has an in-built 'inquiry' to determine available features. The information we need for P2654 could be slotted into the "Vendor Unique Bytes".
  • Scheme includes a Logical Unit Number, hence a form of multidrop bus is possible.
  • Has security features although we cannot be sure what is actually in there until we have seen the documentation.
  • Concern that the overhead may disproportionate to the payload in some cases, although the block size can be set by Mode Select. In early implementations, command processing time could be significant.
  • It is possible that even if there is a SCSI port available on a device there may not actually be a way of routing data from it to the downstream interface of the device (perhaps a fibre-channel interface).
  • The limited command set we'd need could probably be implemented in logic and wouldn't need a processor.
  • Could possibly define the call-back API. Individual existing SCSI standards may be too prescriptive so we'd need to create our own API on top. May help define what "our" API needs to offer to allow interfaces to be "plugged in".
  • Commands used to be perceived as very rigid in terms of what e.g. 'blocks' were referring too. May have been expanded in more recent years.
  • Sequence is essentially that you write a block and then read a block (rather than simultaneously shifting data in and out, as per 1149.1) although actual behaviour probably depends on implementation in the hardware.
  • Possibly reconciles down to Write and Read commands. Aligns with Michele's propositions.
  • Once the hierarchy has been configured via the API it becomes essentially transparent and data can be sent directly to the bottom target.
  • It is "just a method of encapsulating data".
  • There may be limitations as some sections of the circuit may not be available at the point of test, e.g. an Ethernet host may not have started up, although this may be also true for many other cases.
  • Appealing that the security aspects seem like just an alternative wrapper - can use either the standard wrapper or the secure wrapper as necessary.
  • Smaller designs may not have a SCSI interface (high-end servers probably will). SCSI-over-Serial may be option which could use a simple 2-pin interface. However there may restrictions on physical access if that is being used for something else.
  • Even if we find we can't make direct use of this, it's possible that T10 will illustrate the kind of framework we'll need for P2654.
  • Inevitably there'll be a push-back against adding more software into embedded systems. Test software builds are common during build and integration phases and there will always be some cost to having embedded test at all.
  • Concern that intermediate layers we pass through might try to audit that commands being passed on are "valid" and so block unrecognised P2654 traffic. In theory, each device should only look at the data targeted to itself and simply pass on everything else. 
  • We can look at trying to obtain some of the T10 documents (many appear to be available to download simply by registering on the T10 website). Further discussion can take place on the forums for now.

7. Any Other Business

  • {Slide 13}
  • Ian will check that the ITC poster is complete and up-to-date.

8. Today's Key Takeaways

  • T10 may give insight on the type of framework we might need.

9. 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.
      • "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 meeting.
    • "Event", "Access Interface" as proposed at April 15 meeting
    • LRU and SRA.

10. Schedule next meeting

  • October 14, 2019
    • Columbus Day , US and Thanksgiving, Canada.
    • Richard, Louis and Joel will be out.

11. Topic for next meeting

  • P1687.1 feedback on Brad's Module Classification slides.

12. Reminders

  • None.

13. List New Action Items

  • None.

14. Adjourn

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

Respectfully submitted,
Ian McIntosh