The System JTAG Working Group

Minutes of Weekly Meeting, 2008-11-17

Meeting called to order at 8:20am EST

1. Roll Call

Carl Walker
Brad Van Treuren
Carl Neilsen
Ian McIntosh
Peter Horwood
Adam Ley
Eric Cormack
Tim Pender (joined 8:34)

Excused:
Heiko Ehrenberg

2. Review and Approve Previous Minutes

10/30 Minutes: One correction noted last week: Affiliation of Paul Holowko should read "BAE Systems" (instead of "BEA Systems").
Since only Heiko and Carl of the six attendees are eligible to approve these minutes, it was agreed to publish without formal approval. This follows the precedent from last year's Fringe Meeting.
11/10 Minutes: Approved (moved by Eric, seconded by Brad).

3. Review old action items

Adam proposed we cover the following at the next meeting:

Establish consensus on goals and constraints
What are we trying to achieve?
What restrictions are we faced with?

Establish whether TRST needs to be addressed as requirements in the ATCA specification if it is not going to be managed globally (All)
Adam review ATCA standard document for FRU's states
Ian to contact Rohit regarding IEEE policy for interviews.
Ian queried policy for sanctioning interviews, vetting content, stating disclaimers, etc., once were are formally constituted under the IEEE/TTSC. The response was that we were free to conduct whatever interviews we wish: TTSC will not interfere.
Patrick contact Cadence for EDA support person.
Expect report if Patrick attends 26/11 meeting.
Ian - Distribute Data Elements diagram (UML and simplified versions) [Done].
All - Consider what data items are missing from Data Elements diagrams for Test Program Generation [See discussion topic 4c].
Eric - Make initial contact with Synopsys on possible EDA participation [Done - See discussion topic 4b].

4. Discussion Topics

Newsletter

[Ian] Has anyone not seen the draft Newsletter I mailed out?
[Adam] I don't believe I saw that.
[Ian] Possibly - I didn't use the reflector as I didn't want too big a circulation of the draft, so I guess I maybe missed you.
[Brad] Adam doesn't appear to be on the email.
[Ian] For those who did see it, are there any corrections or additions?
[pause]
Do I have a motion approve this?
Moved by Brad, seconded by Eric, no objections or abstentions.
[Ian] OK, I'll update the RSS News links and send this out through the course of this week.

EDA participation

[Eric] I visited Synopsys over two days this week. They sounded keen on becoming involved. They have someone, or maybe a small group, who have a role in supporting external groups and meetings like this.
[Eric] Do we have a sort of standard pack of information I can pass on?
[Ian] Not really - We haven't really had to do that sort of thing much, but I'm sure I can pull a couple of things together that we can offer. I'll do that outside this meeting. In the meantime, you can always point them at the website.
[Eric] Thanks. I suppose the contact will be in the States, so I expect I'll pass anything to my European contact and he'll pass it on to his contact. I don't know if there's anyone else in Synopsys we could contact.
[Ian] There's always Rohit!
[Brad] Adam - Do you know what Adam Cron's role is now that he's with Synopsys?
[Adam] I think he's more on the Applications Support side - I don't know that SJTAG would really be his bag where he is.
[Brad] Ian - Was the author of that EDA article I sent known to your contact at Mentor?
[Ian] Oddly, no. Since both Lyle Pittroff and Mark Laing both seemed to have worked for organisations taken over by Mentor fairly recently, I thought they may be working in the same unit. I've also asked Adrian Harper about Lyle, but haven't heard back yet.

Data Element validation vs Structural Test Use Case (continuation)

I sent out various diagrams, to try to give as complete a starting point as I could. Let's say we look at the lowest level, the device descriptions. For the scannable parts, we have BSDL and the other standards to describe their behaviour for test, but what about the non-boundary scan parts? How do we describe them? VHDL, ABEL, IBIS, truth tables are all options.
Tim joined, 8:34
[Tim] Have we mentioned the STIL language because you want to be able to know how to control these devices.
[Eric] Hasn't that been used for quite a long time. I remember it used with Teradyne in the 1990s.
[Adam] More along the lines of being adopted in 2000. This has been focussing on the device level testing primarilly. As far as the current vendors go, we all seem to have our own formats that we use to describe non-boundary-scan information.
[Eric] I'm worried that STIL may be well adopted by many device vendors.
[Ian] We should still consider all the possibilities.
[Tim] It would be better to follow an existing standard.
[Eric] We were looking at STAPL as well.
[Ian] STAPL provides us a vector package management, but we still need a format for doing the ATPG. We still need to identify what data we need to describe the system to be able to carry out the test generation process.
[Eric] STIL seems to be a much more generic solution than what Synopsys, Mentor and the others use internally.
[Eric] In the past, STIL was like EDIF where in the past each company implemented only nibbles of the language and never all of it. Is that right Adam?
[Adam] That may be true. Where STIL is used most effectively is the transfer of vectors from the simulation environment to the tester environment.
[Eric] I found that to be the case as well. I have found that people have run into certain parts of STIL were not implemented by certain tools. We need to make sure it is properly defined if being used. It is a good transfer medium.
[Tim] Are there different levels of conformity?
[Eric] There may be. I've not used it for a while.
[Tim] Ian, you talked about IBIS translations: That may give you a template for the I/O, but idea of the device function.
[Peter] What about TSSI?
[Eric] Is this also WGL?
[Tim] Didn't they get bought out by Fluence?
[Adam] Look at tessi.com to show it has been reconstituted.
[Tim] Also VCD?
[Tim] I want to be able to control tri-states and things - I don't think I need a complicated model of the device.
[Peter] You need to know some functional behaviour.
[Ian] Yes, that's needed for the cluster test generation. And we need to know how to manage the board edges.
[Brad] I agree.
[Brad] For the record, IEEE 1450.0 is STIL, and 1450.6 is CTL used in 1500
1445-1998 is old Teradyne standard for Digital Test Interchange format for DoD.
[Tim] Mentioning DoD reminds me that some circuits have redundancy. We need to understand and describe which devices are powered on and how we deal with interlocks, etc.
[Ian] That's exactly the situations we have to deal with. The dynamic aspects need to be managed.
[Ian] Some of our previous discussion on HSDL looked at the capabilities for the dynamic elements, but I don't know if it does everything we might need.
[Adam] HSDL has a construct called "constraint" which can be used to prevent contentions the way you describe.
[Brad] Modularity - different boards could be plugged into the same module space. HSDL has elements that can deal with this.
[Peter] A problem I have with using VCD, TSSI or other device vector versions, is that we are putting constraints on the tool vendors that may be difficult and impinging on the vector generation. We really need to have the names that give us the cross reference to the tools models rather that forcing an import.
[Ian] Generally, we already have some way of modeling these devices in the tooling. I agree that if the tool vendor already has a model for the device, you really don't need to add in another model. But there are always shortfalls.
[Tim] Is there a standard library model for STIL? If there was a global repository that would be useful. It seems like tool vendors each have their own.
[Ian] Not that I'm aware of. As you said, each vendor seems to keep a repository of their own tools.
[Brad] For our internal tools we relied heavily on VHDL and Verilog models, but that got difficult as we started to use more behavioral modelling. It seems better to get device data directly from the device vendor.
[eric] Will device vendors provide the support if we specify a standard data format?
[Ian] Not at first. They need to be driven by customer demand. I'd expect it to go a bit like 1149.1 did: At first tool vendors each created their own device models. After 1149.1 showed some uptake then device vendors were prepared to buy into BSDL as a standard description format.
[Brad] Where are we in the food chain. Are we trying to standardise at the device description level or higher up?
[Ian] I think we standardise higher up. At the device level I think we really only need to know that data we need is there in some format that the tooling can handle.
[Ian] OK, what some of the other elments on the diagram: The BoM and Netlist?
[Brad] Second-source parts can cause havoc. Parts that are functionally the same but respond differently in test.
[Ian] Yes, even simple things like manufacturer ID codes have tripped us up in the past.
[Brad] It's beneficial to be able to identify these things in the BoM
[Ian] Are we suggesting the BoM is linked at the last minute?
[Brad] Some of the BoM is needed up front, but some must be defined later.
[Brad] Another thing is connectors and signal name correspondence. Sometimes the signal names correspond 1:1 through a connector, other times only part of a connector uses signal groups with matching names, other times ther's no correspondence at all. Generally this is data that's not in the CAD.
[Tim] I do a system-level interconnect, manually creating the HSDL to deal with this.
[Brad] Tooling has got better so some automation is possible.
[Ian] Surely connector pin IDs should be matchable, even if signal names can't?
[Brad] That's easier if you have a standard interface defined, but it's harder without that, especially once you start to bring in things like fibre I/Fs.
[Brad] Even jumper blocks can significantly change how a boards netlist looks.
[Ian] We usually only show jumper blocks settings on assembly drawings.
[Brad] But even then, the intent of the jumbper block may only be described in some higher level document outside of the CAD.
[Tim] And there may be several different stages of assembly.
[Tim] I'm having some difficulty understanding the differences between "system", "board", etc. What someone sees as a system might be a module to someone else.
[Ian] Which is why I wasn't comfortable with the original UML diagram, and why we came up with the version that just has "assemblies" with optional attributes depending on whether we're treating it as a module or a system.
[Brad] What you're getting into is specialisations of the general case.
[Tim] Something that doesn't come out of the modelling: It is sometimes necessary to pre-condition some signals - perhaps to synchronise with some other circuitry.
[Brad] That also gets into post-test recovery - Do you reset, warm boot, cold boot, etc.?

5. Schedule next meeting

Wednesday, November 26th, 2008, 8:15am EST
Monday, December 8th, 2008, 8:15am EST
Monday, December 15th, 2008, 8:15am EST

[Ian] As you know I won't be at the meeting on 26th. I've emailed Heiko to check that he can chair it, but I haven't had a reply yet.
[Brad] I think he was just out last week and this week.
[Ian] That was my understanding.
[Tim] Will there be a turnout that week - Thanksgiving?
[Ian] I hadn't considered that. Could people let myself and Heiko know if they don't intend to make the call next week, as soon as possible please? If there's only going to be two or three people on the call it'd be better to cancel.

6. Any other business

[Ian] Brad, from your ITC notes, there was discussion on TTSC flowing down a template for group operating procedures
[Brad] Yes, but there was no timeline for that happening. I don't think the P1687 people have passed their template on yet
[Ian] Was the template to be based on the P1687 procedures?
[Bard] Not necessarily - I think it was just being offerred as an example.
[Ian] I had been working on something. Do you think it's worth me sending it to Rohit to see if I'm going in the right direction?
[Brad] I expect the TTSC will accept whatever the group proposes - it is the groups's procedure.
[Tim] Brad - Are you able to share your ITC Paper on DDR2 testing?
[Brad] I'm not sure. Technically it's copyright of ITC - I'll need to check on that.

7. Review new action items

None.

[Tim] Was there an action to notify who was able to attend on 26th?
[Ian] Not really. I just want to know who can't make the next meeting so we can decide whether to cancel.
[Eric] When would you hope to know if the meeting is happening?
[Ian] I'd like to be able establish that on Thursday so I can notification out to everyone during Friday.

8. Adjourn

Meeting adjourned at 9:32am EST (Moved by Eric, Second by Brad)

Thanks to Brad for additional notes.

Respectfully submitted,
Ian