Minutes of Weekly Meeting, 2011-05-23

Meeting called to order: 11:06 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Patrick Au
Adam Ley
Carl Walker
Peter Horwood
Harrison Miles (joined 11:14)
Brad Van Treuren (joined 11:26)
Tim Pender (joined 11:33)

Apologies:
Heiko Ehrenberg
Brian Erickson

2. Review and approve previous minutes:

05/15/2011 minutes:

  • Draft circulated on 05/17/2011.
  • Two corrections noted:
    • In comment from Harrison in 4a change 'fr4om' to 'from',
    • In comment from Ian in 4b change 'which why' to 'which is why'.
  • Motion to approve with the above amendments by Eric, seconded by Harrison, no objections or abstentions.

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?
  • 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/Brad: Condense gateway comments and queries into a concise set of questions. - Ongoing
  • All: Forward text file to Ian containing keywords from review of meeting minutes. - Ongoing.
  • Carl/Brad: Get annotated keyword worksheets to Ian by Wednesday Close of Business. - Ongoing
  • All: Consider how a keyword can be used to define the chain configuration for a given test step, and what that keyword might be.
  • Adam: Prepare response to Brad's enquiry on identifying different cores in a device within dot7. - COMPLETE
  • Ian: Prepare draft of Newsletter for review at next meeting. - COMPLETE

4. Discussion Topics

  1. May/Spring Newsletter
    • [Ian] I was struggling for material, so the 'From the chair' section is really just a comment of the two main topics.
    • [Ian] Heiko gave me a correction: In the item on ITC 2011, it should read '...SJTAG team aims...', not 'aim'.
    • [Eric] Yes, 'aims' would be correct.
    • [Patrick] When I look at the ITC website, I see two sets of dates: Which is correct?
    • [Ian] Ah, you'll be seeing the sates for ITC itself and for ITC Test Week. ITC is usually Tuesday to Thursday and is the exhibition and main presentations, while Test Week spans out to the weekends either side. Those extra days are usually tutorials and workshops on specific subjects.
    • [Patrick] OK, it's just that I'm making a request to attend and wanted to be sure. Can you send me that section from the newsletter?
    • [Ian] Yes, I will do. {ACTION}
    • [Ian] Are there other corrections, or any more suggestions on material to include?
    • [Eric] It looks good.
    • {Eric moved to approve for publication, seconded by Patrick, no objections or abstentions}
    • [Ian] OK, I'll make the edit that Heiko suggested and get this issued before the end of the month.
  2. The Multiple BSDL Problem
    • [Ian] Adam has circulated some material on dot7 during last week. I wonder if Adam could talk us through some of this, particularly how dot7 manages access to specific cores or instances.
    • [Adam] I can do that, although I don't have anything prepared. It may be best if I used the HSDL example from the standard.
    • {HSDL section from 1149.7 shared}
    • [Adam] For multiple instances of the same device type, 1149.7 provides a Node ID (nodeid). This is an 8-bit extension to the conventional device ID. The standard does not specify how you define the Node ID; that's a mechanism that must be provided by the supplier, if the device is permitted to have multiple instances. Setting the Node ID my use straps that are read at power on on IO pins that are used for something else after power up, or there could be a nonvolatile memory defined by the chip supplier.
    • {Harrison joined}
    • [Ian] So, each instance effectively has a unique ID set in the hardware, and with a unique ID it maybe becomes easier to map different BSDLs to each instance?
    • [Harrison] That's true, but you need to look at the bigger picture. A device can have multiple cores but they may not be of similar 'mass'. This solving part of the problem. There is overlap, but you still don't know /how/ it's going to be used in a particular case.
    • {Brad joined}
    • [Brad] It's more that I was drawing an analogy with dot7 in how it describes connectivity. I was trying to see if there was a solution there that could be adapted to our own problem space.
    • [Adam] If you're referring to the embedded TAPs behind the dot7 interface then the standard largely skirts that issue, although there is some idea of how it should be implemented. There are a couple of mechanisms described but nothing is mandated. Access to the TAPs is considered to be in the documentation for the emulation tools. It is documented via the BSDL and the HSDL where that is provided.
    • [Brad] It's a lot like 1500 and TAM where it was left to the user.
    • [Adam] I don't think that particularly instructive, but it's probably accurate in the strict sense.
    • [Adam] IDs for multiple instances of identical device types are expected in the general usage, but the multiple instances will share the same description.
    • [Brad] The instance is represented in the HSDL?
    • [Adam] Instances of a given device type are elaborated in HSDL.7. It defines the members by a reference designator and assigns a Node ID to each member that needs that.
    • [Brad] So, the commonality is in BSDL.7 while the specialization is in HSDL.7. I think that's a key point for this week.
    • {Tim joined}
    • [Brad] Harrison, I think that's a little different to the object orientation you were describing?
    • [Harrison] Well, I see it differently. While trying to stay within the confines of dot1, dot7 has a found a mechanism that uses space in the state machine to do what they need. But I'm thinking more about how you would organize the tools.
    • [Brad] I see a bit of a disconnect there.
    • [Harrison] It's maybe hiding messiness or perhaps complexity by means of an abstraction. BSDL is still a flat file. It needs a human to define what needs to be done with it.
    • [Harrison] Dot7 is trying to stay within dot1.
    • [Brad] I think what you're trying to say is that we're trying to hide that there's a dot7 there. Dot7 has carved out two interfaces: BSDL.7 and HSDL.7.
    • [Harrison] From a tester's point of view it's a 'don't care' - there won't be any pure dot7 boards around. There could be, but in practise it's very unlikely.
    • [Adam] I have about 10 minutes that I can talk on this before I have to go.
    • [Adam] Go to page 822 in the Acrobat file.
    • [Adam] This is a BSDL snippet that corresponds to the diagram above it. It has four devices each described using the same BSDL. There is a section called 'Members' which associates reference designators with device type and package style.
    • [Adam] The next section is the port mapping of the members.
    • [Adam] In 'Members_Nodeids' each nodeid corresponds to a given instance. Even devices that are distinguished by type could still have node IDs.
    • [Adam] We expect that the boundary scan declaration database will be searched for 'mychip2', then that content will be associated with the reference designators that use 'mychip2'.
    • [Adam] You could have used 'mychip1', 'mychip2', 'mychip3' and 'mychip4' to assign different content to each. Different instances of the same device having different descriptions was not anticipated by dot7.
    • [Brad] I have the concern here that I had with the original HSDL: The Members can have instances of U1, U2, U3, etc., replicated several times at the system level. SO you still have the problem of distinguishing which U1 you're talking about.
    • [Adam] Well, HSDL supports hierarchical descriptions, so if we scroll down in the document, you'll see and example where we instantiate two 'modules' that each represent the star from the previous example.
    • [Adam] Now in the Members_Nodeids section you can see that we have a dotted notation for the Node IDs.
    • [Brad] Can you clarify - Is the hierarchy within a package?
    • [Adam] There is no particular boundary implied.
    • [Adam] The toolset has to provide for mapping the hierarchy appropriately.
    • [Adam] I'm not proposing this as a solution, just providing the information on how dot7 addresses devices.
    • [Brad] I think this has been beneficial.
    • [Harrison] I'm still not sure what the problem is that you're trying to solve.
    • [Brad] It's the need for multiple BSDLs: That there is no clear way to support multiple BSDLs in a single device instance. I wanted to see how dot7 was dealing with what seemed to be a similar problem space.
    • [Ian] I suppose what I want to say here is that I can see ways you could 'manage' the multiple BSDL issue, but as Harrison says it's all human intervention. It would all be things that have to be set up at test generation time, on a case by case basis.
    • [Ian] What gives me a concern is that in possibly finding a solution to one set of cases, we miss the bigger picture. What we've been looking at is one particular aspect of the bigger issue of 'chain dynamics' in a system; other aspects being, say, where a board is omitted from a system or a different daughter card gets installed and the chain configuration changes.
    • {Adam left}
    • [Harrison] OK, I'm beginning to see where this is headed. Here's the challenge - You want to treat each board as a 'container' and let's call the system a 'vessel' and we can have several containers in the vessel. Which containers are in the system? Some devices will be dot1, some will be 1500, some will be dot7. You may be able to treat each container as a complete environment.
    • [Ian] I think we're about to open up some new discussions here, but I'm conscious of the time, so I think we should leave this until the next meeting.

5. Key Takeaway for today's meeting

  • [Brad] In dot7, BSDL.7 holds the common features of device instances while HSDL.7 has the specializations.

6. Schedule next meeting

Next Meeting:
June 6th (11:00 AM EDT, 4:00 PM BST)
No meeting on 30th due to Memorial Day holiday in US and Bank Holiday in UK.

Schedule for June 2011:
6th, 13th, 20th, 27th.

7. Any other business

Ian relayed information that the Standards Association Board have elected to remove the requirement that Standards are reaffirmed at 5 yearly intervals, and have instead introduced a requirement that they should be revised at not more than 10 year intervals. Some discussion followed commenting that in the electronics field 10 years may prove too long, although it was accepted that revisions need not wait 10 years. It was questioned what the implications would be for intrinsically 'stable' standards such as Ethernet.

8. Review new action items

  • Ian: Send Patrick newsletter extract on ITC 2011.

9. Adjourn

Brad moved to adjourn at 12:09 PM EDT, seconded by Tim.

Respectfully submitted,
Ian McIntosh