[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2009-06-01

Meeting called to order at 10:34 AM EDT

1. Roll Call

Eric Cormack
Ian McIntosh
Carl Walker
Brian Erickson
Brad Van Treuren
Adam Ley
Tim Pender

Excused:
Peter Horwood

2. Review and approve previous minutes:

5/18/2009 minutes:

  • Updated draft circulated on 19th May:
  • No further corrections noted.

Brian moved to approve, Eric seconded, no objections.

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
  • Patrick contact Cadence for EDA support person.
  • 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
    (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Carl W/Andrew: Set up conference call to organise review of Vol. 3 - Ongoing
  • Andrew: Make contact with VXI Consortium/Charles Greenberg. - Ongoing
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • All: Consider structure/content of survey - Ongoing
  • Harrison: Virtual system exploiting Configuration/Tuning/Instrumentation and Root Cause Analysis/Failure Mode Analysis Use Cases. - Ongoing
  • Brad: Virtual system exploiting POST and BIST Use Cases. - Ongoing.
  • Ian: Virtual system exploiting Environmental Stress Test Use Cases. - Ongoing
  • Brad/Ian - Prepare draft survey for review by group. - Ongoing
  • All: Propose answer options for the questions shown as needing completion. - Ongoing
  • All: Assess which section each question should be placed into. - Ongoing
  • Ian/Brad: Construct new question(s) for row 21 based on Brad's previous graphic. - Ongoing.
  • Ian/Brad: Construct new question(s) on gateway devices (linkers, bridges, instrumentation gateways). - Ongoing.
  • Ian: Circulate draft May Newsletter to group by May 22nd. - Complete.

4. Discussion Topics

  1. Gateway Definition (continued)
    • [Ian] At the last meeting there were a few comments that I thought we should be following up on: Are gateways within the scope of SJTAG? How do you track the last state of a chain, whenever you switch chains? Is management of Gateways White Paper material or part of the standard?
    • [Brad] Some other things: There is divergence in what tooling will support; Some will want you to define the protocols, while others will just ask you to detail the connectivity.
    • [Ian] The traditional boundary scan approach is to provide the netlist for connectivity and hope the tooling can sort out everything else, but is that the right way?
    • [Brad] That's what I struggle with. Leaving things open for the user to do the protocol can make things difficult.
    • [Tim] I agree, but I don't know if there's anything better than we have right now. It maybe needs some high level management.
    • [Brad] Being able to say 'I want that chain connected now' seems to be a more meaningful option.
    • [Tim] How are IJTAG handling dynamic registers?
    • [Brad] There is a SIB structure in the device, clearing or setting the SIB will turn the instrument path on or off.
    • [Adam] SIB is properly known as the Select Instrument Bit.
    • [Brad] There can be multiple SIBs inside a device, so you can select multiple instuments at once.
    • [Brad] I guess dot 7 has a new protocol for selection?
    • [Adam] 1149.7 allows for 2-pin operation, hence the need for addressability. There's also a defined mode for the 4-wire interface that also requires the devices to be addressed.
    • [Tim] We may need to provide support for this.
    • [Ian] We probably do.
    • [Brad] It's a big question: How do we define gateways to future-proof the standard? At the same time, we don't want block legacy designs with existing structures from the standard.
    • [Adam] I think what we've just been describing is a hierarchy of gateways: Gateways on the board, gateways on the chip and gateways in the chip.
    • [Brad] Then there are gateways to mezzanine's.
    • [Adam] I'd consider that more as a connectivity issue rather than heirarchy.
    • [Brad] We need to sort out hierarchy from connectivity in order to flesh out our system architecture model. Then we can deal with this gateway issue a bit more easily.
    • [Brad] When we discussed this a while back we came up with the 'assemblies' description for boards and systems, but that may be too general.
    • [Ian] I wasn't happy that there was a useful definition of 'system'. In our context, a radar 'system' may comprise three or four Line Replaceable Units, but from test perspective each of those boxes could be considered as a 'system'.
    • [Carl] But then the radar is just part of the 'system' that is the aircraft.
    • [Ian] Indeed. It all depends on your perspective.
    • [Adam] 'System' may be a useful term because it is not defined. You can talk about attributes asociated with assemblies, but what you can be sure of is that a system will have components or leaf elements that make up the composition under consideration.
    • [Brad] You may think of it as leafs in multiple containers. And you have to be able to deal with boards where the vendor is not supplying the full design data.
    • [Ian] We've previously said that was important. OEMs are naturally going to be reluctant to make too much of their IP public.
    • [Brad] I can envisage a 'super instruction register' that is an aggregation of all the instruction registers in the chain. You could then build commands for that super register that don't expose detail of the design.
    • [Brad] Also, there's the delegation aspect, when you instruct something to go test itself; that could be at the device level, board level or system level.
    • [Tim] I think we have to start out with the class assignment that Adam began to describe earlier.
    • [Brad] Can I ask, what is the general concensus here? Is it:
      a) It's all right just to define the connectivity of gateways, or
      b) The standard manages the protocols, or
      c) I'm really confused and don't know.
    • [Adam] I'd put myself under c) as I'm not certain how this intersects with the overarching effort here.
    • [Tim] For b) if you had to explain the protocol to the tooling how would that help?
    • [Brad] No you'd write the protocol.
    • [Ian] I'm inclined to agree on b) because letting the tooling decide on 'safe' chain selections would need better modelling of the system than I think we can expect right now.
    • [Brad] It sound like we're just dealing with connectivity within SJTAG then.
    • [Brian] I'm sorry, I thought a) was connectivity?
    • [Ian] a) was describe the connectivity to the tooling and let the tooling manage the protocols.
    • [Brian] OK, I go with b).
    • [Brad] This is an important conclusion, and will help with the Gateway questions for the survey.
    • [Ian] There is the issue of user sophistication, though. I can see people who will just want to throw a netlist and BOM at the tooling and let it come up with the solution. Maybe SJTAG is too complex for that type of use.
    • [Brad] I can see some software engineers who just want to hook up their WindRiver pod and do some emulation. They don't want to know how to set up the path.
    • [Brian] There are some FPGA vendors who don't really support gateway devices.
    • [Tim] That's why I like b). I can use a transparent CPLD to connect to the relevant chain, depending on some discrete signals I set up.
    • [Brad] When you get an external interface with multidrop coming off a backplane and you also have local control, it can look totally different to the tooling but in reality the tests are just the same.
    • [Brian] My anticipation is that vendors will not support beyond the board level. After that you need third-party tooling.
    • [Ian] That's no different to the current situation.
    • [Brian] Yes, that's what I'm saying.
    • [Brad] If we're smart, we might be able to migrate b) into a). Some tools already provide an element of dynamic control. I think it's important to note that b) does not preclude a) but a) precludes b).
    • [Tim] The next phase would be to ask how many layers you need. For my CPLD, I need 8 signals for 8 chains. I guess many people couldn't afford that many signals, so they may need to use the ASP type of thing with chain select being written into a register.
    • [Ian] That's part of the question that got me involved here originally. We have used multiplexers with discrete control lines and protocol-in-the-chain devices like scanbridges. Some designs have both types of chain selection and the tooling struggles to make sense of it.
    • [Brad] That's why in TFCL we have test steps to run at particular points to set up the chains outwith the test operation.
    • [Brad] There was a paper at ITC a few years ago that described using I2C for chain selection.
    • [Ian] Yes, we ended up with 'external' pre-conditioning operations too.
    • [Brad] There is some persistence of state across test steps that you need to manage.
    • [Ian] OK, we'll leave it there for now.

  2. May Newsletter
    • [Ian] To formally record the voting on the May Newsletter: Peter cast the first vote for approval of the newsletter and is noted as making the motion to approve. Adam's vote arrived next and is recorded as seconding the motion.
      There were five votes in favour of the motion, none against. Three eligible members did not vote, and so are recorded as having abstained. The motion to approve the newsletter is carried.
    • [Ian] This month, even more so than the last couple of months, the newsletter was a bit thin on content. I had wondered about reducing the frequency and Eric agreed with that.
    • [Eric] Yes, quarterly seems like good choice: It'd let us have discussions like today's and be able to present some options.
    • [Ian] Heiko and Peter also indicated that they'd be in favour of a less frequent publication.
    • [Brad] The danger is that people will start to ignore the newsletter if it doesn't seem to have much substance.
    • [Ian] That's exactly what worries me. I don't want to be padding it with meaningless text, just to get it to a size that seems right. So is bi-monthly or quarterly preferred?
    • [Brad] I move to change to quarterly publication.
    • [Eric] I'll second.
    • [Ian] Anyone opposing?
    • {Silence}
    • [Ian] OK we'll change to quarterly. The only problem will be remembering when it becomes due!

  3. 2009 Survey
    • [Ian] I don't want to dwell on this too long. I haven't had much time to do anything with the survey form, and I think Brad's also had other things to deal with.
    • [Brad] Yes, that's right.
    • [Ian] What I'd note is that there hasn't been any activity on the forum to comment on the current state of the survey form. Is that because there isn't enough happening on the form for people to be able to comment, or because of lack of time, or is there some other reason?
    • [Brad] It's been time for me.
    • [Tim] It's also time in my case.
    • [Adam] Again, time.
    • [Ian] OK. Time has also stopped me doing more with the form. I just wanted to sure there wasn't something I was missing. There are things I could be doing; sorting the order of the questions, getting the tooltips loaded, etc.
    • [Brad] We were also stuck on the Gateway questions, but today's discussion has given us good material for that.

5. Schedule next meeting

Schedule for June 2009:
Monday June 8, 2009, 10:30 AM EDT
Monday June 15, 2009, 10:30 AM EDT
Monday June 22, 2009, 10:30 AM EDT
Monday June 29, 2009, 10:30 AM EDT

6. Any other business

None.

7. Review new action items

None.

8. Adjourn

Eric moved to adjourn at 11:31 AM EDT, seconded by Carl.

Respectfully submitted,
Ian McIntosh

Copyright 2007-2009 The SJTAG Working Group
The SJTAG Initiative is "work-in-progress" and the views and opinions expressed here are subject to change without prior notice.