Minutes of Weekly Meeting, 2011-10-10

Meeting called to order: 11:06 AM EDT

1. Roll Call

Ian McIntosh
Patrick Au
Peter Horwood
Adam Ley
Heiko Ehrenberg
Brad Van Treuren
Eric Cormack
Richard Foster
Brian Erickson (joined 11:07)
Carl Walker (joined 11:09)
Tim Pender (joined 11:10)

2. Review and approve previous minutes:

10/03/2011 minutes:

  • Draft circulated on 10/03/2011.
  • Three corrections noted:
    • 4a [Heiko] 'be a busy' -> 'be as busy'
    • 4b [Ian] 'PAR to soon' -> 'PAR too soon'
    • 4b [Adam] 'accompaniments' -> 'attendant complications'
  • Eric moved to approve with the above amendments, seconded by Patrick, 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/Brad: Condense gateway comments and queries into a concise set of questions. - Ongoing
  • All: Forward text file to Ian containing keywords from review of meeting minutes. - Ongoing.
  • Carl/Brad: Get annotated keyword worksheets to Ian by Wednesday Close of Business. - Ongoing
  • All: Consider how a keyword can be used to define the chain configuration for a given test step, and what that keyword might be.
  • Harrison: Prepare slide showing matrix of industry sectors by volume/mix. - Ongoing.

4. Discussion Topics

  1. Reestablish basic objectives of the group
    - Continuation of last week's discussion.
    - Question: How closely coupled should SJTAG be to e.g. P1687, 1149.7?
    • [Ian] One thing about trying to take the notes from these meetings is that often I don't really absorb parts of the discussion. It's only when I come to type the notes up that I see things that I wish I'd asked about.
    • [Ian] Last week there were two things that caught my eye, but I guess they're both interrelated.
    • [Ian] The first was where Adam asked if were looking at SJTAG for today's environment or for tomorrow's environment. Harrison expressed the opinion that it had to be tomorrow's environment. I can't say it's wrong but it's not an answer that makes me happy, personally.
    • [Ian] That kind of leads into the second item, since P1687 is a future standard: There was an implication in the discussion that there might be a dependency for SJTAG on P1687 and other recent or emerging standards. I may have been misreading the discussion there, but it felt wrong to suggest that 'SJTAG needs P1687'. That was what spawned the question in the agenda.
    • [Ian] Brad originally wasn't expecting to be on this call so he sent a proxy contribution. It was a bit late yesterday by the time I got it circulated, but I hope most of you managed to read it before the meeting.
    • [Brad] It doesn't feel like it's a strong coupling between SJTAG and P1687 and dot7. SJTAG is independent from those but needs to support them. SJTAG needs to provide the mechanisms to access those standards, but in many ways it should be no different to supporting ASP or Scanbridges from a SJTAG perspective. So I asked the question, 'How does the support of these standards differ from that of the ASP and Scanbridge protocols?'
    • [Brad] SJTAG shouldn't be restricting itself to supporting only selected standards: To future-proof itself it needs to be open to any standard that may come along, and we know there will be more to come.
    • [Ian] Adam also sent me a note in response to Brad's proxy.
    • [Adam] I agree with Brad, but might venture to go a step further in saying that we're spinning our wheels considering supporting any other standards until we have a sense of what we want to do with SJTAG. We are, as it were, drawing on a very large canvas right now, and we need to focus in.
    • [Adam] We might be better served by thinking in terms of the problem space in a fairly narrow way. P1687 may be a factor in that.
    • [Brad] Something else that was said: 'Everything is going to become an instrument.' I'm not sure I agree with that.
    • [Ian] Depends on what was meant. Maybe in an abstract sense it is true; it maybe depends on what you call an 'instrument'.
    • [Brad] I agree with Adam, but what I'm struggling with is how we get into that narrowed scope. We've tried using the Use Cases and didn't manage to map that to primary requirements. We tried using the logical building blocks and more recently with the pairwise discussion.
    • [Ian] That's the issue I recognise too.
    • [Adam] One thing I suggested is to take a step back. Take a specific Use Case, as Brad termed it, and determine what is the constituency for it. Is it for manufacturing test, or field test? Find the primary constituency for that use case and then see if fits the constituency for any others.
    • [Brad] Thats why the latest round of discussions with pairs and use cases should have been beneficial.
    • [Ian] I guess this getting back to the idea of some 'model system' to talk round. In principle it seems a good way to go.
    • [Adam] I recall that some of the early efforts were looking at portability of vectors into embedded systems and portability of result data back into the originating system. It looks like that still hasn't been solved in any standard framework. That's something that could possibly be carved off.
    • [Brad] I struggle with trying to overlay that onto our use cases; it's not really a use case itself.
    • [Adam] Sure, that's fine; so start with a Use Case.
    • [Brad] If we pick something like interconnect tests first then that might restrict us when we get to FPGA programming, where the diagnostics will be different for example.
    • [Adam] If you're considering diagnostics, then that's different: I'd say that moving diagnostic information into an embedded environment is maybe too ambitious at this stage.
    • [Ian] From my perspective, within SELEX and as someone who uses external controllers more than embedded, what I would probably say is the most troublesome area for me is programming at the system level. Poor tooling support for multi-board systems, different data formats. Creating interconnect tests with multiple boards isn't as much of an issue.
    • [Brad] In ALU, each unit has a different reason for their buy-in to using JTAG. So the primary use case will be different for each.
    • [Ian] I agree, which is why I emphasised that I was speaking from my personal perspective. It's difficult to see what will be important for others. It'd be good to find what gives the most 'bang per buck' in terms of helping users.
    • [Brad] I liked Adam's idea of identifying the end user's of the conforming products.
    • [Adam] That's what I'm meaning by the 'constituency' in today's discussion. There may be other constituencies; tool vendors, chip makers. If it makes sense you can include equipment manufacturers.
    • [Brad] Perhaps we should just select some arbitrary Use Case. Take that and single out what are the categories we need to be filling out for it. Come up with a template of what we need to solve for each Use Case. It's similar to what we had to do for Volume 2 of the White Paper.
    • [Eric] Ian, from ITC, of the discussions you had, were there any indications of which problems people had?
    • [Ian] No, I don't recall there being anything that was specifically mentioned.
    • [Heiko] Is the latest survey on the website?
    • [Ian] It should be, I'm not sure where though. It's a set of HTML pages.
    • [Heiko] OK, found it. It's linked from the Stored Documents page.
    • [Ian] There might be some slight indications we can take from the survey.
    • [Brad] I don't know that we asked the right questions.
    • [Ian] That seems to be a common problem in surveys! Once you see the responses you wish you'd asked different or extra questions. I think that some Use Cases will clearly be of more peripheral interest, other will have wider appeal. An arbitrary choice seems to be as good as anything to me.
    • [Ian] Whatever we choose, Gateways/switches/Scanbridges will probably feature. A problem I perceive is that there's no portable way of describing them; most tooling seems to have a hard coded 'lump' for these devices.
    • [Brad] They also tend to make a lot of assumptions about architectures in the tooling. We've gone through 'only our devices in the chain' to allowing parts in BYPASS to being able to do ReadID in some cases.
    • [Brad] We need to determine what is involved in order to perform this Use Case. These are the specific elements that are needed. I'm thinking that the constituency is abstract; it is important but doesn't really have anything to do with data vectors.
    • [Brad] I'm just trying to look at Volume 2 on Programming/Updates.
    • [Ian] It may be an aside but another thing that is important to me, and possibly others is design security, and the implications it has on test and programming.
    • [Brad] I'd look at that as a refinement and not part of the general model.
    • [Ian] That's fine. So how do we propose to move on?
    • [Brad] One of the insights I had recently, and I put this in my email, was that we're now starting a migration into a new field with JTAG. Now we're describing not just the structural aspect but also the behavioral aspects.
    • [Brad] We're going to have to look at the Use case in terms of the structural environment and then look at the behavioral aspects; what needs to be in place to enable this operation?
    • [Brad] In doing this we're trying to find an avenue to narrow the scope.
    • [Ian] Does that sound OK to everyone?
    • [Adam] That sounds fair.
    • [Brad] It's no longer just hardware.
    • [Ian] So to summarize, we'll look at the Programming/Updates Use Case from Volume 2 and see if we can expand that 'template' to cover the structure and behavior?
    • [Brad] Have agreed that we should use the Programming /Updates Use case?
    • [Ian] OK, lets vote on that.
    • {Brad moved to use the Programming/Updates Use Case as a sample study, seconded by Tim. No objections or abstentions, motion carried.}
    • [Brad] Should we also formalise the decision on loose coupling to P1687 and dot7? I'll so motion.
    • {Eric seconded, no objection or abstentions. Motion carried.}

5. Key Takeaway for today's meeting

  • [Eric] We need to narrow our scope.
  • [Brad] SJTAG should only be loosely coupled to other standards like P1687 and 1149.7

6. Schedule next meeting

Next Meeting:
October 17th (11:00 AM EDT, 4:00 PM BST)

Schedule for October 2011:
17th, 24th, 31st.
Brad will not be able to attend on 17th.
Eric may have difficulties joining.

7. Any other business


8. Review new action items

9. Adjourn

Peter moved to adjourn at 12:04 AM EDT, seconded by Brian.

Respectfully submitted,
Ian McIntosh

Proxy contribution from Brad:

Regarding the close coupling of SJTAG with P1687 and 1149.7, I have a strong 
opinion that SJTAG is independent and should support these activities as well as 
any others.  P1687 and 1149.7 are nothing more than specialized access 
mechanisms to data registers that reside within the 1149.1 family of protocols.  
Everything is still based on the 16-state TAP Controller.  That viewpoint also 
includes non-standard access mechanisms like the ASP and ScanBridge as 
compatible, but not compliant, mechanisms that may or may not be supported 
within an SJTAG domain.  The question that needs to be asked is, "How does the 
support of P1687 and 1149.7 differ from that of the ASP and ScanBridge protocols 
from an SJTAG perspective?"  There is both a hardware, architecture, and 
protocol variation for each of these.  This means they are all modeled 
differently for their specific implementation, but their objective is the same: 
provide communications access to instruction/data registers inside a device.  So 
some of what Harrison is saying about everything is an instrument is sort of 
right, but I would venture to say everything we can describe is an interface to 
a data register that may or may not have a described behavior associated with 
it.  P1687 and to a lesser extent 1149.7 seems to be the first standards in our 
realm  that are now describing register behavioral information.  
IEEE 1149.1-2012 will also be including some behavioral information for select 
instructions.  We are now on the verge of a major shift in the JTAG paradigm 
from what was normal in the past.  We are now crossing over into the realm of 
both structural classification and behavioral architectures described by 
subordinate standards.  Should SJTAG consider itself requiring the need for 
describing register behavior?  For gateway devices, this might be critical.  Can 
this be described in terms of a P1687 specification.  I claim not for the 
ScanBridge, which should be able to be described as a gateway instrument, but 
the control mechanism exists above the P1687 hierarchical domain layer since it 
relies on explicit TAP instructions and register pairs for its control and not 
subordinate controls.  One could bend the ICL, but the current PDL does not 
provide the bridging dependencies across the registers as required for the 
control model.  My NSDL handles TAP based architectures the same way as it does 
the P1687 architectures.  It is unfortunate the P1687 WG would not settle on 
this solution.  Michele and I have asked repeatedly in the P1687 group to have 
someone include the ScanBridge as one of the use cases.  We were told that 
device architecture is outside of the scope of the P1687 architecture and would 
not be considered.  That is a shame.

So I want to caution about the close coupling between SJTAG and the P1687 and 
1149.7 standards.  They are just two representational aspects that need to be 
supported.  More will come in the future - guaranteed.  There will be hardware 
interfaces required to access each of these standards (e.g., gateways in terms 
of 4-wire TAP to 2-wire translators and the P1687 SIB), that each standard is 
suppose to provide the necessary description to support it.  That is as far as 
SJTAG should have to go.  That is loose coupling and not tight coupling.