Minutes of Weekly Meeting, 2011-06-13

Meeting called to order: 11:06 AM EDT

1. Roll Call

Eric Cormack
Heiko Ehrenberg
Patrick Au
Ian McIntosh
Carl Walker
Brian Erickson
Brad Van Treuren (joined 11:11)

Excused:
Adam Ley

2. Review and approve previous minutes:

06/06/2011 minutes:

  • Draft circulated on 06/07/2011.
  • No corrections noted.
  • Insufficient attendees to vote on approval.

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.

4. Discussion Topics

  1. Continuation of Problem Space Description
    - Instrumenting devices
    - Role and relevance of other standards
    - Modeling the problems
    • [Ian] I wanted to examine a couple of items that came up as a result of last weeks discussions. The first was a remark from Harrison where he suggested that driving silicon vendors to instrument devices was key to SJTAG.
    • [Ian] That may be a solution or part of a solution, but it surely has to be looking well into the future; it doesn't offer much to designs coming through now. Does that seem like fair comment?
    • [Patrick] You'd have to think so.
    • [Brian] It seems like something for our dot1 or dot2.
    • [Heiko] I missed the last couple of weeks' discussions, so I'm not sure what is meant 'instrumenting devices' here.
    • [Ian] I think Harrison was using the way that FPGA vendors can provide IP that offers ways of assisting testing, such as Xilinx and their Chipscope, and largely bypass limitations of BSDL and 1149.1.
    • {Brad joined, 11:11}
    • [Heiko] Well, there has also been discussion in 1149.1 on using the User register. It's not exactly the same but it is similar.
    • [Brad] I think that was in reference to the Initialization Registers.
    • [Heiko] Yes, but once you have that, people will take it further.
    • [Brad] I tend to be more down the path of thinking of the Test Data Register rather than instruments. An instrument has structure as well as a behavioural description; the structure comes from the BSDL. If you look at the 1532 extensions, you can see it gets into a crossover into behavioural descriptions.
    • [Brad] That last part is maybe one of our Key Points for today.
    • [Brad] You could almost stretch dot6 into 'behavioural' - there's not a constant pattern there, it's changed to a pulsed stream at the output.
    • [Brad] We need to talk about behaviour as well as structure in 1149.1.
    • [Ian] Well, I think we're dealing with technologies today that no-one on the original 1149 group could have foreseen.
    • [Brad] Even the concept of testing ac coupled signals was foreign to that.
    • [Ian] OK, but do instrumented devices help us?
    • [Brad] Instruments are just one case, there are other things that need to be discussed. I can't agree that everything can be modelled as an instrument.
    • [Ian] I have a feeling that it makes things more complex. Let me rewind a bit on that: In certain cases it seems to makes things more complex than they really need to be.
    • [Brad] Yes, in the case of the interconnect test, the BSDL is defining the structure and static length of the data registers, then algorithms can be applied to work out how to use that structure. The algorithms are reusable, they're not specific to the board. You can consider them to be generic. These are more like generics or templates in software - or even macros that are the same for that use case.
    • [Brad] With the notion of an instrument, you need to define the algorithm used to control to that instrument; there's no standard way to control all instruments because each instrument has a different behavior, although there are standard interfaces being defined. It's the difference between a standard interface and standard usage. Thus, an instrument requires additional information for the tooling to describe how to use it. This is very different than the requirements for an interconnect test.
    • [Ian] I asked this before, and I don't think I really got an answer: Are we in danger of substituting our BSDL descriptions with instrument descriptions and not really solving the problems?
    • [Brad] You mean transforming from BSDL to instrument?
    • [Ian] Yes. I wondering if Harrison felt that an instrument model was in some way more naturally polymorphic, and so could solve more problem types.
    • [Brad] That could be true, but you'd still need a hierarchy that supports the dynamic changes. 1687 still uses a static model of the instruments; it's just dynamic in how they're configured at run time. It's not talking about plugging in new entities.
    • [Brian] 1687 allows me to turn paths on and off, but not change the model.
    • [Brad] Yes, that's a good description.
    • [Ian] I think that there's maybe more of an issue for people like Brad who are mainly working with embedded testing. Where you have an external controller, you maybe have more resources on hand and manual intervention to allow you to deal with the different configurations.
    • [Brad] But that becomes cloudy when you have to deal with concurrency. Then the external tester becomes more like the embedded tester - you have more constraints to handle. That's why my 2005 paper at ITC talked about being able to fetch vectors from the UUT. That lead to the idea of it being Plug and Play. Then Gunnar's paper had the different viewpoint of pushing the test into the UUT. We were careful to show both ends of the spectrum.
    • [Ian] OK, that maybe brings me round to the second point. Again it was prompted by Harrison, suggesting that SJTAG needed to lean more on P1687 than on dot7.
    • [Ian] I'm thinking that there are several related standards that people may be working with right now that they'd want to use in their system designs.
    • [Brad] I almost start to wonder about what has the most or least impact on the problem. P1687 brings in dynamic DR length - it changes over time, while with dot7 you end up with a bus topology. While you might have a board edge with a 4 or 5 wire TAP you quickly get to a point where it needs to become a two-wire dot7 TAP.
    • [Brad] Some designers are asking me 'Do I just need two wires now?' As Heiko pointed out, people are going to abuse features.
    • [Ian] Arguably, many of our SJTAG use cases come about from abuses of dot1. Maybe not 'abuses', but creative applications.
    • [Brad] Certainly innovative.
    • [Ian] Digressing a little but I was recently discussing the use of additional busses to command devices to route TAP signals to certain places within a system. That needs functionality and gets back to a form of the multiple BSDL problem.
    • [Brad] There are cases where you need some degree of function; parts that aren't going to work unless you have the clock running, and that maybe comes from a programmable part. My favorite case like that is where some processors won't come out of reset until you give them a number of clocks, so you've got to clock it to get the TAP functional.
    • [Ian] When I see things like that I wonder if the device vendors have lost sight of what JTAG was for.
    • [Brian] I don't know that they've lost sight, maybe just didn't understand it from the beginning.
    • [Ian] That maybe worries me even more.
    • [Brian] I think 1149.1 is just stuck in, as a lowest priority.
    • [Ian] I can relate to that, having seen board designs where the JTAG PCB tracking was added after all the functional requirements had been met, so it had poor signal characteristics and reduced TCK frequencies.
    • [Brian] It always the lowest priority.
    • [Ian] Digressing again, but we're trying to change that mindset, because ignoring testability costs you money.
    • [Brian] Convince management of the value and you'll start to get support.
    • [Brad] There's also a perspective of the industrial process: Quite often the chip designer will quite literally implement the data register as a chain of cells inserted between the core logic and the pins. Some people are complaining about not getting dot6 on SERDES channels, because the vendor omits the cells altogether. Ken Parker made the point in 1581 that it needs to be part of the core.
    • [Ian] Yes, the lack of dot6 on the RocketIO on Xilinx FPGAs is a big disappointment. We moving more and more towards serial buses and away from parallel buses, so the available JTAG functionality is reducing to the extent that it becomes near useless.
    • [Brad] You're not alone. I think we're going the same way.
    • [Ian] It seem to me to be laziness. They complain that the BSCAN cell disrupts the IO, but that seems more because they don't want to spend the time integrating it behind the core logic's IO.
    • [Brad] Vendors are coming back with emulation interfaces, for functional types of testing.
    • [Ian] And that is valuable.
    • [Brian] The question I have is where are we heading with regard to putting a PAR together.
    • [Brad] That's a good question. We need to set some boundaries.
    • [Ian] Well, we've been trying various methods to do that, and haven't really succeeded.
    • [Ian] I think we may each have slightly differing opinions about what needs to be in the core. I don't know how we distill that out and get to a consensus.
    • [Brad] Your third bullet point gets us to the modeling. In 1581 I liked what Heiko did where they ended up with a demonstration model; that seemed to really energize people. Maybe we need a theoretical system to use as a benchmark or baseline. Then we can start fleshing out our interfaces.
    • [Heiko] Haven't we tried that before?
    • [Brad] It wasn't the same - systems that you perceive - it was maybe trying to do too much.
    • [Ian] Maybe that third bullet from this week will become a slightly modified modeling topic for next week.

5. Key Takeaway for today's meeting

  • [Brad] IEEE Std. 1532 crosses over into behavioural aspects.
  • [Brad] 1149.6 starts to describe behaviour at the level of a port.
  • [Brad] We have been talking about 'structure' and 'behaviour' from the outset without realizing it.

6. Schedule next meeting

Next Meeting:
June 20th (11:00 AM EDT, 4:00 PM BST)

Schedule for June 2011:
20th, 27th.

7. Any other business

None.

8. Review new action items

None.

{Brian left, 12:02}

9. Adjourn

Eric moved to adjourn at 12:03 AM EDT, seconded by Carl.

Respectfully submitted,
Ian McIntosh