Minutes of Weekly Meeting, 2015-10-26

Meeting called to order: 11:07 AM EDT

1. Roll Call

Carl Walker
Heiko Ehrenberg
Brad Van Treuren
Brian Erickson
Eric Cormack
Peter Horwood
Tim Pender

By Proxy:

Adam Ley
Michele Portolan
Ian McIntosh

2. Review and approve previous minutes:

  • 10/19/2015 minutes (updated draft circulated 10/22/2015)No further corrections noted.
    • Eric moves to approve, Brad seconds; no objections -> minutes approved.

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
  • Persistent AOB items:
    • The Newsletter was due at the end of July. Brad probably has one topic left on his list.
    • Try to get Al Crouch on call re 1687.1.

5. Discussion Topics

a. Preclusion: What gets precluded, why should it be precluded?.

  • Brad: Michele’s main point is that instrument constraints affect the environment around them, and that this must be considered when managing the instruments (and the constraints on a given element as they are propagated through the hierarchy);
  • We need to identify elements in the hierarchy that need to be managed; the most obvious one would be the test data register, since that is the actual interface to the instrument and it might be required that that register must not be changed during an instrument operation;
  • Heiko: So, some registers may be allowed to be accessed while others must not be accessed to avoid interfering with the associated instrument;
  • Brad: Then the next thing we need to look at is how this fits into the hierarchy; a scan chain access may be prohibited if access to a particular register within a chain would corrupt its associated instrument activity;
  • Peter: Or you need to do an IRScan instead of a DRScan;
  • Brad: correct
  • Brad and Peter discussed that even controlling some scan chain selection devices may require DRScans that potentially interfere with aforementioned instrument operation;
  • Brad: That begs the question of whether and how we need to communicate the requirement not to access a particular TDR during instrument operation;
  • Heiko: Yes, we need some way of describing such requirements in our system model / infrastructure description;
  • In response to Brad’s question on whether or not there are other preclusions we need to note, Heiko was wondering if we need to make any specifications regarding power circuits;
  • Brad noted that power needs to be on for a test to be executed on a particular instrument;
  • What about the state machine? We may need to limit a TAP controller to remain in a certain state (e.g. Run-Test / Idle) for certain tests;
  • Heiko was wondering if we need to define this for the TAP State Machine or for the TAP pins?
  • Brad notes that the TAP State Machine level seems to be the better feature to be used for such a preclusion; Heiko agreed;
  • Brad asked if we need to specify requirements for resets (precluding a reset while the instrument is to be operated; as reset may remove any configuration that had been done); we could take that further and define a set of required conditions for an instrument to operate properly (“enable conditions” if we want to call them that; avoiding a reset being one of those constraints);
  • Peter pointed out that some people require TCK to be held at static level at some point to lower power consumption;
  • Brad notes that the TCK for a sub-chain during the parking condition may be another resource that we need to specify certain requirements for;

6. Topic for next meeting

  • Preclusions: Are there any other elements in the hierarchy we need to consider for preclusions?
    • (perhaps Ian and/or Michele have additional elements in mind?)

7. Key Takeaway for today's meeting

  • Elements that appear to require preclusions:
    • TDR; reason: the TDR is the actual interface to the instrument and changes in the TDR may interfere with instrument operation once a test is started;
    • Power; reason: power must be supplied to the instrument for it to be able to run tests
    • TAP State Machine; reason: instrument may require a certain TAP state to be held while TCK is running
    • “Compliance Enables” (Reset and possibly other instrument control signals); reason: avoid loss of instrument configuration / control
    • TCK for secondary ports; reason: a particular subchain may need to be parked while an instrument on that sub-chain still needs a few clock cycles to run properly;

8. Glossary terms from this meeting

  • None.
  • 'Scheduler' (from Aug 31).
  • 'Locking Mechanism' (from Oct 19).
  • 'Preclusion' (which may then require 'Allowance') (from Oct 19).

9. Schedule next meeting

  • November 2 (Brian will be missing); 11am EDT (4pm UK time).
  • November schedule:
    • 2, 9, 16, 23, 30. Eric expects to be absent on 9th.

10. Any other business

11. Review new action items

  • None.

12. Adjourn

  • Eric moved to adjourn; Brian seconded;
    •  Meeting adjourned at 11:50 AM EDT.

Respectfully submitted,
Heiko Ehrenberg