Minutes of Weekly Meeting, 2015-02-16

Meeting called to order: 11:07 AM EST

1. Roll Call

Ian McIntosh
Eric Cormack
Brian Erickson
Carl Walker
Tim Pender
Bill Eklow
Heiko Ehrenberg (joined 11:14)
Brad Van Treuren (joined 11:25)

Adam Ley
Michele Portolan
Peter Horwood

2. Review and approve previous minutes:


  • Updated draft circulated 02/11/2015.
  • No corrections noted.
  • Eric moved to approve as updated, seconded by Carl. No objections or abstentions.

3. Review old action items

  • 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: Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172

5. Discussion Topics

a. Additional comments on the proposal:

"that the SJTAG standard should describe the structure and access behaviour for chain management control in a general manner and not for specific devices"

  • {Discussion delayed until Heiko joined the call}
  • Heiko had previously advised by email his agreement with the proposal, but Ian wanted to make sure that everyone in the group had the opportunity to make comment or raise questions.  Heiko had no comment to make.
  • Adam has not made any comment.

b. Any material for ITC?

  • Bill advised that Michele's paper submission is now in the ITC database.  It will probably be late April before paper selection takes place.  Even if not selected as a full paper it may still be accepted as an invited talk.  There are not a lot of papers submitted as of this moment.
  • We feel it is unlikely that SJTAG could offer a full paper, but would expect to support a poster within the "Standards" collection.  Bill suggested that the poster could be made to loosely couple with Michele's paper, and perhaps the end of Michele's paper presentation could "promote" the existence of the Poster.
  • Bill also advised that there is consideration of a second Poster session this year: The additional session would act as a follow up to the Technical Papers, allowing people who didn't get a chance to put a question during the paper presentation to touch base with the author.
  • There were no further thoughts regarding a panel.

c. Revisit draft PAR statements - continuation.

  • Last week we seemed to be suggesting that our core or "Dot 0" standard should be the level immediately above the existing 1149.1 and including the chain management.
  • Ian felt that the term "management" might suggest this wouldn't be a purely hardware standard as there was an implication of software there.  However, was this meant to imply defining the management or was it describing the management facilities in the design such that the tooling could decide how to do the management?
  • Bill asked if this was again intended to be purely "JTAG"?  Ian thought it wasn't intended to be so and that certainly we wouldn't want to write a PAR that would make that a constraint.  There were clear cases where we may need to use another interface to set up boundary scan access.   Bill felt that might require a name change from "SJTAG" to avoid misperceptions.  P1687 had trouble during ballot over whether or not it was constrained to use 1149.1. 
  • Brad felt it was important to leave room to allow protocol translations, e.g. where and FPGA with and I2C master is used to provide a bridge from 1149.1 to I2C.  Some instruments may only have I2C or SPI interfaces.
  • Ian felt that even though we may be allowing other interfaces, 1149.1/JTAG was still a key technology: At system level (and board edge) pins for test are at a premium so trying to get all test access via a single bus is highly desirable. Since JTAG is still the predominant native access method for test and programming it makes sense to use that and create bridges to other interfaces.  Brad mentioned a similar discussion with Rod Tulloss regarding 1149.5.
  • This raised the topic of testing non-functional UUTs and Ian noted that there was a move in his company toward building completely unprogrammed systems and loading the firmware only once the intended customer was known, so there was a need to have a "bring alive" mechanism, and this was JTAG.
  • Brad stated his preference for considering "Data Substance" as separate from "Control Substance":  You need the latter to provide some level of control to contact the target entity and the former to pass data to it.
  • Referring back to 1149.5, it was planned that it would operate even without functionality in the target.  However most boards now have some form of board management controller (for power, etc.) that is expected to be working to get the board to do anything. 1149.5's JTAG interface  used a particular protocol that was very similar to the AT&T BSM, so there was effectively a bridge between 1149.5 and 1149.1
  • We were looking at "altered" 1149.1, i.e. to accommodate multidrop.  Then the question of multidrop 1149.7 arises in order to save more pins, at which point some designers will ask "Why not just use I2C?"  System designers will tend to prefer a 2-pin interface over a 4 or 5-pin interface.  Bill noted a leaning towards what 1149.10 is doing with SERDES with an 1149.1 bridge at either end.
  • Tim commented that I2C's problem was lack of speed - it was OK for control but not for data.  Bard added that Gunnar had similar experience with the IPMI bus being too slow e.g. for the transfer of tests from the host, but it was fine for commanding tests.  Ian felt that we were defining speed as a discriminator between what was suitable for data and what was usable for control.
  • Ian thought using an existing mission bus for test is perhaps the ultimate "pin-saver" but generally requires a moderate degree of functionality that cannot be guaranteed.  Brad mentioned the Scan Proxy, where the test can be transferred as IP packets - this is essentially a "soft interface" using, e.g., Ethernet.
  • In ATCA the Board Management interface must be operating to get the board to power up so it can leveraged as a test interface - it can be assumed to be working.  While Ian agreed that was true it created a "chicken and egg" situation in terms of bringing the board alive in the first place.  Brad expected that this would be programmed during manufacture, but that didn't fit Ian's model of building fully unprogrammed systems.  Tim suggested that backplanes my provide discrete lines or I2C busses that can mux the JTAG on command for programming such devices; Ian stated that this was essentially what he did. 

6. Key Takeaway for today's meeting

  • Interface speed is a discriminator of whether an interface is only suitable for control or may be used for data.

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • Next meeting February 23, Ian will be absent and Brian is tentative.
  • March schedule: 2, 9, 16, 23, 30.

9. Any other business

  • The newsletter is due. Brad is still finding limited time to work on the Green Paper.
  • Group officers needs to be addressed. Start the process on 3/2/15. Heiko does not have the bandwidth to take on the role of Chair but is prepared to continue as Vice-chair.

10. Review new action items

  • None.

11. Adjourn

Tim moved to adjourn at 11:59 AM EST, seconded by Eric.

Respectfully submitted,
Ian McIntosh