Minutes of Weekly Meeting, 2009-10-05

Meeting called to order at 10:36 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Brad Van Treuren
Carl Walker
Patrick Au
Peter Horwood
Adam Ley
Tim Pender
Heiko Ehrenberg (joined 10:37)


2. Review and approve previous minutes:

9/28/2009 minutes:

3. Review old action items

4. Discussion Topics

  1. White Paper Review - Filling the Gaps
    • [Ian] We've got a handful of paragraphs to complete that are mainly sections that were added after we'd reviewed those Use Cases. I've already been round these and made sure the is some text in each section but it will need to be reviewed and expanded.
    • [Ian] The first is Consequences for Configuration/Tuning/Instrumentation.
    • {Current text read out for the benefit of dialin attendees}
    • [Brad] Indirect access may be too time consuming if the chain is too long.
    • [Ian] So you may decide to construct a short chain within an FPGA to address that?
    • [Brad] Indeed.
    • [Tim] Can you give an example of what is meant by a Functional Register?
    • [Brad] Well, maybe there's something like a Memory Mapped Register that you're trying to write to while there's no firmware on the board yet, or if you have multiple processors on a board, like a main processor and some DSPs, and you need to configure one of the DSPs that do not have a console interface available.
    • [Brad] Thinking of P1687, it may be a problem if there is coordination needed between two devices, especially if they're in different chains.
    • [Ian] I don't think that's specifically a P1687 issue; what you say would be true in any case.
    • [Brad] Yes, that's right and I'm thinking about maybe where you're tuning a SERDES link and the devices are on different boards.
    • {Wiki edited}
    • [Ian] The next section is the Value Proposition for Software Debugging.
    • {Current text read out}
    • [Brad] With NEXUS you can do interrogation of the processor even it's hung. You don't need to use HRESET or SRESET, which destroy the state you may be trying to investigate.
    • [Adam] Does that depend on sideband signalling?
    • [Brad] The stuff I've seen so far works without sideband signals.
    • [Adam] Dot 7 teaches that you should be able to hot plug to the devices without disruption.
    • [Tim] I'm not sure about this - JTAG uses SRESET and that's disruptive.
    • [Brad] The most important thing to mention is that access can be from the board edge, so you don't have to use an extender and fit an emulator, and that means you keep all the backplane connections as they would be in normal use.
    • [Ian] So this goes at the top of our list?
    • [Brad] I'd say so.
    • [Brad] If Jim Webster were here he'd mention his use of LASP, where he used the extra signals that are routed through the gateway for HRESET and SRESET.
    • [Tim] There may be a number of digital I/O signals like that you may want to use, so you might multiplex them once you get past the gateway, otherwise you could end up with 32-bits.
    • [Tim] How can you access register without disrupting the processor? I might want to see the stack pointer, to see where the crash happened.
    • [Brad] For ARM the CAPTURE DR returns the Stack Pointer, Program Counter and certain other registers, and CAPTURE DR is nonintrusive. It's quite limited. You're not able to do an UPDATE DR, for example.
    • [Tim] I have had some issues with compliance pins, where I was using one processor to set the compliance pins on a second processor. Some of the tests included hard coded resets and it all broke down.
    • [Brad] That's the sort of case where you need to define your signal conditioning in a precondition file for a test. This means the tooling needs to adhere to your preconditioned signal states when initializing the test algorithm and not perform a TAP reset. In some cases we had to record the test as an SVF and hand edit out the TAP resets to get it to work. Most of the tooling provide the conversion of the test to SVF or STAPL as a workaround to overcome this problem.
    • {Wiki edited}
    • [Ian] That takes us on to the Consequences for Software Debugging.
    • [Brad] Tooling doesn't allow for multiple interfaces to exist within the same scan chain; you can't have a Motorola and TIdsp together.
    • [Adam] That should be addressed within 1149.7.
    • [Brad] It still needs to be in the tooling. Dot 7 will facilitate this from the physical perspective.
    • [Brad] Devices with multiple cores, like System on Chip or Multi-Chip parts need not have TAPs for each core.
    • [Ian] Again, that's something that Dot 7 is heading towards.
    • [Brad] Should we be making the point that Dot 7 is going to be a major factor for this use case and that SJTAG should provide the access to Dot 7 from the system level?
    • [Ian] Yes. I don't think we've mentioned it much so far other than a passing mention in Volume 1, but Volume 3 seems the right place for that.
    • [Brad] You're probably right.
    • {Wiki edited}
    • [Ian] We're running over time today, so we'll need to come back to this: We only have BIST Value Proposition and Fault Injection Consequences to do.
  2. 2009 Survey
    • [Ian] I've added some pop-ups, which can go over, but first on question 5.10 in diagnostic granularity I felt we were missing an option: We talk about "Go/NoGo" but that probably needs to be broken down into Go/NoGo for the system and Go/NoGo for each of the FRUs in the system. The latter is the minimum we'd expect when testing a box at a second line repair facility.
    • [Brad] I'd agree.
    • [Eric] Yes, you need both those.
    • [Ian] OK I'll add that.
    • [Carl] Regarding the pop-ups, I found that the larger one with the diagram was obscuring too much. Could it be moved out of the way? Can you control the offset?
    • [Ian] I can control the offset. I can also make it fade out after a delay.
    • [Brad] Some of the map tools have pop-ups that can be pinned and dragged where you want them. I don't know if that's possible here.
    • [Ian] I think I can do that; I need to check the documentation. I can also add a Close button.
    • [Brad] Yeah, the map tools have that too.
    • [Tim] Is there something to tell you which questions have help?
    • [Ian] Not really.
    • [Brad] You have a kind of icon at the question numbers. There could be a different icon for questions with help.
    • [Carl] Or a question mark or something over at the right hand side? I don't want to make it to difficult.
    • [Ian] Hmm, adding a fourth column might be too much work at this stage. The icon isn't too difficult. What is the main objective - is it to keep the answer options clear, because I could easily set the pop-up to only work over the question?
    • [Carl] Do any questions have a different pop-up for the answers, if not you put a hyperlink on the question text?
    • [Ian] Yeah that could be done too. I guess I need to see what options there are for this.
    • [Ian] As we're way over time I'll quickly go over the pop-ups we have now.
    • [Ian] In 6.3 do we agree on the help text?
    • {Agreed}
    • [Tim] Should all these Yes/No question have a "Don't know" option?
    • [Brad] I'd say so.
    • [Ian] OK.
    • [Ian] And for 6.4?
    • [Brad] This was really trying to get Gunnar's idea of running one of a number of tests stored on the board.
    • [Ian] Selecting which test to run.
    • [Brad] More that there's a system level controller at a higher level that is controlling which test is to run by the board level controller on the board.
    • [Ian] OK. I'm not sure about 6.5.
    • [Brad] There's still a lot you could ask about the help.
    • [Carl] It one of those things where you either know about object orientation and it just makes sense or you don't know.
    • [Ian] I'm worried that by explaining it, we'd be leading the user to a "Yes" answer. Maybe we're better to drop the help?
    • [Brad] That may be the most appropriate choice.
    • [Ian] We don't really have time for any more. There are a few placeholders in section 7 that you should look over. {ACTION}
    • [Ian] In the meantime, I'll update the form as discussed here. {ACTION}

5. Schedule next meeting

Schedule for October 2009:
Monday October 12, 2009, 10:30 AM EDT
Monday October 19, 2009, 10:30 AM EDT
Monday October 26, 2009, 10:30 AM EDT (2:30 PM GMT)

Eric will be absent for a two week period mid to late October.
Carl cannot attend on 12th.

Carl will send out new Outlook Meeting Reminders to begin from 19th October. It is probable that this will change the Meeting ID number, so the WebEx link will change (dialin numbers will be unchanged).

6. Any other business

7. Review new action items

8. Adjourn

Peter moved to adjourn at 11:55 AM EDT, seconded by Patrick.

Respectfully submitted,
Ian McIntosh