Minutes of Weekly Meeting, 2014-01-27

Meeting called to order: 11:06 AM EST

1. Roll Call

Eric Cormack
Carl Walker
Ian McIntosh
Michele Portolan
Tim Pender (left 11:59)
Brad Van Treuren
Heiko Ehrenberg (joined 11:08)

By Proxy:
Adam Ley (email exchanges shown indented and author highlighted)

Excused:
Peter Horwood
Patrick Au

2. Review and approve previous minutes:

01/13/2014:

  • Draft circulated 01/13/2014.
  • No corrections advised.
  • Michele moved to approve seconded by Carl with Brad abstaining. No objections.

3. Review old action items

  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? See also Gunnar's presentation, in particular the new information he'd be looking for in a test language (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Ian - Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
  • Establish consensus on goals and constraints
  • What are we trying to achieve?
  • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172

5. Discussion Topics

a. Newsletter
b. Can we capture the recent discussions in a simple form, e.g. can we perhaps diagram where management protocols, access link protocols and data all sit? Is there some standard order of events that must be followed?

  • Ian elected to merge these items as the expectation was that we could use some of the material presented to the iNEMI BA-BIST group for the newsletter.
  • {Brad shared his slide pack.}
  • Brad talked through his slides, the first two of which were familiar to the group.
  • SJTAG Visualization (Michele's slide):
  • Described SJTAG as providing a management function over the access links: SJTAG at the top level, connecting to various modules that sit on top of the hardware interfaces (a bit like PHYs) -- the JTAG 1 - JTAG n and other interfaces.  The structure on the board is placed in a system model of some form, from which the SJTAG Test Manager needs to consider not just what data is used where but also when it is applied.  This leads to consideration of dependencies and "test flow" brings in the when aspect.
    • Adam, by email: A consideration central to SJTAG that I think is missed here is that the “SJTAG Test Manager” is not (typically) monolithic, which presents challenges across each of the what, where, when characteristics. A key concern of SJTAG, as I believe we have always discussed, is that algorithms, routines, and models need to be portable in some way amongst the distributed environs of test generation, test application, and diagnostic analysis.
  • Illustrative SJTAG System (Ian's diagram):
  • The iNEMI group felt this illustrated the board level problem domain well.  Brad had described the way we worked through dot6 test between U5 and U6 then moved on to instrumented cases with the loopback instrument and the variety of ways that multiple lanes might be handled and the difficulties this presented in attempting to describe it using ICL/PDL and the BA-BIST templates.  It is not enough to describe the instrument itself; you also need to know how it will be used.  This seems to have been a new insight for the BA-BIST group who had not really considered instruments co-operating across devices.
  • The 1149.7 Bridge had been questioned and Brad had pointed out that you would need something like this to use dot7 only devices in a board that had a predominantly dot1 infrastructure and that the reverse would also be true, to use dot1 devices within a 2-wire network.  It could be thought of as another instrument that provides downstream access and the SPI/I2C Bridge was similar. 
  • Brad had also described using U15 to host an instrument to test U16.  When challenged that little could be done for U14 Brad had noted that a Flash Writer instrument could be loaded to speed up Flash programming.
  • Don't know how to describe how an instrument can be used, and BA-BIST group considering a Phase 4 project to look at instrument-to-instrument behaviour.
    • Adam, by email: I can’t really make sense of this comment (the first part of it) within the limits of the context provided. As I understand it, instruments, as I believe the term is used here, would be provided with PDL that defines, if you will, how the instrument is to be operated. I suppose the name of any given PDL proc (iproc) would provide some insight into the purpose of the instrument. Then, I would hope that there would be some additional information associated with (within) the PDL that more fully describes how the instrument(s) can be used. (?)
    • Ian: My brevity is probably at fault here: I think what was conveyed in the discussion was that BA-BIST weren’t considering the wider considerations of how an instrument might be used in the conduct of a test, rather than just making the instrument “do something”.  That is reasonably OK where a single instrument is used (as in their MBIST instrument example) and the PDL is probably sufficient.  However the PDL is probably not enough when it comes to trying to work with disparate instrument that may be in different chips and you need an awareness at a higher level.
    • Adam: I believe that I understand (and concur with) what you are saying, but I would like to suggest that, where BA instruments are provided, they should be provided with attendant PDL, and that their purpose and how-to-use (particularly in cooperation with other BA instruments on other chips) should be somehow factored into (or at least, in some structured way, referred to by) said PDL. If there’s not presently a (structured) way to do that within the existing PDL structures, then that could be a value-add for the iNEMI activity and/or SJTAG ...
    • Ian: I think your view is correct, but the feedback from Brad seemed to suggest that the BA-BIST people hadn’t got as far as thinking about that and were more focussed on “what does this instrument do?” rather than “how might we employ this instrument?”.  The sense was of a chip-centric view despite it being a BA forum.
    • Brad: BA-BIST is considering the description of the operation of an instrument from the instrument edge to the external device under test.  This is the purpose of the iNEMI templates.  There is indication of the algorithms that need to be provided by the instrumentation for the purpose of testing this external bus/interface.  Yes there is consideration that some PDL needs to be provided by the instrument designer as to how to activate these algorithms and when for the test to be successful.  That is outside of the scope of the iNEMI Phase 3 project.  The whole issue of coordination of instrumentation is perceived and understood to be critical to the success for testing, but has not yet been addressed by the iNEMI BA-BIST project as that has been outside the scope of defining the operation of the instrumentation edge to the external device under test.  In the last iNEMI meeting there was a lot of discussion on the fact that they have not really addressed this coordination of instrumentation by the templates created and that it seems to be important and needing additional work outside of the scope Phase 3 was looking at; thus the need for a possible Phase 4 project.  Phase 3 was supposed to also address the use case of SERDES interface testing, but the examples shown are for the first use case of External-MBIST with a DDR3.  Ian is right when he stated "how might we employ this instrument?"  When I brought up the SJTAG use cases of a U5 to U6 test with a SERDES Tx instrument and a SERDES Rx instrument available and the various ways it could be deployed in U5 or U6 (separate instruments per lane, multiplexed instruments over lanes, loop back of lanes, etc.) the iNEMI team finally realized they have not gone far enough with the analysis for industry.  Actually, they were realizing this in the previous meeting and is why they wanted me to create some SJTAG slides explaining what I was describing to be used at their webinar in March.
  • Brad commented that there was always the possibility that U5 might be a dot6 part and U6 a dot1-2013 part.
    • Adam, by email: Does this truly intend to say dot1-2013, as distinct from dot1 generally? If so, what is the thought as to the value add for “-2013” in this scenario?
    • Ian: I read the discussion there as citing 1149.1-2013 as an example, that could easily have been P1687.  I think the objective was to highlight that we might have an uninstrumented device at one end of a lane and an instrumented device at the other.
    • Adam: It seems I’m still missing something here. If I take your statement as denoting a contrast (instrumented device versus uninstrumented device) and infer that you mean to place that in the context of a test of the device-to-device interconnections, am I to understand that 1149.1-2013 (or P1687) means instrumented whereas dot6 means uninstrumented? Is the 1149.1-2013 (or P1687) device presumed to embrace (also) dot6, such that a “conventional” interconnect test is possible, or is it presumed to preclude dot6? Also, I’ll note that 1149.1-2013 should NOT be taken to infer that a device is instrumented (at all), much less that it is instrumented for BA; the later point applies also to P1687.
    • Ian: Maybe I captured it poorly, but I suspect you’re reading it much more literally than was intended.  It’s fair comment that 1149.1-2013 doesn’t automatically imply that an instrument is present but I think Brad was making a rather loose, off-the-cuff comparison there, which possibly over-generalised.  My take was that we could have a device pairing that shares a common physical interface but where the test features behind those interfaces are quite different, perhaps with a PDL description for one end but not the other.
    • Brad: Some points that need to be made are 1) there are instrumented devices that are controlled via a variety of access link technology and 2) some instrumentation that is not directly compatible on the other end of a connection (e.g., .1-2013 pure embedded instrument on one end and no dot6 support and only dot6 support on the other).  For the first case, there needs to be some means to "manage" the operations between these disjoint interfaces in a coordinated fashion whereby the instruments may be used in concert.  This may involve actual memory mapped IO access with the processor interface to control an instrument A and a P1687 access to control instrument B.  The term instrumented and uninstrumented in this context was meant to describe those instruments controllable with defined JTAG access link (definable through PDL and either dot1-2013 or P1687) interfaces and those that do not have associated PDL (e.g., I2C proprietary, SPI proprietary, memory mapped IO) from the {typical} SJTAG flow we have been considering up to this point in time. 
  • E-MBIST EcoSystem for Data Transfer (new slide):
  • Illustrates one instrument talking to a (relatively dumb) device. The right hand side shows what BA-BIST have claimed as the domain for their templates.  The templates are primarily for the board tester to specify to chip designers the features they need to address the shortfalls in test coverage at the board level, and relies on P1687 or 1149.1-2013 to describe how you get from the chip edge to the instrument and most of the examples in P1687 go to instruments that are on the chip.
  • Brad was introducing the left hand side of the diagram.  It was a way to describe the infrastructure needed to get data to the instrument at the right time and which encompassed the board/sub-system/system domain.  This needs some sort of description language and some sort of algorithmic language. 
  • What we're showing is a decoupling of the data flow from the control flow: Instrument data links and system access links from the tester to the end instrument.
  • System-Level Access/Data Path Concept (new slide):
  • This is an attempt to broaden out the "cloud" in the previous diagram, with the SJTAG Gateway (or U12 in our illustrative system), SJTAG Selector (U13) and the I2C Bridge (U9) to give specific examples of where the access links might be applied, and showing that control may be by several different interfaces.  The ASP gateway protocol would use the same JTAG wires but other interfaces may require additional pins at the board edge, which could be a consideration.  Brocade's example used I2C as the selection mechanism and was the way ATCA had been looking.
  • Brad deliberately hadn't defined the physical interface, choosing to leave it "fuzzy".  You then need to route the board JTAG interface to some instrument or bridge to an instrument. The SJTAG Selector could be like a scan path linker, but something that manages chains.  Like the Gateway, we don't really care about the control interface: It could be some dedicated interface or just piggy-backing off some existing interface.
  • There could be any number of sub-chains.  The top one shown is pure 1149.1 but could easily use P1687 or 1149.1-2013 descriptions.
  • Tim asked if the second sub-chain was daisy-chained.  It may or may not be.  Brad noted that it was basically a translation from JTAG to I2C and back.  Ian noted that would enforce a delay while the I2C bridge is loaded with data before passing it on to the destination bus which might add some complexity to test involving both end instruments as shown.  Brad agreed that the delay would need to be factored in.
  • The possibility of the access links being distinct from the JTAG data paths was novel to the iNEMI group, although Ian thought that conceptually it wasn't all that different to things like the Shadow protocol, which is outside 1149.1 even though it may share the wires.  Current tooling tends to hide what actually happens in some "magic" in the board setup in the tool, but we may be asking for a more open approach to accommodate the greater variety of interfaces.  Brad noted that most of the iNEMI paticipants were "chip people" with a few ICT test people with board test knowledge but little experience of multidrop and one or two people who maybe understand the system through to chip aspects.
  • Scope must expand so SJTAG can use other interfaces.  How would 1149.1-2013 or P1687 define alternate data paths as against access links?  Michele felt that biggest issue would be synchronisation: P1687 defines "ports" but not the behaviour behind them which would make co-ordination between different interface difficult.
  • Brad asked the group if the slides captured recent discussions adequately; it was agreed that they did.
  • There will be a BA-BIST webinar in March; Brad has been asked to be on hand for any explanations that may be required.
  • This was good material for the Newsletter, but Ian felt the diagrams were essential though they wouldn't fit legibly into the Newsletter format.  Ian proposed that we should prepare a more substantial article on the website (with larger diagrams) and place a "teaser" summary item in the Newsletter of only a couple of paragraphs with smaller diagrams.  Brad agreed, but would find it difficult to make time this week to prepare anything.  Ian felt it was worth delaying the Newsletter by a week or so to get a good article in place.

c. Moving forward:
- How has Scope and Purpose changed? See http://www.sjtag.org/ home page.
- Continue with 'Purpose'.
- Can we outline a hierarchy/structure of SJTAG standards? See Heiko's additional notes from BTW in the previous minutes, Brad's email of 12/09 and Ian's email of 12/31.

  • Not discussed

6. Key Takeaway for today's meeting

  • SJTAG concept slides presented to iNEMI BA-BIST group were discussed.

7. Schedule next meeting

  • Next Meeting: February 3.
  • February schedule: 
    3, 10, 17, 24

8. Any other business

  • Eric reports that there may be opportunity to make contact with automotive representatives via the National Microelectronics Institute..

9. Review new action items

  • None.

10. Adjourn

Eric moved to adjourn at 12:11 PM EST, seconded by Brad.

Respectfully submitted,
Ian McIntosh