Minutes of Weekly Meeting, 2015-04-27
Meeting called to order: 11:05 AM EDT
1. Roll Call
Brad Van Treuren
2. Review and approve previous minutes:
Approval of April 20 minutes (updated draft sent April 21):
- Peter advised changing "had" to "have" in "Peter agreed that we needed to declare that we had an interface to a board but ..." (just over half way through 5a). No further corrections noted;
- Eric moves, Brad seconds, no objections/abstentions -> 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.
- 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. Revisit draft PAR statements - continuation, Identify feature list for a "dot 1".
- Heiko started with a quick question: we are talking just about hardware right now or also description/documentation?
- Brad suggested that all three parts would be needed in the core: h/w, s/w, and description;
first off, the topology of the access link for devices at the board needs to be defined (just a flat hierarchy, no linkers, etc.).
- Brad asked if we should also include a discussion / details about terminations and other signal quality / signal level related topics (e.g. fanout).
- Heiko thinks yes, at least to the extend that we can ensure boards can work together in a system; e.g. one board may have a pull down on /TRST and would then "take down" the scan chain functionality for the whole system;
- Peter agrees;
- Brad notes that specific voltage requirements should probably not be part of the actual standard document; rather the standard should focus on the interoperability at a structural level;
device interfaces would need to be tolerant of the voltage levels (chip vendors need to make sure things can physically work together at the board and system level);
- Brad picked up on the discussion of pull-resistors on TAP signals, e.g. on the /TRST signal; especially when devices with and without /TRST pin are combined in a chain, how do we propose those to be handled? those types of things we probably need to describe/define in our core standard;
- Heiko suggested that one requirement in SJTAG could be that in the case of scan chains that include devices with and devices without/TRST pin, such scan chain would need to be initialized (reset) with both a hard-reset (apply /TRST) and a soft-reset (apply at least five TCK cycles while holding TMS high);
- Brad then asked what we'd do about the need for a net list for the whole board? (would need to be in some standardized netlist format);
- ODB++ is popular but is a post-layout format. Brad commented that BScan is supposed to have the benefit of being able to provide test coverage results pre-layout to aid in eliminating test points. Waiting for an ODB++ as the de facto standard defeats that benefit. Short cycles means you need to optimize everywhere you can.
- EDIF was considered not to be an option, as EDIF is not EDIF in all cases. Heiko agreed that he did not feel EDIF was a format to standardize on.
- Heiko thought that a complete netlist (a UUT description beyond the scan chain description) is not needed for all SJTAG applications and therefore should probably not be part of the core standard (as part of a dot extension the net list description would be very useful, though).
- Considering the scan chain description, Brad asked if we would need to define the maximum TCK supported by a scan chain (max TCK of the slowest device in the scan chain)?
- Heiko noted that BSDL defines TCK and tools can figure out what the max TCK is for a particular chain; so, max. TCK description is probably not a required feature, but it might be useful for someone to communicate that they don't want you under any circumstances to run a specific scan chain with a faster TCK than specified by them (through a means defined as an option in the SJTAG standard);
- Taking that discussion further, Brad asked if we'd need to provide a means to specify the maximum number of cells to switch per device or on the board?
- Heiko thought that this could be extended to the definition for power requirements, power consumption, etc., and would be good to have but maybe not necessarily as part of a core standard;
6. Topic for next meeting
- Brad: after reviewing today's notes, perhaps we should start to partition rules for access link and for data link, and see if there are any that we cannot put into one of these categories?.
7. Key Takeaway for today's meeting
- Identifying a feature list is hard .
8. Glossary terms from this meeting
9. Schedule next meeting
- May 4 (Eric and Peter will be missing).
- May schedule - 4, 11, 18, 25 (probably cancel this date; Memorial Day in the US and holiday in the UK too?)
10. Any other business
- New Electronics article:
- Ian: I've heard no more from Graham Pitcher, but I'll suggest Wednesday PM for a conference call, time to suit Heiko. If he'd rather do one-to-ones then I'll pass that on.
- Heiko: Wednesday afternoon your time (Ian) should work for me.
- Brad suggests to promote SJTAG.org, offer readers to follow what's going on with SJTAG, join the group, join discussions, etc.
11. Review new action items
Brad moves to adjourn, Eric seconds;
Meeting adjourned at 11:58am EDT;