Minutes of Weekly Meeting, 2009-09-21

Meeting called to order at 10:38 AM EDT

1. Roll Call

Ian McIntosh
Tim Pender
Brian Erickson
Carl Walker
Brad Van Treuren
Peter Horwood
Eric Cormack
Heiko Ehrenberg (joined 10:48)

Patrick Au
Adam Ley

2. Review and approve previous minutes:

9/14/2009 minutes:

  • Draft circulated on 15th September:
  • Three corrections noted:
    • [Brad] Yes, that's pretty {much} where my comments were heading.
    • [Brad] And mean more value add{ed} for including JTAG in the system.
    • [Brad] In the past ... very common. It does {of} course add extra cost.
  • Brad moved to approve with the above amendments, 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
  • All: Test at least part of the draft survey form and provide comments through forums. - Ongoing.
  • Brad/Brian/Ian: Develop "Application Fields" descriptions for Device Versioning on the forums (http://forums.sjtag.org/viewtopic.php?f=14&t=52). - See discussion 4a

4. Discussion Topics

  1. White Paper Review - Continuation on Device Versioning
    • [Ian] We started off a discussion on the forums to fill out the Application Fields section. I pulled a couple of paragraphs from Brad's post that I felt worked as an introduction. Brad then added some more thoughts and Heiko pointed out that dissimilar boards could return identical sets of IDCODES.
    • [Ian] Given that the discussion hasn't yet produced recommended text for the wiki, we could either discuss it now or continue it on the forums.
    • [Brad] The momentum on this is on the forums. I think it best to continue it there.
    • [Eric] That seems fair. And I agree with Heiko's comment on the IDCODES.
    • {Heiko joined}
    • [Ian] So let's move on to Tooling Requirements {wiki text read out}.
    • [Brad] Some tooling allows multiple IDCODES which can help support using parts from more than one vendor, but there are complications. There is a finite number of mappings possible, so if you use several vendors and each has several compatible parts you can easily run out of available mappings.
    • [Brad] The handling of USERCODE in BSDL is cumbersome. Even some of the suggested BSDL extensions don't play out, because they still point to one reference.
    • [Ian] So something like indirectly referencing a file outside the BSDL for those values would help?
    • [Brad] It's bigger than that. It needs to be an indirect to a set of mappings. Then there's USERCODE.
    • [Tim] USERCODE gets programmed in when you change the firmware.
    • [Brad] The register description is in the BSDL. The contents may or may not be in the BSDL.
    • [Tim] Generally there is no data in the BSDL for USERCODE prior to configuration, but may be inserted into the post-config BSDL.
    • [Ian] Meaning that Device Versioning has to be a post-config operation.
    • [Peter] Some PLD vendor tools will auto increment the USERCODE on each programming operation so you can effectively serial number the boards. I don't think many of the third party tools do that.
    • [Ian] No, but how useful is that for us? It wouldn't tell us if the firmware in two devices is the same or different. It'd be more useful for the development tools to autoincrement the USERCODE when you commit a new firmware build, at the VHDL sources.
    • [Peter] Yes, for each new revision.
    • [Brad] With PLDs and PROMs you have the question of whether they're programmed before or after assembly.
    • [Tim] Why does that matter?
    • [Brad] You could build a board with preprogrammed parts that are out of date.
    • [Brad] The tooling then has to identify the installed version and apply the update.
    • [Tim] The way things are now, you almost need a BSDL per device even if they have the same code: You may have different I/O depending on where the device is installed.
    • [Brad] That's true of memory interconnect, where setting the driving parameters can only be done post-configuration. More than just device type has an effect. The conventional methods run out of steam when we start dealing with these dynamic configuration cases.
    • [Brad] Then we have tunable devices, changing parameters rather than firmware.
    • [Tim] Do you have an example?
    • [Brad] Power Conditioners, where voltage levels can be set through 1149.1 or SERDES where you can set things like predistortion.
    • [Ian] That's more the sort of example I had in mind. But does this actually have an effect on Device Versioning?
    • [Brad] Well, they use firmware registers and could be persistent A register with the firmware version would be in the same category.
    • [Ian] OK, can we start pulling these ideas into the Tooling Requirements?
    • {Started editing wiki}
    • [Brad] One requirement is that there needs to be a set of CODES; currently BSDL really only supports a single CODE.
    • [Brad] The support for device options is important. We found a CM who had changed a part without our authorisation that way.
    • [Brad] Rather than just passing or failing, we may want to change the flow of a program based on the result of a test. SVF can't do that; STAPL can to a limited extent.
    • [Ian] Yes, it's like we want to get down to individual device registers, but most tooling has gone in the direction of a vector that's abstracted from the registers, in favour of getting simple go/nogo results.
    • [Tim] Along with that, you may want check a USERCODE against a mask; there may be a range of builds that I don't need to apply an update to.
    • [Brad] What Tim's asking for is a kind of bit arithmetic. STAPL can give you some of that capability.
    • [Ian] OK we're not going to get any other section of this Use Case done this week. We've spent a long time on this use case.
    • [Tim] I think it's because it's go so many complications.
    • [Ian] Yes, that's true, but I'm a bit worried that we're in danger of over analysing this one, compared to the other Use Cases.
    • [Brad] I was having that thought too.
  2. 2009 Survey
    • [Ian] There's not too much to say here today. The form was updated with the suggestions from last week's meeting, so it's now at version 20.
    • [Tim] Is the version on the form or just in the page with the link?
    • [Ian] There should be a version mark at the foot of the form.
    • [Eric] Yes, right at the bottom, below the Submit Form and Rest Form buttons.
    • [Ian] I was thinking of adding questions on the scale of jobs where people would or would not apply SJTAG, but I think it's getting too late for adding things like that now. I really want to get this survey through to completion now, without rushing it.
    • [Ian] Probably the main things to concentrate on are adding any tooltips and checking it all works, so please try to use the form.

5. Schedule next meeting

Schedule for September 2009:
Monday September 28, 2009, 10:30 AM EDT
Patrick may be absent for 9/28

Schedule for October 2009:
Monday October 5, 2009, 10:30 AM EDT
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

6. Any other business

Gunnar has been in contact and may be able to join some calls in future. Brad noted that it may be worth reminding Gunnar that he could make comment by proxy.

7. Review new action items


8. Adjourn

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

Respectfully submitted,
Ian McIntosh