Minutes of Weekly Meeting, 2012-03-19

Meeting called to order: 11:11 AM EDT

1. Roll Call

Ian McIntosh
Harrison Miles
Carl Walker
Peter Horwood
Patrick Au
Adam Ley (joined 11:18)
Tim Pender (joined 11:22)
Brad Van Treuren (joined 11:47)

Excused:
Heiko Ehrenberg
Brian Erickson
Eric Cormack

2. Review and approve previous minutes:

03/05/2012 minutes:

  • Draft circulated on 03/05/2012.
  • No corrections noted at this time.
  • Insufficient attendees to vote on approval.

03/12/2012 minutes:

  • Draft circulated on 03/12/2012.
  • No corrections noted at this time.
  • 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 to consider an appeal to SJTAG email newsletter recipients for participation from the automotive industry in the next newsletter.

4. Discussion Topics

  1. Discussion: "SJTAG in a nutshell - What I think SJTAG is all about"
    Concluding with Brad's thoughts, views from other members.
    • [Ian] I wanted to conclude on Brad's previous notes, but he's likely to join us late.
    • [Ian] I'd like to have had opinions from the tool vendors among us, but both Adam and Heiko aren't with us.
    • [Harrison] But I'm a tool vendor! My take on SJTAG, if it's going to move forward is that it's going to have to take advantage of P1687 - the notion of coupling an instrument with the test and vectors. Along with a common interface.
    • {Adam joined}
    • [Harrison] 1149.7 created the notion of needing a command and data protocol channel. SJTAG isn't looking much different from P1838 on 3D devices. The challenge there is similar to SJTAG: No guarantee that each die is from the same vendor.
    • {Tim joined}
    • [Ian] I can see what you're suggesting with regard to the 3D devices, but I think there are differences: I think a lot of what the 3D device people are looking will be considering the device in isolation. When we look at a board you might see that as similar to a 3D device, but in a system you need to take care of what happens at the board edge. It's like the difference between INTEST and EXTEST.
    • [Harrison] That's why I say you have to separate post-power-on from pre- power-on states. Test works in the least functional state; anything that looks operational complicates things.
    • [Ian] But it can even be an issue at that simpler state as a test signal may look like a fault condition that shuts the system down completely.
    • [Harrison] JTAG needs to stop normal behaviour. Even if you don't load the operating system, the BIOS may still be running.
    • [Harrison] I'd say there are 3 or maybe 4 layers or levels of consciousness. At the lowest level you have JTAG and what I'd call 'bare metal testing'. In a perfect world, with instrumentation, you get a result that lets you have hardware confidence about the boards, nothing more.
    • [Harrison] You have to have a mechanism that allows operation at levels above that and Dot7 is the only thing that offers that. SJTAG is going to have to break down into layers.
    • [Ian] I'm seeing Dot1 as the common 'transport'.
    • [Harrison] Bring results out through the Dot1 port, Then take advantage of ICL for the connectivity between devices. The first notion of SJTAG is to take advantage of ICL. Next, maybe more difficult is to get to a common backplane port. Then you can think about to orchestrate across multiple boards, then how do I work across the system.
    • [Harrison] As we said, multiple boards could look topologically similar and with SOCs that can 'self-ignite' then you need to get a silicon ID and create a hash code with the serial number, so you can identify the board. Things that were optional can no longer be optional.
    • [Ian] I can see those things, but it's probably the idea of the common backplane port is the one that creates the biggest problem for us.
    • [Harrison] There was PICMG, they maybe got it right with compact PCI, ATCA, microTCA. ATCA has it's maintenance port.
    • [Ian] OK, I'm taking a simpler view of the common backplane port and think more in terms of a pure JTAG port, a single JTAG port from which I can gain access to all the boards.
    • [Harrison] Well it can't be five wires. The other question is 'Do I need significant additional silicon to do it?'
    • [Ian] Well that's relevant. The point of JTAG for us is that it shouldn't need much functional circuitry in order to be usable. If there's a presumption that some appreciable amount of logic needs to be working to run a test then I can end up with a dead box and no means to tell why it's dead.
    • [Harrison] Seems like a hub/spoke architecture gets you where you want, so Dot7 is topologically the right way to go.
    • {Brad joined}
    • [Brad] I'm trying to think of what Dot5 was trying to bring. Dot5 seemed to get loaded with all sorts of things, that industry maybe didn't really want and so it didn't take off.
    • [Brad] Ian's point about the functionality needed is good. For our Plug and Play we wanted a pure boundary scan solution. We didn't need the Board Management Controller in order to get the test data.
    • [Brad] Some parts of the circuit may be powered up and some not. BScan gives us the capability to test with very little functionality. But we also need to consider the power model too.
    • [Brad] One thing we maybe haven't discussed is what Harrison needs for the ID: A minimal level of functionality on the board to perform interrogation of the ID.
    • [Harrison] I think the interrogation can be simple, you can self-learn through the JTAG port - discover the chain.
    • [Ian] Assuming that everyone has adopted a common approach to setting the default chain.
    • [Harrison] The details are already in the specification. Some vendors chose not to implement those features.
       
    • [Ian] Harrison, are you going to pursue the survey material with iNEMI?
    • [Harrison] Yes, I'm putting some slides together, I need to then take those back to iNEMI for them to approve what I can share. Once I have that I can let you know and you can schedule some time in.

5. Key Takeaway for today's meeting

  • [Brad] JTAG is capable of providing test results with minimal functionality in the UUT.
  • [Harrison] There are minimal facilities required on a board to get an ID. The board ID should a mandatory requirement for SJTAG.

6. Schedule next meeting

Next Meeting:
26th March (4 PM BST) - Heiko will be absent

Schedule for April:
2nd - Heiko and Patrick will be absent
9th - No meeting (Easter Monday)
16th - Tim and possibly Harrison will be absent
23rd
30th

7. Any other business

  • [Ian] Last week a question was raised about what was going to be in the 1149.1-2012 update: I was wondering about trying to get an overview of what the changes are?
  • [Harrison] I think that might be a good one to do.
  • [Ian] I think both Adam and Heiko are on that group. Adam has dropped off the call now. I'll see if I can get something organized.

8. Review new action items

None.

9. Adjourn

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

Respectfully submitted,
Ian McIntosh