Print

Minutes of Weekly Meeting, 2009-06-15

Meeting called to order at 10:35 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Brian Erickson
Carl Walker
Tim Pender
Brad Van Treuren
Heiko Ehrenberg
Adam Ley (joined 10:40 AM)

2. Review and approve previous minutes

6/8/2009 minutes:

Eric moved to approve with above amendment, Carl seconded, no objections.

3. Review old action items

{Adam joined the call}

4. Discussion Topics

  1. White Paper Review
    • [Ian] I'm hoping to kill two or three birds with one stone today: I'd like to see the White Paper move forward, in particular, Volumes 2 and 3, so I thought we could look at Volume 2, Uses Cases, today. In the e-mail exchanges last week, Brad mentioned a 'spiral development model' and since it's about a year since we last seriously visited the Uses Case discussions, we can see if we have any new perspectives, especially since we have newer members who were not part of those prior discussions.
    • [Ian] We'll take Cases as they appear on the wiki.
       
    • Structural Test
    • [Ian] This is probably pretty well complete. I guess it's the most established use and the one Heiko is most familiar with, so he able to write this one up fairly easily.
    • [Heiko] Yes, that's pretty much the case.
    • [Brad] Do we have a definition for MTC in point 8 of the Detailed Description?
    • [Heiko] Maybe Maintenance Test Controller or Master Test Controller?
    • [Eric] Test Controller anyway.
    • [Ian] From the context, I'd say Master Test Controller. Do we know where it originated from?
    • [Heiko] It was in the SJTAG Use Scenarios 0.2, that Brad mailed out on 17 October 2007: "MTC is our own Protocol Manager IP".
    • [Brad] OK, that was something that was shared at BTW 2006.
    • [Ian] We should get things like that added to our Glossary.
    • [Ian] Anything we need to change here?
    • {Silence}
       
    • Configuration/Tuning/Instrumentation
    • [Ian] We have a large introductory passage here compared to that for Structural Test, but nothing in the Detailed Description. I suspect we could move some text from the introduction.
    • [Brad] Yes, the introduction to each section shouldn't be more than a paragraph. The first three sentences would be fine for an introduction.
    • [Ian] OK, we'll move the rest to the Detailed Description.
    • [Brad] Maybe we should comment on the overlap with Fault Injection here; we've used this to make a power controller think we've had a power failure. Also carries over into Root Cause Analysis.
    • [Ian] There is overlap in a few Use Cases: There may be scope for a Venn Diagram illustration similar to the SJTAG Universe.
    • [Brad] The point here is that this is about gaining access to information in the system, rather than testing the system. We can maybe include a link to the Xilinx Application Note on the GNAT interface.
    • [Ian] If it's publicly accessible then, yes. It's possibly more accessible to people that the P1687 description of instrumentation.
    • [Brad] Perhaps we should also mention coordination with other interfaces such as I2C?
    • [Ian] I think that takes us into Alternative Techniques: Really it's the same thing, just a different way of accessing it.
    • [Brad] Yes, that the point. It's the same data registers; there are functional means of access, I2C, etc., but 1149.1 can also give you the same access.
    • [Ian] Can we say anything about tooling?
    • [Brad] Tooling needs to be aware of other devices in the chain. Aware of Chain Management requirements, fo example you don't always want power management devices in the chain all the time. Lattice have a tool for their Power Management devices but it makes very simplistic assumptions about the chain.
    • [Ian] We tend to put our power management devices in their own chain for that reason, but it's often not the best architecture.
    • [Brad] Especially if you want to try simulating failures.
       
    • Software Debug
    • [Ian] I think from 'Primary Goal...' onwards can be split off into the Detailed Description or other sections.
    • [Brad] Maybe we reference one of the things that Jim Webster has talked about: The TI Linking Addressable Scan Port has two additional signals. Jim has used these to pass through HRESET and SRESET to provide support for emulation.
    • [Ian] I guess that could go into Alternative Techniques.
    • [Brad] The real enabler comes with 1149.7.
    • [Brad] Right now, mostly, you need to reset to go into debug mode, so you lose all the state information of the hung board, which isn't real useful.
    • [Brad] Nexus was able to extract certain information.
    • [Adam] 1149.7 had some coordination with Nexus, but didn't really use anything from there.
    • [Adam] Dot 7 doesn't address emulation methodologies, just the means of access.
    • [Ian] Nexus could be linked in the Alternative Techniques section.
    • [Brad] The JTAG only access of Dot 7 is what caught my eye. Ideally you could have a Power PC and a DSP and the emulation tools all access through the same chain instead of having several pods hanging off boards.
    • [Tim] Does that mean the tools will have to use a standard language?
    • [Brad] Or a standard interface that we would define. 1149.1 gives you the hardware standard. SJTAG then gives you the software standard, but in a way that doesn't expose the proprietary information in the tooling.
  2. 2009 Survey
    • [Ian] As we noted during the review of actions, there has been no further progress on the survey.

5. Schedule next meeting

Schedule for June 2009:
Monday June 22, 2009, 10:30 AM EDT - Brian cannot attend
Monday June 29, 2009, 10:30 AM EDT - Tim cannot attend

6. Any other business

7. Review new action items

8. Adjourn

Heiko moved to adjourn at 11:38 AM EDT, seconded by Brad.

Thanks to Heiko for additional notes this week.

Respectfully submitted,
Ian McIntosh