Print

Minutes of Weekly Meeting, 2009-06-29

Meeting called to order at 10:36 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Carl Walker
Brad Van Treuren
Heiko Ehrenberg

Excused:
Adam Ley
Tim Pender

2. Review and approve previous minutes:

6/22/2009 minutes:

Eric moved to approve, Heiko seconded, no objections.

3. Review old action items

4. Discussion Topics

    1. White Paper Review
        • [Ian] Heiko made most of the changes to BIST and Fault Injection prior to the meeting last week. I haven't had time to check whether all the things we discussed have found their way into the wiki.
        • [Heiko] I tried to do a few things during the call but there are other things that still need to go in.
        • [Ian] We didn't note any consequences for Fault Injection. Is that because we don't see any negatives?
        • [Brad] We didn't identify anything. I guess we should note that most devices don't support pin level control, so you may need to add some special logic. FPGAs lend themselves to that quite well.

         
    2. Programming/Updates
    3. [Ian] No text has been moved around yet and it looks like these are really just notes in this section.
    4. [Heiko] It's pretty much just the notes from the previous discussions; mainly the notes from the forums.
    5. [Ian] Section from "Categorization of programmable items..." loooks like it should be in the detailed description.
    6. [Brad] And the list above it goes into "Application Fields".
    7. [Ian] The discussion of the programming time for large Flash memories seems like "Consequences".
    8. [Ian] Use of high speed busses belongs in "Alternative Techniques".
    9. [Brad] And you add to that the use of parallel loading techniques.
    10. [Brad] Regarding the third bullet, changing the firmware as you go through assembly stages: I see more of a lifecycle issue, with software being developed in parallel with the hardware, so new releases need to be loaded. Then there's updates that need to be applied in the field.
    11. [Ian] Yes, but I do see the orignal case here: We may have identical hardware that goes on different aircraft and so gets different software. But we don't want a new test harness for every variant so we have a "test load". It may also be that the test load has better diagnostics capabilities than the mission load.
    12. [Brad] We often get locked in to the software for testing, because its part of the customer requirement. I think you're the same Carl?
    13. [Carl] We get into some of those; we have the cases of off-line testing vs on-line testing. We have our Production Diagnostic tests and then what we call IVT - Infrastructure Validation Testing - with traffic passing through the unit.
    14. [Brad] The system software at delivery needs to contain whatever field diagnostics you intend to make use of.
    15. [Carl] My problems are slightly different. Typically the products have network connectivity, and we can suggest to the customer that we can run some software of our own to diagnose problems. But then there are also some secure networks.
    16. [Brad] As we get into autonomous networks, we get more like the situation Ian describes. That's where tailoring or altering a system to change it's personality on the fly starts to become important.
    17. [Carl] Definitely true, although it's difficult to see what these future needs will be.
    18. [Brad] We haven't addressed the issue of fall back; having a saved image that can be used in case the update fails for some reason.
    19. [Ian] Probably goes into "Consquences". An important point.
    20. [Carl] It's also worth noting that JTAG is often the fall back if other programming methods fail and the board won't start.
    21. [Brad] Maybe we can contrast the concurrency you can get when using local control vs multi-drop external control. Each have issues.
    22. [Ian] It's certainly worth noting.
    23. [Brad] It's part of the value proposition that even if it takes 2 hours to program via JTAG it may be worth trying in parallel with sending out an engineer with a replacement part.
    24. [Heiko] I'm looking for better word for "items" in "Categorization of programmable items". Maybe "programmable targets"?
    25. [Brad] Yes, that sounds better.
    26. [Ian] Can we list the techniques for speeding up Flash programming? There's the "Skip FF" method.
    27. [Brad] Yes, where you know the block was already FF. There's the method of using user registers to create a short chain for programming attached Flash. Write pulse can be harder to use in a pure BScan application.
    28. [Ian] We certainly tend to use Write Pulse.
    29. [Brad] I don't see it much in embedded, if you try keep to pure BScan. We can deal with it in our TFCL though.
    30. [Heiko] There's the option of using emulation features.
    31. [Brad] That could fall under "Alternative Techniques".
    32. [Brad] Tooling: I think there are ways of doing this that don't require any additional circuitry. Special software may be needed to control the chains that may not be part of vendor tools. Then there is the models for Flash devices.
    33. [Brad] There are issues with some devices that need to have preloads in the FPGA before using it to program the configuration PROMs. Another thing to remember is that most FPGA IO will default to something like TTL, while many Flash devices may be expecting LVTTL, so you need the FPGA configured, and a BSDL for the configured IO. This can then get into tooling requirements.
    34. [Ian] Sounds like more for "Consequences".
    35. [Ian] I don't think we have time to start on Root Cause Analysis today.

 

  1. 2009 Survey
    • [Ian] I've made a start on the form processing now. I hope to have the database side of things working by maybe midweek, then we can start testing the form properly.
    • [Brad] I hope to get some time this week to work on the Gateway questions.
    • [Ian] I only need to put placemarkers in to link the database to the form: It won't matter if the questions change or some get deleted.
    • [Brad] OK, that's good.

5. Schedule next meeting

Schedule for July 2009:
Monday July 13, 2009, 10:30 AM EDT
Monday July 20, 2009, 10:30 AM EDT
Monday July 27, 2009, 10:30 AM EDT

6. Any other business

7. Review new action items

8. Adjourn

Eric moved to adjourn at 11:34 AM EDT, seconded by Brad.

Thanks to Heiko for additional notes.

Respectfully submitted,
Ian McIntosh