The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-08-27

Meeting called to order at 8:20am EDT

1. Roll Call (Participants):

Ian McIntosh
Carl Walker
Carl Nielsen
Patrick Au
Peter Horwood
Heiko Ehrenberg

"Excused Absence":
Brad Van Treuren, submission via Proxy

2. Review and approve minutes

meeting minutes of 8/18/08 approved (Ian moved, Peter seconded)

3. 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

4. Discussion Topics

Results and Status from SJTAG Survey Activity

[Ian] Gunnar Carlsson submitted his survey answers just before last week's meeting (his feedback was not past of last weeks count)
no other changes

Status and review of white paper sections

Section 1: Ian made some reorganization; trying to flesh out more of what is being done now rather than a history of what has been done
Section 2: no changes / updates
Section 3: no additions / changes
Language Section: in preparation

System Data Elements

[Ian] provided an overview, also, review Brad's email for an introduction to UML

Yellow box is essentially encapsulating the board level objects and attributes.
sjtag.device:

DeviceDescription basically say there's a model; which type of model depends on the type of part so there are specializations of the generic DeviceDescription for BSDL, etc.
Non-scannable parts may have IBIS models, maybe VHDL or ABEL or simply a truth table.

I suggested to Brad that maybe the BOM needs to be in here, to allow for things like optional components, e.g. fitting equivalent AMD or Hyundai Flash devices. (the group agreed that that kind of information is needed)
Brad commented that "For sjtag.system, things get a bit more fuzzy" - I agree, I'm struggling a bit with exactly what's being represented here. I believe that the specialization link and relationship arrow are intended to show the hierarchical aspects. The way it's drawn makes this harder to see (it seems to be drawn better in sjtag.board). In any case, I'm not sure this is the right way to go about it. For example, I'm inclined to think of a mezzanine card, a board or module and a system all as "assemblies", each having similar attributes (Netlist, BoM).
one or more SystemConfigurationDescription related to one or more BoardDescriptions

[Heiko] system assembly should be part of the overal system description
[Ian] correct, if you look at system assembly it relates to many system descriptions,
[Ian] Do we need the sjtag system box ?
[Heiko] if yellow box is the board description only, we'd need to describe somewhere how things are connected between the different boards (netlist for system level)
[Ian] you can go from one card to another card, if you have a top level description you are in effect describing a flat netlist
[Peter] I agree that the sjtag system box is redundant as other wise you end up with reliance on text file being updated. sjtag system must be dynamically probable; We don't really want to have the System Configuration fixed; one of the aims of SJTAG was to be able to probe to determine the configuration, if that makes sense. Does anyone agree?
[Ian/Patrick] yes
[Patrick] where would the TAP voltage for the board be defined ? Some boards use different TAP voltages. How do we recognize what is needed in each case?
[Ian] We discussed this for ATCA, and concluded that we may have define the backplane TAP voltage.
[Patrick] But can we do that? - 1149.1 allows a range of TAP voltages.
[Carl W.] That's where we may have draw the distinction between "SJTAG Compatible" and "SJTAG Compliant".
[Carl W.] It's part of the problem we had describing the Architectures - we didn't want to get into that level of detail. For a Programmable Star you probably don't have a problem.
[Peter] you only run into tap voltage issues when using COTS cards, otherwise TAP voltage would have been defined when system was designed
[Ian] what happens when you do system upgrade 10 years later?
[Peter] then your new cards are designed as backward compatible
[Heiko] There's a GatewayDescription on the diagram - maybe the TAP voltage could be part of that?
[Ian] That seems like quite a good place to put it.
[Heiko] In sjtag.device we have the box "OtherDescription" - that seems a bit open ended, so this is supposed to cover all other kinds of descriptions we may think are needed?
[Ian] I think it's meant to be for now. The boxes to the left seem to be relatively easy to suggest what the description might be (BSDL for 1149.x Description for example), but the other boxes to the right are mainly non-scannable parts that need some other form of model. I guess OtherDescription just signifies "other model types we haven't revealed yet".
[Ian] I don't know how deeply we want to get into this today, but there is probably an awful lot of attributes that could be assigned to a board: Operational Constraints to maintain failover conditions, for example.
[Heiko] Also Resets that might cause a board to shut down.
[Ian] Brad also noted that he was wondering if SystemConfigurationDescription maybe amounted to a System-level BoM - I think it is. To me, sjtag.system seems to be unnecessary, as the hierarchical options are already captured in sjtag.board, which should maybe be renamed sjtag.assembly.
[Brad (P)] The reason I noted the SystemConfigurationDescription is due to the fact that the sjtag.board perspective is purely static in nature regarding the assembly. The devices listed for the board are defined in a CAD netlist file directly and hard wired to a specific configuration defined by that netlist. A system, on the other hand (including a carrier board), contains a dynamic netlist which is quite different from that of a traditional board. This netlist is generally not provided by a CAD netlist since the mating configurations are not defined inside the CAD system, but defined in some other artifact document. Once the mating configurations are known, the CAD netlist connections may be assembled to form the current configuration. The interconnections between boards varies depending on what is connected. The adjoining/mating board may contain a different netlist from what what previously installed. There is also the case that a new design which is unknown to the original system is added. We need to know how to meld in the new description for the system without affecting the operation of the tooling. Thus, I think there are some differences between what a system perspective needs from that of a board perspective. The sjtag.assembly might be a common/base type, but there are specialized needs different from a system and board in operation.
[Heiko] any other comments on this slide today?
... pause ...
if not, let's keep the topic open for comments from Brad and further discussion during next meeting. It may be good to add a new discussion topic to the SJTAG forum for this UML slide
[Ian] I'll take that as an action item

5. Schedule next meetings:

Monday, September 8th, 2008, 8:15am EDT
Monday, September 15th, 2008, 8:15am EDT
Wednesday, September 24th, 2008, 8:15am EDT

6. Any other business

SJTAG Newsletter: Heiko moved, Peter seconed, group agreed to sending out the August edition Ian proposed (once RSS feeds are added);

Ian will send it out this week

"New Electronics" article (9/23rd issue; feature on Systems Test),

circulation is about 18,500, hard and soft copy (very few people actually pay for it)
initial questions emailed to us are quite good as they probe what sjtag is trying to achieve; there is a concern that all replies should indicate a common goal (we need to be "on the same page")
[Heiko] will they send a draft before publishing
[Ian] not sure; deadline will be tight (final copy due by Sept 10)
[Patrick] who is she inteviewing
[Ian] one end user and a tool vendor;
* Ian volunteers to be interviewed representing an end user
* Heiko volunteers to be interviewed representing a tool vendor
[Ian] anyone with a good answer to questions (forwarded yesterday) please email Heiko and/or Ian; any contribution is gratefully recieved
[Ian] Some of these questions may be worth putting on the FAQ list on the SJTAG website?

7. Review of new action items

Ian to start a System Data Elements thread on the SJTAG forum;

done: SJTAG Forum Index � SJTAG General Discussions � System Data Elements (http://forums.sjtag.org/viewtopic.php?p=153#153)

8. Adjourned at 9:15am EDT

moved by Heiko, second by Patrick

Thanks to Peter and Ian for assistance with the notes.
Heiko.