The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-08-04

Meeting was called to order at 8:20am EDT

1. Roll Call (Participants):

Brad Van Treuren
Carl Nielsen
Peter Horwood
Heiko Ehrenberg
Tim Pender

Excused absences:
Ian McIntosh
Carl Walker

2. Review and approve minutes

7/28/2008 minutes approved (Peter moved, Heiko second)

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)
Register on new SJTAG web site ( http://www.sjtag.org/) (All)
Look at proposed scope and purpose from ITC 2006 presentation and propose scope and purpose for ATCA activity group (All)
Adam review ATCA standard document for FRU's states

4. Discussion Topics

Results and Status from SJTAG Survey Activity

Brad believes there are 4 additional responses;
Plan to end survey at the end of August.
We need to start thinking of what additional information we need from the user community (for our more detailed follow-up survey)

Status and review of white paper sections

Section 1: Brad and Ian did a number of changes; all sections filled out, more graphics added (some graphics are just placeholders for now, not fine tuned yet)
Section 2: Heiko and Peter didn't get to work on it
Section 3: Carl N. reports no progress on the hardware section;
[Brad] Ian and I think this section seems to become a bit too detailed for a white paper; need to consider the depth of information needed in a white paper; Perhaps we need to start a wiki for the draft standard which contains much of what Carl and Carl have written.
[Carl N.] for now we just planned on putting as much as possible into it, then remove non-essential things (not include it in a white paper but keep it for possible future needs);
[Brad] anyone interested in working on the language section, please send me an email

Review proposed scope and purpose statements (sent under separate email)

Scope:

[Brad] main point here is to clarify that we specify the "methodology of access", not implementation details;
[Peter] "methodology" is the right word, I think, since we would be allowing "freedom of implementation";
[Brad] Tim, I believe it was you that noted we had dot 5 and we need to make sure SJTAG does not follow the same fate.
[Tim] When I began to implement system level JTAG I read what was available. I began to read 1149.5 and kept reading and reading. There was a lot of information that was overwhelming. We need to make sure SJTAG is easy to understand. I used to use the ASP, but feel vendors need to define and provide drivers/software to show how to use their SJTAG hardware.
[Tim] IEEE1149.5 was overwhelming, just for the implementation there was too much to read and absorb; SJTAG should try to be simpler to implement;
[Heiko] Should we add "configuration" and "programming" to the list of features we provide as a method of access for? Also, I think we should include 1149.4 and 1149.6 too "... describing the structure of IEEE 1149.1 connections ..." (1149.4 has two additional test bus signals, AT1 and AT2, for example);
[Brad] Perhaps we focus more on the IEEE 1149.1 TAP being the specified method of access described in SJTAG
[Brad] I think if we specify the API this will help people write these drivers and provide the level of uniformity and standardization we need. I think this is what you were getting at Peter.
[Peter] Yes.
[Heiko] I wonder if we should add configuration and/or programming for the list of features available. Right now we have test, debug, instrument, and emulation. P1687 people would claim they are all instruments. Further down in �The elements�� need to add 1149.4, 1149.6, and 1532. Possible reword to use 1149.1 defined TAP interface.
[Brad] Defining the 1149.1 TAP interface may eliminate the ASP interface protocols that are outside the 1149.1 protocol.
[Peter] We are not defining things outside the original 1149.1 state machine. We just redefine what particular state are allowed to do. We are defining the 4 or 5 wire interface and not defining the specific protocols.
[Heiko] I agree. We are defining the use of the 1149.1 signals and not the protocol. The ASP also uses these signals.
[Brad] We need to make sure we need to work with just the JTAG TAP wires.
[Brad] I want to make sure people don�t redefine the use of these 4 or 5 signals.
[Peter] I think we need to state the signals are 1149.1 compliant signals.
[Brad] data representations� Is this to broad of a scope or not broad enough?
[Heiko] Does it preclude configuration or programming data? (e.g., test vectors (including any information for programming data))
[Brad] Is a definition of only a structural definition needed or do we need a procedural or functional definition language that defines the algorithms to do things like selection. This is the problem I have with HSDL right now. Currently, the DYNAMIC PATH leaves the details for the connection algorithm to the user that is done a bazillion different ways in systems today.
[Brad] Is "...software application programming interfaces (APIs) defining command primitives facilitating communications between functional command, control, and data modules of a Test Manager application." sufficient or do we need to describe more details rather than just API functions?
[Tim] Suppose you have an OO language using chain1.reset() that is going to put your board in a particular state. I would like to control that on a board by board basis. It might be in a power management situation, non-compliance workaround, or something else. We need to be able to control every chain. There might be some synchronization issues.
[Brad] This is what I was getting to when asking if a structural description is enough or do we need a procedural description as well. So we could define a reset( ) required for each board, for example. Thus, the procedures would map to levels of the hierarchical structural descriptions.
[Tim] I am looking for control of individual chains on the board as well.

Purpose:

To be discussed next week ...

5. Schedule next meetings:

Monday, August 11th, 2008, 8:15am EDT
Wednesday, August 20th, 2008, 8:15am EDT [Carl W. has set up a different bridge number for this call]

6. Any other business

None.

7. Review new action items

anyone interested in working on the language section of white paper, please send an email to Brad
if you think of any additional comments on the Scope draft, please email them to Brad or the whole group
Brad will send out a revised Scope based on today's discussion

8. Adjourned at 9:22am EDT

moved by Heiko, second by Tim

Many thanks again to Heiko for assisting in preparing these minutes.

Respectfully submitted,
Brad