Minutes of Weekly Meeting, 2012-10-08

Meeting called to order: 11:07 AM EDT

1. Roll Call

Ian McIntosh
Patrick Au
Carl Walker
Brian Erickson
Adam Ley
Heiko Ehrenberg (joined 11:13)
Eric Cormack
Brad Van Treuren (joined 11:30)

Peter Horwood

2. Review and approve previous minutes:

10/01/2012 minutes:

  • No corrections advised.
  • Brian moved to approve, seconded by Adam. No objections or abstentions.

3. Review old action items

  • Adam proposed we cover the following at the next meeting:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • 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
  • Ian: Contact Bill Eklow regarding use of the ITC mailer to promote an SJTAG Fringe Meeting at ITC. - Ongoing
  • All: 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?

4. Discussion Topics

  1. ITC Poster - What do we present this year?
    • As Heiko was having difficulty joining the call, Ian reported that Heiko was proposing to base the poster on the takeaways from the 8/13 meeting (the four scenarios where SJTAG might be applied). Heiko had a draft layout for the poster and Ian was happy with what the proposal.
  2. Adam's questions from meeting #1 (see actions)
    • Although there were three points noted, Ian remarked that the latter two appeared to be expansions on the first. Adam agreed but also noted that when these were first raised it was in the context of proposing a JTAG implementation for ATCA, where there was a more concrete objective. It was subsequently felt that the questions remained pertinent moving forward into the broader context of SJTAG.
    • Ian commented that the intent of this topic was not to attempt to answer the points directly but instead to try to understand what made them difficult to answer. We could then try to address the barriers.
    • Considering the question "What are we trying to achieve?", Ian wondered if this was still too vague a notion to be able to know what the objectives were. Adam agreed that there was some element of that. Ian though this came back to the question of scope and this was perhaps something of a circular argument.
    • Regarding the restrictions we face, it seems that this is a question that can be addressed only once we have answered the previous point.
    • {The following out of sequence discussion was added after Brad joined}
    • Regarding the first of Adams three questions, Brad felt it was difficult to define constraints without a consistent architecture. Adam suggested that we turn that around and that it was then even more important to define the constraints up-front in order to make any progress. Brad thought it was difficult to define anything if there was nothing to point to, and Adam proposed that defining a standard architecture might be the first goal, a first step towards something more solid.
    • Brian remarked that we had previously talked about short term goals and long term goals, so maybe a standard architecture should feature in our Dot1 with a more general view to follow in Dot2. Adam agreed and noted that no-one need be bound that architecture for evermore. Ian wondered if we might all have been subconsciously looking backwards and trying make SJTAG fit all the legacy architectures and device limitations instead of looking forward to what might be a more ideal model. Brad added that most other standards had started with some form of architecture to use as a basis, so in order to start solidifying the concepts and then expand upon them we ought make some choice of architecture.
    • On the question of "What are we trying to achieve?" Brad felt we had too broad a problem space and needed to prioritize the elements. The Use Cases should have helped here but they do not offer a uniform perspective. Brad agreed with the earlier conclusion that the issue of identifying the restrictions could only be addressed once the objectives were more clearly defined.
    • Brad asked what the feelings were over adopting a model architecture. Ian thought that a single, fixed architecture may not suit everyone, but it should still be possible to incorporate some flexibility - options that could be omitted where they weren't important to the user. Ian had the opinion that most people on the call would likely have some loose idea of an architecture in mind already, but Brad remarked that he wasn't comfortable with the current state of the art, and that maybe no solution was perfect. Ian agreed that an ideal, one-size-fits-all architecture may be unattainable in the short term. Brad preferred the way the ASP worked compared to the Scanbridge's insertion into the chain topology as this meant a different access for board centric test, but the Scanbridge had useful state controls. There wasn't really any architecture that he was satisfied with. This was also a factor in Broadcom producing their own gateway.
    • Ian wondered if maybe we needed to just describe the gateway features we ideally wanted and disregard current devices. Allow people to make their own compromises until a 'compliant' gateway is produced. Brad emphasised that it couldn't be just 'a gateway', it would also need to carry some definition.
    • Brad commented that it was common to have some device that acted as a board level manager. Eric reiterated that considering the component level was too deep and the lowest level maybe ought to be a mezzanine. Ian wondered how much difference that actually made and referred to the Data Elements diagram which considered everything as a recurring hierarchy of 'assemblies.' Brad inferred that Eric was proposing that we consider 'intelligent' testable modules and agreed with that viewpoint: With that view, even reprogramming didn't require detailed low level knowledge. As boards become more complex it seems that they all need some level of board management capability. Brad proposed that we consider an 'architecture of self-test' - can we achieve all of the things in our Use Cases if there is an intelligent control on the board: Encompass all of the Venn diagram through an architecture that delegates. This seemed to be a subject for future discussion.
  3. SJTAG functional primitives: Top-down or bottom-up?
    • {Heiko joined}
    • Ian recapped that Brad had previously expressed a preference for a bottom-up approach while Tim seemed to favor a top-down methodology. Last week, Ian had attempted to decompose the Structural Test Use Case using a top-down method but had reached a position where it seemed difficult to go any lower without losing the intent of the function.
    • {Ian's forum post shared}
    • Ian asked if there were any other opinions within the group. Eric questioned whether it was appropriate for SJTAG to be considering the component level, although he accepted that there was relevance for the purpose of diagnostics. Patrick agreed with Eric, that SJTAG should be considering the system. Brian suggested that maybe there were two levels involved: One level where the board integrity is under consideration and another where the system integrity is tested.
    • {Brad joined}
    • Brad admitted to being perplexed by this issue and referenced the iNEMI study which describes 'Board Assisted BIST' so there is some consideration of a diagnostics capability there. Ian thought it may be difficult to look at the system level aspect without at least some of the lower level detail. For example, in-system reprogramming would need knowledge of the chains and the devices in them.
    • Brad had tried to step back and consider functionality: A board may have temperature sensors in devices and the user will may to read the temperature but not wish to be concerned about the intricacies of how it is done. There is the board level functional aspect, but also the strict 1149.1 testing aspect. We had however agreed that SJTAG was concerned with more than just test, and Brad wondered if perhaps these two aspects could not be considered together. Structural Test answers the question "Did I build it OK?" while functional test answers the question "Does it do what I expect it to do?" Ian observed that 1149.1 had been 'hijacked' from its original purpose and used in ways that were not part of its original aims. Brad noted that there was some reference to BIST, so some vision of that use of the TAP for access had been foreseen, but not as broad as it has turned out.
    • Brad added that some of that was behind Dot5 trying encompass all that it did, but we had agreed last week that SJTAG was not trying to be a new Dot5. In Dot5 there was a proper Master-Slave relationship established. In Dot1 the architecture demands a polling system to determine if an event has occurred as a slave cannot initiate anything. Ian wondered if that would be a problem for SJTAG; Brad thought that it might in due course.
    • {Discussion returned to 4b}

5. Key Takeaway for today's meeting

  • We need to adopt some form of baseline architecture in order to define our constraints and be able to move forward.

6. Schedule next meeting

Next Meeting:
October 15 - Ian, Patrick and Eric will miss.

October schedule:
22, 29 - Brad expects to miss one Monday during October.

7. Any other business

Eric reminded the group that daylight savings time will end on October 28 in Europe and November 4 in the US: The joining time for Europeans will therefore be one hour earlier for the October 29 meeting only.

8. Review new action items


9. Adjourn

Eric moved to adjourn at 12:13 PM EDT, seconded by Patrick.

Respectfully submitted,
Ian McIntosh