Minutes of Weekly Meeting, 2009-12-07

Meeting called to order at 10:38 AM EST

1. Roll Call

Ian McIntosh
Patrick Au
Tim Pender
Carl Walker
Adam Ley
Brad Van Treuren
Michele Portolan (joined 10:52)
Heiko Ehrenberg (joined 11:02)

Eric Cormack
Brian Erickson

2. Review and approve previous minutes:

11/30/2009 minutes:

  • Draft circulated on 30th November:
  • Corrections noted:
    • Call To Order and Adjournment times should be EST not EDT
    • In 4b: [Ian] Since our philosophy now is to program a completed system box ...
    • In 4b: [Brad] Another issue, with multidrop, is that we may have boards ...
  • Tim moved to approve with above corrections, seconded by Patrick; 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?
  • 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
  • All to consider what data items are missing from Data Elements diagram
  • 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
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • All: Review 'straw man' virtual systems and notes on forums:
    http://forums.sjtag.org/viewtopic.php?f=29&t=109. - Ongoing
  • Ian: Post bullet points (architecture drivers) from today's discussion on forum. - COMPLETE
  • All: Add to, or comment on, the bullet point list of architecture drivers. - Ongoing.

4. Discussion Topics

  1. White Paper Review - System Architecture
    • [Ian] Last week we suggested that Volume 3 may be better addressing 'System Architectures' rather than 'Hardware Architectures'. Brad has since posted a diagram on the forum as a stimulus for today's discussion.
    • {Forum topic on Volume 3 shared}
    • [Brad] What I was trying to do here was illustrate the roles within a system while not stating where they actually lie; trying to show the hierarchy.
    • [Brad] Even if you're testing with an external system, you still need to work around the internal control software: That may not necessarily be present during manufacturing.
    • [Ian] I know you're not stating where things lie, but there's a kind of implication that the Assembly Manager exists at the board level?
    • [Brad] Or at a subsystem level; maybe a shelf within a system. An assembly could be a System-on-Chip.
    • [Brad] I was trying to use terms that we'd used before. I was trying to capture the Push-Model versus the Pull-Model in data transactions. I guess one that's missing is the hybrid: a Pull-Model but with some events handled as Push-Models. For example on the ATCA type architectures, a Shelf Manager may query at will, some overtemperature or similar things will cause a preemptive message to be sent.
    • [Ian] A lot this messaging we're discussing, and it's going back the idea idea that JTAG is just part of a bigger pictures, seems like it's actually happening outside of JTAG?
    • [Brad] It's more about the locality: In a multidrop, the test is initiated from some other board, but somehow you need to resolve what that means at the UUT. It's tied and linked to control information about that board, and that's not easily understood. It's the number one question I get from people asking how they should implement multidrop in their system.
    • [Ian] That could depend on scope. I guess if all you want to do is run a JTAG POST, then the sequence is more strictly defined and the messaging less important.
    • [Brad] To some extent, but modern boards may have a complex power up and go into some limited state, depending on how 'green' the power up is expected to be.
    • [Brad] Redundancy for fault tolerance: Which circuit is 'active' and which is 'standby' may be determined simply by the power up race. Testing the Standby is easily done but not so easy for the Active one.
    • [Ian] So maybe for your diagram there are layers that could map onto more specific solutions?
    • [Brad] There are definitely many architectures that can be overlaid on that.
    • [Brad] Multiple boxes in a system may need to be tested individually at the shelf level.
    • [Ian] That's similar to our need: A radar is the 'system' but it may be made up of three or four distinct boxes. The aircraft commands the Processor when it talks to the radar, say to request BIT. The Processor then commands the other boxes. But take a box out of the system, then that box may be considered a 'system' in itself.
    • [Ian] OK, I took a stab at things from a different angle. I may have gone wrong though, because this became hard, and it's not as complete as I'd hoped!
    • {Powerpoint slides shared}
    • [Ian] Basically wanted to look at the physical aspects of a generic system.
    • [Patrick] Is a 'module' here a board?
    • [Ian] Yes, or maybe 'Assembly'. They're FRUs installed in some form of backplane. Then we can show each of these modules with one or more chains. Most people can understand the board-level chains.
    • [Ian] At the system level, we want to some coordination between the boards and some form of external interface. It's this 'woolly' bit I've called the 'Chain Linking Fabric'; there are lots of ways this can be done.
    • [Ian] This last slide is where it all starts to go wrong for me. In trying to draw something nonspecific it starts to look like a 'solution', which isn't what I intended. It looks like multidrop, but the paths to the module interfaces could be really be anything.
    • [Ian] I was hoping I could show some kind of 'layering'; overlays that built up on the basic hardware to show mapping onto the various entities that we've talked about.
    • [Brad] So you're building up to meet with my diagram as it flows down.
    • [Ian] One thing I tried to show here was that the System Management could be on the backplane, but is more likely to be on one of the boards. Generally, backplanes are difficult to remove so you would try to avoid putting circuitry on there that could fail.
    • [Brad] In some cases 'backplane' may just be wiring.
    • [Ian] Yes, in my mind I was allowing for a wired harness there.
    • [Brad] In your diagram with the cloud, that cloud should maybe be in the board chains.
    • [Ian] I was trying to include the boards too, because there's some indeterminate interface from the edge to the chains.
    • [Brad] There may be different levels of complexity there: It may be just a switch; either on or off. Others may also have state information, e.g. the state of TMS when breaking or closing the link.
    • [Brad] Maybe this is focussing in on the layers: Start by modelling the simple connections, then add more intelligence.
    • [Brad] The layers or compliance levels are a bridge between your diagram and mine:
      • Level 0 - Most simplistic only one chain
      • Level 1 - Multiple chains, either on or off
      • Level 2 - Bridging chains, add in state information
    • [Ian] I was trying to keep away from making what looked like architectural decisions, but it's hard not to have your own view of what's right come out.
    • [Brad] Maybe we need to represent the elements of connectivity: Building blocks of logic for chain management.
    • [Ian] Does anyone else have anything to add?
    • [Patrick] I don't I'm seeing anything new.
    • [Ian] I don't think it's new either, it's just tying to get to a generic representation.
    • [Brad] Maybe we can start by defining our grammar: We need a chain. Then a logical element that allows certain connectivity.
    • [Patrick] What about where you have more than one chain?
    • [Brad] That's where the logical elements come in. I think p1687 are going the same struggle to get a 'language' they can share.
    • [Ian] It occurs to me that some boards, maybe daughter boards in particular, will simply have 'chains'; no gateway of other management logic.
    • [Brad] So that management will have to be carried out somewhere else.
    • [Ian] Which is what I meant.
    • [Tim] It could be that all the boards have the same management and the control runs through them all, just in some boards parts of it get turned off. Maybe a register that gets set to say it's a Slave or a Master.
    • [Brad] Broadcom had a paper at ITC, maybe 2005, where they had chain selection via I2C.
    • [Ian] We had something on a design that was fed into us from a partner that had some custom arrangement to select chains. It was simple enough, but gave real problems with the tools when developing the tests.
    • [Brad] The tooling need to know how to control the chains.
    • [Ian] That was the problem in this case; the tooling couldn't figure out how to select the chains, because we didn't have an adequate way to describe it.
    • [Brad] Tooling can't be expected to do all things for everyone. But it is fair to say that there need to be 'hooks' for some of those other things.
    • [Ian] Again, it's JTAG being part of a bigger environment.
    • [Brad] And needing to coordinate with that.
    • [Ian] I'll get my slides onto the website in some way that you can link from the forums. {ACTION}
    • [Patrick] And ask people to comment?
    • [Brad] Yes and make suggestions on the building blocks. Other insights may be helpful. We could use a 'graphical erector set' to represent systems and topologies. Something we can use to describe our requirements against.
    • [Carl] Did P1687 have anything we could use? It seems that we're solving the same problems
    • [Brad] I don't think there is. One of the issues is that our bubble includes their bubble.
  2. 2009 Survey
    • [Ian] Once again we don't have time to discuss this. Maybe Brad and I should take considering what we expect from the survey outside and in slow time, as we were the main authors.
    • [Ian] One thing I need to do is send out the reminder email to the people who have not yet responded; that includes most of the people on this call! {ACTION}
    • [Brad] When will the survey run until?
    • [Ian] I said we'd hold it open up to Christmas Eve.
    • [Patrick] I'll do it before I go on holiday.

5. Schedule next meeting

Schedule for December 2009:
Monday December 14, 2009, 10:30 AM EST

Patrick and Eric will miss Dec 14

  • [Ian] Next week will be the last meeting for this year, so we should probably agree January's schedule now.
  • [Patrick] We're back at work on the 4th.
  • [Ian] I don't think I will be; both Friday 1st and Monday 4th are holidays here. It's not mandatory that I'm present though, if others feel they want to meet that day.
  • [Brad] I think we need some of your engagement in the discussions, Ian, so it may be better to wait until the 11th?
  • [Ian] Is everyone happy with 11, 18 and 25 January then?
  • {Agreement}
Schedule for January 2010:
Monday January 11, 2010, 10:30 AM EST
Monday January 18, 2010, 10:30 AM EST
Monday January 25, 2010, 10:30 AM EST

6. Any other business


7. Review new action items

  • Ian: Make slides used today accessible on website
  • All: Provide forum comment on the graphics used during the meeting; suggest "building blocks" that may be used in future:
  • Ian: Mail out reminder message to people who have not yet responded to the Survey Invitations.

8. Adjourn

Tim moved to adjourn at 11:38 AM EST, seconded by Carl.

Respectfully submitted,
Ian McIntosh