Minutes of Weekly Meeting, 2014-10-13

Meeting called to order: 11:06 AM EDT

1. Roll Call

Ian McIntosh
Eric Cormack
Carl Walker (left 12:11)
Brian Erickson
Brad Van Treuren
Tim Pender
Peter Horwood
Heiko Ehrenberg (joined 11:08)
Michele Portolan (joined 11:12, left 12:11)

Adam Ley

2. Review and approve previous minutes:


  • Draft circulated 10/06/2014.
  • No corrections noted.
  • Eric moved to approve, seconded by Brian. 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. Test Managers - Primary and alternate cases

  • We had decided that we needed to present a documented, primary case for what a "Test Manager" is along with a alternate case in less detail but listing why it was less preferred, but we had not agreed on which was our primary case. The two options were: 1) the abstracted Test Manager specialized into the SJTAG Manager and the Chamber Manager and 2) the Test Manager as a distinct layer {Test Managers slide 6 shared}.  The impression was that we were leaning towards the abstracted Test Manager as our preference.  Heiko agreed, noting that it would be easy to change our description of the SJTAG Manager and Chamber Manager to suit.  Brad added that it was a key point of abstraction: That you only need to describe the additions and not re-write the base descriptions.
  • Ian wasn't sure how to represent the abstract Test Manager in the diagram and tried pushing "ghosted" Test Manager boxes behind both the SJTAG Manager and Chamber Manager {Slide 7 - v6a}.  Heiko suggested renaming the SJTAG Manager to "Test Manager, SJTAG" and Brad felt that adding the word "specialization" would help if it could be fitted in {Slide 8 - v6b}.  It was probably necessary to show the generic case - External Controller, Test Manager, UUT environment and UUT - before presenting the EST case with the specialized Test Managers.  It may need built up as 1) the generic representation, 2) the left hand side only (i.e. no Chamber Manager) then 3) the EST case.
  • Ian wondered if the group felt that the EST case was still relevant and useful - the general opinion was "yes" although it could perhaps confuse what the real abstraction is.  It shows the hardware dependency increasing (becomes more specific to the underlying hardware) as you delve down through the layers.
  • Considering the JTAG Control System, Brad commented that the Test Controller Interface would need to define whether it used I2C, PCI, etc., but there would be common features above that.  Peter inferred that Brad was considering a classical OO model with a base class that is refined for each specific instance.  Brad stated that while instances would have specific implementation specializations, there would be a set of common behaviors across all instances.
  • The JTAG Test Controller would need to support at least the 1149.1 transactions, but would we allow, e.g., scanning in states not allowed by 1149.1 (c.f. 1149.1-2013 now allows TDRs to vary in length whereas they were previously required to be fixed length).  Devices like ASPs are dependent on such out-of-band behavior, and Ian felt that not making the allowance could limit SJTAG.  Brad considered that may depend on what we choose to support.  1149.1-2013 provides for two, and only two, segment selection methods while P1687 defines only the SIB but allows, textually at least, for others.  Would this mean that Brocade's I2C path selection was non-compliant? [Hung-chi Lihn, Paper 10.3, ITC 2006, "Reusable, Low-cost, and Flexible Multidrop System JTAG Architecture"]  Brad felt we could accomodate these things if we can define access mechanisms separately from the data mechanisms and in a way, this was partly what IEEE Std 1500 was trying to do.
  • Ian thought there was a difference between SJTAG and both 1149.1-2013 and P1687 in that both of those were concerned mainly with what happens inside the device boundary and were "forward looking" so could make a call on what would be allowed in future device implementation, while SJTAG needed to deal with board level chains and existing chain management devices.
  • Brad noted a need for cooperation at the level of the JTAG Control System and its peers as well as at the higher layers.  This may be another point at which abstraction could be applied. Ian remarked that the bullet points already indicated that the JTAG Control System diagram was intended to be an example and that all Control Systems would be of a similar architecture.  There was probably commonality at least at the Test Step Interface.
  • Brad wondered if we were in a position to start defining the primitives of our Test Manager.  Ian was unsure if that first needed confirmation that we were on the right track by getting the answer to our question on the Test Manager model which we still had not completely formulated.  Ian was aware that we now needed to make sure that any public presentations included some preamble to set the context and explain what SJTAG was trying to achieve.
  • Brad's BTW presentation in 2002 used examples showing how TFCL could be used in a practical case and Gunnar's 2005 presentations similarly gave practical examples showing concurrency: Brad felt this was helpful in getting hardware people to grasp the concepts being presented. 
  • The External Controller is not aware of the lowest levels and only wants to know that it needs to execute a particular test suite at a given oint in time.  The architecture is heavily dependent on the idea of delegation.  This may become complex, but possibly only if you're trying to view the entire picture at once.  At each "level" there's probably a much simpler view of it's immediate surroundings.
  • Peter felt that a challenge was not locking in to a particular method of chain selection.  There are clearly pros and cons for each and users' needs will vary, such as a requirement to reuse tests at different levels.  This was why Brad wanted to try to separate the access protocol from the data protocol but could see difficulties as for some devices the path selection becomes entwined with the data stream.
  • Ian could see the potential that a path selection operation via e.g. I2C or SPI might not complete before the data path starts being used - In some cases any "acknowledge" might simply indicate that the request has been received, not that it has been completed.  In that case Brad felt that we needed to make it a rule that the interface provides a means to determine that the request has been fulfilled, but agreed to that there was nothing to say that one Control System wasn't delegating to another computer.
  • Tim enquired about the operation of scan bridges as these seemed to have the selection wrapped up with the 1149.1 data.  Peter explained that at first, the bridge will appear to be the only device in the chain.  1149.1 is used to address the device and load the DR of the bridge to select the local scan chains to be included. It is then unparked and the regular scan operations are routed to the selected chains with a padding/re-synchronizing bit inserted between each local chain.  Firecron's devices can be placed in a transparent mode using discrete control pins but not all bridge devices offer that capability.
  • The desire to be able to use the same test in an embedded case as during factory assembly test is part of the consideration in comparing ASP and Scan bridge technologies, and is also where the Brocade example comes in since once set up the access becomes transparent.  Board level test will often set scan bridge addresses to 0 and these are then set differently when the board is installed in the system.  Peter referred to a demonstration with Qinetiq where, using Firecron's own tooling, they were able to modify the selection address on the fly and so re-use pre-developed tests at the system level.  This was harder to do with other tool vendors' products as they do not have the address in easily predictable places.

b. SJTAG Standards Roadmap - continue organising topics.

  • {Not discussed due to lack of time}

6. Key Takeaway for today's meeting

  • Control Systems may be another candidate for abstraction.
  • Significant discussion on Access Link mechanisms and possible separation of Data Links and Access Links.

7. Glossary terms from this meeting

  • None.

8. Schedule next meeting

  • October 20
  • October schedule: 20, 27. Heiko likely to be absent 20 (ITC week), Tim absent 27.

9. Any other business

  • Brad has draft Green Paper for next newsletter about 90% done.  Should be able to review in time for a release at the month end.

10. Review new action items

  • Ian: Assemble new slide pack with the relevant slides only as discussed this week.

11. Adjourn

Eric moved to adjourn at 12:20 PM EDT, seconded by Tim.

Respectfully submitted,
Ian McIntosh