Minutes of Weekly Meeting, 2015-11-16
Meeting called to order: 11:06 AM EST
1. Roll Call
Brad Van Treuren
2. Review and approve previous minutes:
- 11/02/2015 minutes (updated draft circulated 11/04/2015).
- No further corrections noted.
- Eric moved to approve seconded by Brad, no objections or abstentions.
- 11/09/2015 note of abandonment.
- Ian felt these did not warrant formal approval, but there was no group policy on this.
- Brad moved that they are published as record of the decision to abandon the meeting, seconded by Eric.
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
- 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
- May not be needed following the ITC presentation.
- Unclear if 1687.1 meetings are being held - believed not to have started.
5. Discussion Topics
a. Preclusions: Are there any other elements in the hierarchy we need to consider for preclusions?.
- Ian: I see from the previous discussion that the TDR was what was considered for preclusion. I'm not sure I see what else could be involved.
- Brad: Not just the TDR. Michele gave the example where the whole scan chain should be precluded.
- Ian: OK. I'm wondering where that information on what needs to be precluded is going to come from. Can it be derived from the design data? Does it need intellectual input from the test designer?
- Brad: Derived from behavioural information rather than design data. So it has to notify the tooling that it is a "special case". That can't be done in PDL or ICL as it stands.
- Ian: So we're implying some new data source.
- Brad: We're looking at preclusion, not allowance as in 1687, so this is all new territory. What 1687 have is insufficient, and means the integrator needs knowledge of the design to be able to put in the allowances.
- Ian: What is the view on PDL/ICL? Could they be extended to include preclusions?
- Brad: In my opinion, no, as the approach is from that of allowances. It's looking at a different aspect with the retargetter compared to something controlled at run-time.
- Brian: Maybe we should go back to Al (Crouch).
- Brad: I'm not sure he was particularly keen on what 1687 came up with. I think he also understood the problems with concurrency, etc., even if others didn't. Many in the group were only interested in device level test on ATE that only allow serialization.
- Michele: What I see with 1687 is that people are only using it for ATPG. There's not really any talk about functional test or concurrency, even in the tooling.
- Brad: I agree, I don't see it in the design tools.
- Michele: They're using PDL to deliver vectors.
- Michele: I was talking to a company about concurrency. Their response was how do they put it onto the ATE? It won't support it, so it's not used.
- Ian: I think, even at board level, if you're considering manufacturing test, primarily conventional interconnect testing, then things like concurrency don't appear on your horizon. It's only when you want to do "system" tests that it becomes relevant.
- Brad: I think this is a warning - We need to clarify, in our "statement of work", specifically what domain we're targeting. It's not ATE, it's system and functional test.
- Brad: Peter had suggested that another are for preclusion was the state of the scan chain. You can park certain chains but need to be able to state your requirements for parking.
- Brad: The SIB creates a problem because you have to scan through the sub-chain. So the different mechanisms have very different behaviours.
- Brad: An example is that you may want to stay in Run Test Idle for the duration of a BIST - you have a particular reason for shutting down a chain. This maybe translates to state machine control of that scan chain, which amounts to the same thing.
- Michele: This sort of operation is usually at the linker level. In 1687 we shouldn't be needing that sort of operation.
- Brad: Requiring a number of TCKs in RTI for BIST is an example of needing something from the TAP (bus) Controller.
- Ian: Maybe then it's implementation dependant - whether there's a linker present or not. Even if there is, it could be down to the tooling to decide whether it's best to do it at the TAP (bus) Controller or at the linker.
- Brad: I never understood why 1149.1 originally had RUNBIST attributes that were later removed - you still need to describe it within a particular device. Possibly because there are multiple BIST operations possible within a device, while originally there would be a single BIST operation.
- Brad: At the previous meeting, we were needing more understanding of what Ian and Michele were envisioning for preclusions.
- Ian: For me, I follow what's been suggested so far and really have nothing more to suggest.
- Brad: A question I have is how do you identify a resource from the leaf level? - "I want to reserve my TDR/chain/state machine". Other languages often have an implicit 'self' or 'this' object that can get passed so you know what 'this' is.
- Brad: Allowances can be done at a higher level so that can be resolved there.
- Ian: Tooling can resolve it, but probably only at test generation, not at run-time.
- Brad: Right.
- Peter, by proxy: A comment on topics raised, is that in an ideal world .ie. all 1687 cores generated by tools from vendors such as Mentor which would happen within a device, the designers will have used these tools to generate the 1687 cores. However this will not be the case as within a system where you will get devices with home designed 1687 cores, we see this already with standard 1149.1 TAPs, where there are issues with some vendor devices. So we need to take care of this and as such using a SIB on the system is restrictive as Brad pointed out.
6. Topic for next meeting
- What are the alternatives to PDL and ICL that could carry preclusion descriptions?
- How does an instrument know its own instance?
7. Key Takeaway for today's meeting
- An instrument needs to know its instance representation.
8. Glossary terms from this meeting
- 'Instance' (or a more specific version of the term) may require definition in future.
9. Schedule next meeting
- November 23 (week of Thanksgiving in the US); Brad will be absent.
- November schedule:
- 23, 30.
- Anyone unable to attend on 23rd should advise Ian as soon as possible.
10. Any other business
11. Review new action items
- None (Ian may try to distil concise glossary definitions from the previous discussions).
- Eric moved to adjourn seconded by Brian. Meeting adjourned at 11:57 AM EST.