The System JTAG Working Group

Minutes of Weekly Meeting, 2009-10-26

Meeting called to order at 10:39 AM EDT

1. Roll Call

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

Excused:
Tim Pender

2. Review and approve previous minutes:

10/19/2009 minutes:

• Draft circulated on 12th October:
• One correction noted:
  • In 4b, change one instance of 'Post' to 'POST' (towards end of 4b)
• Eric moved to approve with the above amendment, seconded by Carl. 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?
• Establish whether TRST needs to be addressed as requirements in the ATCA specification if it is not going to be managed globally (All)
• Adam review ATCA standard document for FRU's states
• All to consider what data items are missing from Data Elements diagram
• 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
  (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
• Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
• All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
• Harrison: Virtual system exploiting Configuration/Tuning/Instrumentation and Root Cause Analysis/Failure Mode Analysis Use Cases. - Ongoing
• Brad: Virtual system exploiting POST and BIST Use Cases. - Ongoing.
• Ian: Virtual system exploiting Environmental Stress Test Use Cases. - Ongoing
• Brad: Supply draft wording for pop-up help for Question 7.6 - COMPLETE
• Ian/Brad: Prepare 'virtual systems' to support walk-through of two Use Cases. - COMPLETE

4. Discussion Topics

1. 2009 Survey
   • [Ian] Brad supplied text for the tooltip for 7.6 - this was the insertion of resynchronization bits with some gateways.
   • [Eric] And it's a big helper, isn't it?
   • [Ian] Yes it was quite long, but I couldn't see how I could make it any more concise. Oh! I see, I haven't formatted the text into a block. I also see that I still need to remove the help icon from 7.5, now that we've taken the help away from that question.
   • [Ian] Are there any further changes we want to make at this stage?
   • [Brad] I think we've run out of any more questions to ask. If we try to think of anything else then it'll be next year before we release the survey!
   • [Brad] When do you want to release the survey? I think in the roadmap you had this down for early November or maybe the end of October?
   • [Ian] I'd like to get it out as soon as possible now, but I don't want to send out invites towards the end of a week: People are likely to put them aside to deal with later, then the weekend will pass and it's forgotten about. It may be better to launch over a weekend so the invites are in inboxes on the Monday morning.
   • [Eric] I'd agree with that.
   • [Ian] I need to make the edits to the survey form, and reactivate the referral emails, which I turned off during testing to prevent anyone getting an invite by accident, and then flush out the test data from the database. I'll set the form version to v1.00. {ACTION}
   • [Ian] So, we may be able to release next weekend.
   • [Brad] Maybe next week we can go through each question to establish what we expect to learn from it to help us when we start sifting the data?
   • [Ian] Yes, we can do that. We probably can't cover the entire form in one session, but I guess we can afford to take a few weeks over that; we planned to run the survey for eight weeks, so we can use most of that time.
   • [Ian] I'm just thinking that next week is ITC. That means that some of our targets may not be 'online' much. Maybe we're better to leave the survey until after ITC, the weekend of 7th/8th. Our eight weeks then takes us up to the Christmas break, which might work quite well.
   • [Brad] I think that it'd be good to get clear of any of the ITC email that will be around next week.
   • {Brad moved approve release of the survey, seconded by Eric, no objections or abstentions}
   
   
2. White Paper Review - Review of Virtual Systems
   • [Ian] The action on this from last week is possibly superseding the earlier actions we had on virtual systems, but we can consider that later.
   • {Forum post displayed}
   • [Ian] Brad posted up a few diagrams with some notes and I followed with one looking from a different perspective.
   • [Brad] What I was trying to do was to decompose into what were the functional elements of an embedded system for POST and Remote Update. I was trying to get at what was within the system. For example, you need to have a Board Manager that tells the system that the board is there and manages the power up.
   • [Brad] Also, instead of just referring to 'memory', I tried to break out the different types of storage that we need; vector storage, result storage, etc.
   • [Ian] I felt that this was more of a software architecture we were describing here.
   • [Brad] In part, but I've seen where that first block has been purely hardware.
   • [Ian] Since Brad was looking at the embedded case, I deliberately took an externally controlled example for my EST model, where we have an EST Test Manager that controls both the applied environment and the BSCAN element. I felt in this case that I could merge some of the things that appeared in Brad's diagrams into the BSCAN Test Manager as largely all just 'software tooling' to the end user, but maybe that's going too far.
   • [Brad] In our EST we are basically leveraging the onboard System Diagnostic Controller, which takes away a lot of the external hardware. With the external tester case, you need to run the TAP signals from the outside world to the UUT in the chamber. In some of our cases that would be 50 feet long. Instead, we opt to leverage the embedded tooling via the same ethernet interface used for the console and functional test access. This, however, requires the on-board system software to be running. If a failure occurs there, the diagnostics is dead. So the external case presents a level of diagnostics that is available even if the system software ceases to work.
   • [Ian] And that may be a more practical and robust way to do EST. But some of the diagnostic may come from knowledge of the applied environment, which the BSCAN Test Manager doesn't have.
   • [Brad] I think that's a good point you make, that the EST Test Manager has awareness of the whole situation. In our case, you can substitute your BScan Test Manager with the System Diagnostic Manager in my diagrams so there is still an external EST Test Manager that leverages the BScan test resources of the embedded platform via the System Diagnostic Manager through the ethernet interface as messages.
   • [Ian] It's not really any different for your embedded case though; your Board Diagnostic Agent or System Diagnostic Manager may be in the same role.
   • [Ian] The boundaries aren't clearly defined and where various functions lie is indeterminate. For my EST the diagnostics could be tackled several ways: The BSCAN diagnostics could be relayed to the EST Manager to be tied up with the environment data; the EST Manager could perform the diagnostic based on both the BSCAN results and environment data, or there could be a human in the loop making a judgement call.
   • [Brad] The BSCAN Test Manager may output results in many different formats, depending on the vendor. This makes it difficult to define an API to interface to those results.
   • [Brad] One thing that these diagrams are making clear is that BSCAN needs to be a 'plug-in' to something else, so just a GUI tool is not going to be sufficient for SJTAG.
   • [Ian] I agree. I'm not sure that this insight has come across in our previous analysis, certainly not in such a solid way.
   • [Brad] That's why I was pushing for these virtual systems.
   • [Ian] I'm glad you posted your diagrams first, Brad, I think I probably didn't catch what you were getting at when virtual systems were first mentioned and I think I'd have gone the wrong way and been too concerned with the scan chain detail within the UUT.
   • [Ian] I used to think that standardizing the topologies would help the tooling, but now I feel that so long as the tooling can understand the gateways, the topology probably doesn't matter too much.
   • [Brad] I'd say so.
   • [Brad] I think we do need to decompose things like the BSCAN Test Manager. It may be that it's a matter for the tool vendors, without exposing too much of how they do things.
   • [Ian] I am thinking that this may be about to spawn a 6th volume for our White Paper.
   • [Brad] I'd had that thought but was hesitant to say it.
   • [Ian] Could it be some software architectural diagrams that we use to underpin the data and languages in Section 4?
   • [Brad] Any API is going to need to be broken out separately from the data. Some of the big wins in future-proofing come from having that decoupling of the data. You don't want to have a new firmware release because you want to add some tests: That causes trouble for the end user.
   • [Ian] It's sounding like the 'Brad and Ian Show' here; does anyone else have any comment?
   • [Heiko] I like the 'Brad and Ian Show'! I've not really had a chance to take in the posts yet.
   • [Peter] Same here.
   • [Ian] OK. I found I needed some time to absorb Brad's post, although it's straightforward enough once you get into it. I guess we'll make it an action for everyone to read over the thread for next week. {ACTION}

5. Schedule next meeting

Schedule for November 2009:
Monday November 2, 2009, 10:30 AM EST
Monday November 9, 2009, 10:30 AM EST
Monday November 16, 2009, 10:30 AM EST
Monday November 23, 2009, 10:30 AM EST
Monday November 30, 2009, 10:30 AM EST

• Adam and Heiko probably won't make 2nd due to ITC commitments
• Brad has a conflict for 9th
• Tim won't make 23rd

6. Any other business

• [Ian] Brad asked me to make some comment regarding the use of the forums, as he has encountered some problems.
• [Brad] Yes, that's right, and I found the process of finding the cause interesting.
• [Ian] The problem is basically that when creating large posts, you can end up being asked to log back in because your session was no longer valid. When you do this, you then find that your work is lost, and that's frustrating.
• [Ian] I tried a few things to fix this, like increasing the session idle timeout from 3600 seconds to 7200 seconds, but Brad still had problems.
• [Ian] What I found recently was that Brad's IP address was changing if his connection went idle for a while. As a security measure, the forum software checks a user's IP address to validate the session ID. The check was testing the first three bytes of the IP address, which allows for proxies using dynamic IPs. However, Brad's IP was often changing in the third (subnet) byte, which would fail the test. I modified the rule to test only the first two bytes instead, which should now have fixed the problem.
• [Ian] However, it probably still worth taking some precautions when making a large edit: Either, as Brad did more recently, submit your work frequently, then reopen it for edit; there's no problem in doing that, or work up your edit offline then paste it in. It's maybe a bit messy, though.
• [Carl] It may be messy but it's safe.
• [Brad] While I was making my edits, I kept a note at the bottom of the post to tell anyone that it was work in progress. That was to stop anyone replying before I'd finished.
• [Ian] Some public forums block editing of a post once a reply has been made, as sometimes this can invalidate the later posts, but we can afford to be more relaxed about our rules, and posts can be edited at any time. I guess the only problem is people replying prematurely to an incomplete post, which Brad's footnote was addressing.
• [Ian] Does that cover what we needed here, Brad?
• [Brad] Yes, it was really to make sure people were aware of the possible problem.

7. Review new action items

• Ian: Tidy survey questions 7.5 and 7.6, reinstate referral emails, and flush database.
• All: Review 'straw man' virtual systems and notes on forums:
  http://forums.sjtag.org/viewtopic.php?f=29&t=109.

8. Adjourn

Eric moved to adjourn at 11:29 AM EDT, seconded by Peter.

Respectfully submitted,
Ian McIntosh