Minutes of Weekly Meeting, 2011-11-28

Meeting called to order: 11:06 AM EST

1. Roll Call

Ian McIntosh
Carl Walker
Peter Horwood
Heiko Ehrenberg
Adam Ley (left 11:55)
Brian Erickson
Brad Van Treuren (joined 11:09)
Tim Pender (joined 11:09, left 11:57)
Richard Foster (joined 11:09)
Harrison Miles (joined 11:24)

Patrick Au

2. Review and approve previous minutes:

11/14/2011 minutes:

  • Draft circulated on 11/15/2011.
  • No corrections advised.
  • Tim moved to approve seconded by Brad. No objections or abstentions.

11/21/2011 minutes:

  • Updated draft circulated on 11/23/2011.
  • No further corrections advised.
  • Brad moved to approve seconded by Brian. 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.
  • All - Give some consideration to what attributes/features they would consider essential in their 'ideal SJTAG gateway' - considered COMPLETE.

4. Discussion Topics

  1. Merits/demerits of basing our 'Dot0' on:
    - Exclusively using Test Mode
    - Chain selection and management
    • [Ian] We started to discuss this briefly last week and got some opinions but felt that this needed to go before more than the few people we started with at last week's meeting. Are either of these useful as boundaries for our 'Dot0'?
    • {Silence}
    • [Tim] I don't know how binding to Test Mode helps. Even in Test Mode you get into things like IO standards, etc.
    • [Ian] What I'm getting is that there's no great enthusiasm for either option?
    • [Heiko] One problem I have here is that you may want to do something with emulation at th system level. That's not strictly covered in 1149.1, so do we consider Test Mode to be 1149.1 compliant testing or something wider?
    • [Ian] That's a good question. In Harrison's absence I may be putting words in his mouth but I assumed that he was referring more to the UUT not having established it's functional state. So, wider than just 1149.1 compliance.
    • [Brad] I'm also concerned. I think this assumes that Test Mode is intrusive but there are things that can be done with SAMPLE that don't need you take the board out of it's functional state. I'm known for using SAMPLE to get a snapshot of the alarms on a board, so you can perform some check on the sanity of the boards operation.
    • [Ian] In summary, neither of the proposals seems to be very useful to us.
  2. Is there an 'ideal SJTAG gateway'?
    • [Ian] Again, we started on this last week.
    • {Harrison joined}
    • [Ian] Following on from Tim's question the week before on whether or not a P1687 SIB represented an ideal SJTAG gateway (we concluded it did not) I wondered if we could determine what an ideal SJTAG gateway would be.
    • [Ian] We suggested last week that there may be no single perfect device as requirements might vary significantly from application to application.
    • [Harrison] There's an issue of hierarchy; whether it's a gateway in Test Mode or a gateway not in Test Mode. There's a demarcation between those, but there's still the notion of a gateway.
    • [Harrison] A discussion I had recently brought out something I hadn't really considered: The ICL part of P1687 can be applied to SJTAG. In fact it's probably easier to talk about ICL outside of a chip than inside it.
    • [Brad] Perhaps you could define what you mean by Test Mode, Harrison. We were discussing that earlier.
    • [Harrison] By Test Mode I mean where you don't get the board fully operational.
    • [Brad] How does that relate to field test?
    • [Harrison] OK, that's introducing a third condition: There's a point where it's not operational, a point where's it's partly powered. Then there's the field condition, which I think is something separate.
    • [Brad] But it's still boundary scan based test.
    • [Harrison] The type of test is, yes, but that's not the issue; it's the management. The accomplishment is different.
    • [Brad] I'm thinking more of intrusive versus nonintrusive.
    • [Harrison] Now your're getting into the old telecom OA"M (Operations, Administration & Maintenance) perspective. You have the boards in different states depending on what needs to be performed on the board. There is In-Service, Out-of-Service, Standby, and Off. These are the basics and variations of this that people use.
    • [Harrison] So you have Monitoring while In-Service, Monitoring when it is not In-Service, but these are different levels of test that can take place depending on how much of the board is available for test.
    • [Brad] But you can't make it as simple as that. There are many things I can do that are non-intrusive, like take a sample of the state of all the alarm signals using SAMPLE that is non-intrusive. The board could be In-Service when that is done without affecting the system operation. There are many such 'tests' that can be performed.
    • [Harrison] What I was getting at is there are different levels a board may be able to be active in. As you bring a board up, only some of the board may be powered until other parts of it come to life. There are levels of testability for a board depending on how alive it is. I am not referring to the OA"M operational state of the board. That is just system state. I am referring to the operational state of the hardware as to how much of it we can test as we bring the board up.
    • [Brad] You're saying, I think, that Test Mode is dealing with a kind of manufacturing flow?
    • [Harrison] I am; I'm trying to keep those roles distinct.
    • [Brad] It sounds like Harrison's viewpoint is more that of an external tester. But I like the idea of having roles.
    • [Brad] Perhaps we should at a walkthrough of roles that board goes through? Board only test is different to system level test. Then you may have a power-on test which uses system resources which adds a wrinkle.
    • [Ian] Reuse of board level tests at system level was one of things that was mentioned as an aim of SJTAG, so it's in there.
    • [Brad] Salvage is a better term. At board test, the tester doesn't much care about what is driving the board edge. But once the board goes into a system that changes, so it becomes reuse with additional constraints. Salvage, rather than reuse.
    • [Tim] My ideal gateway would support multiple hosts, multiple chains and be addressable. It's be good to bring 'power' into it, say by sensing a logic level to detect power in the chains. It should have the ability to use discrete pins to select chains or daisy chain them, as this would help with test at an EMS. Maybe that should be a transparent mode. I'd want to be able to have a gateway in the chain of another gateway and be able to broadcast to all chains. A limitation of the scanbridge devices is the addressing protocol - I don't want to embed the address in the data stream, so the ASP is better.
    • [Brad] Transparency was also noted in Brocade's 2006 ITC paper where they used I2C to control the chain selection.
      Reusable, Low-cost, and Flexible Multidrop System JTAG Architecture, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4079299)
    • [Harrison] I2C is nice; it only uses 2 or 3 lines. You need to have some kind of interconnection protocol, and now you're putting the burden on the tools. Maybe some kind of variation of what Dot7 does?
    • [Ian] Whenever you introduce some additional control bus, like I2C, you create a complication for the tools, since you're likely also adding in some new physical interface to deal with, that's maybe strictly outside the normal domain of the tool vendors.
    • [Harrison] Look at how Dot7 did it. That may be the way to do it.
    • [Ian] Yes, but on the other hand, I2C maybe allows people to use existing parts rather than waiting for new silicon to come along.
    • [Brad] Back at one of the BTWs, maybe 2005 or 2006, Ben had Mike Westermeier and myself play Devil's Advocate in a discussion on languages. Mike presented a case that STAPL allowed them to do everything they needed. For the chain selection the problem space was abstracted through a message, so then it was up to the software to decide what to do with the message, so it was really independent of the protocol.
    • [Harrison] That makes a lot of sense. The tools will still have to deal with concurrency of testing; the tools will have to do other things.
    • [Brad] There are questions like how many MBISTs can you run concurrently. You may not have enough power pins on the device to support all the MBISTs running together.
    • [Ian] For reference, the presentations that Brad referred to are from BTW 2005 and are on the Stored Documents page on the SJTAG website.
    • [Adam] I can add that Gunnar Carlsson also presented some aspects of I2C in ATCA in work he did with University students.
    • [Ian] I don't think we hold copies of that.
    • [Brad] Gunnar also did STAPL++, dealing with concurrency.
    • [Ian] We do have that in our Stored Documents.
    • {Adam left}
    • [Ian] Should we maybe move the discussion of gateways onto the forums? I feel it needs each person to list out their bullet points and that maybe isn't going to work well in the meeting.
    • [Brad] I'm not sure. There may be other things, like the control, that are more important to consider.
    • [Ian] Well, we don't need to constrain what types of things we put into a forum discussion.
    • [Tim] Maybe it'd provoke some thought, before we meet again.
    • [Tim] I see the ideal gateway may work in local mode or remote mode.
    • [Ian] Treat the forum as a kind of wish list; don't be held to what current devices do.
    • {Tim left}
    • [Harrison] I see ICL as being useful - is there a hierarchy role related to the mode? There needs to be some control plane; maybe more important than 'what does it do?'
    • [Brad] The whole point of the primitives work we did was to come up with requirements for a gateway, but we always disagree. What we described in the primitives was really no different to P1687 - the SIB is a bypass element with a 1-bit control. I think we can still maintain the abstraction at the primitive level.
    • [Ian] Yes, that was where we got to, but at that point we kind of burned out.
    • [Brad] It's a question of what constitutes a system. Not the control aspect, it's structural, and something scalable.
    • [Harrison] I like that approach.

5. Key Takeaway for today's meeting

  • [Brad] We identified that restricting ourselves to Test Mode for our Dot0 is not a good thing.
  • [Brad] Chain management has a structural aspect and a control aspect.

6. Schedule next meeting

Next Meeting:
December 5th (11:00 AM EST, 4:00 PM GMT), Heiko expects to miss this.

Schedule for December 2011:
12th, Carl and Brad will likely miss.
19th, Ian and Brad will likely miss.

First meeting in January 2012 is likely to be Jan 9th.

7. Any other business

Harrison will aim to have his industry sector illustration available for the meeting on December 5.

8. Review new action items

  • Ian - Create new forum discussion topic on attributes of the ideal SJTAG gateway.
  • All - Respond to forum gateway topic with any opinions on what makes a gateway suitable for use in your application field(s).

9. Adjourn

Brad moved to adjourn at 12:09 PM EST, seconded by Peter.

Thanks to Brad for supply notes for part of the discussion that I missed

Respectfully submitted,
Ian McIntosh