Minutes of Weekly Meeting, 2012-02-27

Meeting called to order: 11:05 AM EST

1. Roll Call

Ian McIntosh
Carl Walker
Patrick Au
Eric Cormack
Adam Ley
Peter Horwood
Brad Van Treuren
Tim Pender (joined 11:10)
Brian Erickson (joined 11:17)
Harrison Miles (joined 11:27)

Heiko Ehrenberg

2. Review and approve previous minutes:

02/13/2012 minutes:

  • Draft circulated on 02/13/2012.
  • No new corrections.
  • Brad moved to approve, seconded by Patrick, no objections or abstentions.

02/20/2012 minutes:

  • Draft circulated on 02/20/2012.
  • Add acknowledgement of Heiko's additional notes for the meeting.
  • Eric moved to approve with the above amendment, seconded by Peter, 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
  • Ian: Send out email with proposition to reaffirm the existing officers and requesting email votes by return. COMPLETE
  • Ian: Move Working Group Administration forum into the public section. COMPLETE

4. Discussion Topics

  1. Reaffirmation of Officers
    • {Tim joined at 11:10}
    • [Ian] We have 12 eligible members. In counting these votes up, I discounted my own vote with respect to the chair position and Heiko's as the vice chair. Adam had moved to reaffirm the current officers, seconded by Carl.
    • [Ian] There were 9 members voting for approval and 2 that did not vote, which I counted as abstentions.
    • [Ian] Eric volunteered, at least part time, to take on some of the editor duties.
    • [Eric] At the moment I have quite a heavy work load, but I will try to keep up on it.
    • [Ian] It does not mean you have to take an extensive set of notes, especially if others are taking notes like Heiko and I. This is especially true if you are talking. In fact, if anyone else is taking any kind of notes, please forward them on to me.
    • [Ian] We will probably wean down the detail of the notes a bit in the future.
  2. Discussion: "SJTAG in a nutshell - What I think SJTAG is all about"
    • [Ian] Given we have had a few attempts at how to tackle the whole SJTAG problem, I just wanted to put together a few slides that gives us a very simplistic perspective of a relatively unsophisticated end user view point.
    • {Ian presented his slides on screen}
    • [Ian] These are probably a simplistic view that I think is probably obvious.
    • {Brian joined at 11:17}
    • [Ian] I'm thinking of 1149.1 as a transport mechanism. It is a means of getting the information to the devices in the chain. It does not matter if there are 1532 or P1687 devices in the chain. It does not matter if you have a BDM device either. You basically have an 1149.1 access to it.
    • [Ian] (slide 4) You may also have multiple chains on the board. You also may have chains powered up differently that could cause a chicken and egg problem.
    • [Ian] (slide 5) Generally when you have JTAG it is conventionally agnostic to what the design does. But when you start bringing in the power sequencing and stuff, you need to start thinking more functionally about the design. This is where some of the complication and 'system' aspects comes into the thinking.
    • [Ian] (slide 6) When we look at a system, it is made up of multiple boards that implies multiple chains. In our antenna, it is comprised of 38 chains.
    • [Ian] (slide 7) SJTAG is basically enabling me to do the same things I do with boards, but at the system level.
    • [Ian] I may be differing from others on the call in that the interconnect testing is not as important to me since we can take advantage of our BIT.
    • [Ian] (slide 8) We find we need to be more concerned about the programming of devices in the system and this can become quite complicated when we have to deal with the chain management issues involved.
    • [Ian] These are kind of the fundamental issues that brought me into the group to start with.
    • [Ian] I imagine others here, Peter from a device provider perspective and Adam from a tool vendor perspective might have very different views.
    • [Ian] That was my starter for the discussion. Are there any other comments?
    • [Brad] I sent out a follow up email to your discussion slides.
    • {Harrison joined 11:27}
    • {Ian shared Brad's email}
    • [Brad] The first item is dealing with preconditioning that is required to get the board to work. That could be clocks, CPLDs, etc. A particular example is with the Freescale processors that after HReset need 32 clocks to get out of HReset and let the TAP Controller finally function. Without this, the chain is broken at that device.
    • [Harrison] The Freescale is really an easy case. The Intel x86 devices have a JTAG port that is really a proxy port that needs preconditioning. That's also in Altera parts.
    • [Brad] (Point 2) You may have multiple chains on a board leading to a requirement for some form of chain management.
    • [Harrison] Through this, are you hoping to mandate a single point of control? I'm considering that in a typical design, a large percentage of devices don't support JTAG.
    • [Brad] I'm more thinking that where you do have JTAG parts they're typically in multiple chains with single interface at the board edge.
    • [Brad] (Point 3) This is a 'stretch goal', maybe not an essential part of SJTAG. You may have similar boards with different artworks, or functionally different boards in a given slot. During a backplane test you would like to be able to control the I/O of the board independently of what board is installed in that slot. You would like to know what pins are inputs, outputs, or both on the board currently installed in that slot. I'm thinking of it like having a BSDL for the board that defines how you can control the backplane I/O of a board dynamically.
    • [Harrison] Would you be open to the idea of using the silicon ID register? It's already in many device and contains a manufacturer's code along with a user code.
    • [Brad] Peter, some of your gateway devices have that where there is a JTAG accessible register mapped to some pins on the device that the user can strap to what ever values they desire?
    • [Peter] That's right.
    • [Harrison] Well that's a possibility if it stops being an option and becomes mandatory.
    • [Brad] It's keying what design is in that slot. Slot location might be enough to identify the instance of a design. Possibly this topic is for some 'dot' release later on.
    • [Harrison] This needs to move in the direction of a mandatory ID register because it's not a burden.
    • [Brad] So ID registers become mandatory, but not necessarily the I/O control.
    • [Harrison] I would agree with that breakdown.
    • [Peter] You'd need some sort of central database, especially with COTS card data from the supplier. That might not be easy to get.
    • [Brad] We have been dealing with that for the ATCA boards. Fortunately, the ATCA protocol, using the board management controller interface provides the design and instance information already. It still is a matter of how to manage the data as you point out.
    • [Brad] Carl and I might have an easier time of obtaining the data for COTS cards than you would given we are the end customer.
    • [Ian] I may be going at a tangent here: Even if your board has only a single chain, there may be more than one device with an ID register, so you need to know where/how to look.
    • [Harrison] You could the silicon IDs with some hashing algorithm on the chain to get a board ID.
    • [Brad] I discussed this with Heiko some time back and he pointed out that you could have boards that are different but topologically the same.
    • [Ian] Very much. The 'planks' in our antenna all consist of the same single JTAG with the same FPGA as the only device in the chain, but there are many different types of plank, with different I/O.
    • [Harrison] It gets even more interesting as we're moving into the era of self-defined logic. That's not so simple - uniquely instance the board.
  3. [Brad] The discussion with Heiko I mentioned was back in 2005 when I was presenting our Boundary Scan Plug'n'Play. We couldn't rely on what devices were installed on the board to identify it. So we kept the tests for the board on the board itself, so we always got the right ones.
  4. [Ian] Yes, I mentioned our planks - they're all similar but even design that are vastly different can look topologically similar: Many of our boards will look like a chain with one big Xilinx FPGAs on it. The function will often be detailed by the non-JTAG chips around it.
  5. [Tim] In some cases you might be able to use the Usercode. There may be advantages if the Usercode had pins that mapped onto a register, so you could set it in the board design.
  6. [Brad] Peter's Firecron parts have board strappable pins that map to a defined register. It may be that it isn't big enough to give a unique ID, but the principle is there.
  7. [Harrison] About the gateways - Are they on each board?
  8. [Ian] Normally, each board has a gateway, that fans out to the chains on that board. But in our antenna, putting a gateway on each plank for a single FPGA was a cost burden, so we put six gateways on the backplane and fanned the chains out there.
  9. [Ian] So the answer is 'yes and no'.
  10. [Brad] That is similar to where we ended up on MicroTCA where I had to define the JTAG switch module because the AMC cards were used in multiple environments. AMCs can be used as plug-in boards to an ATCA carrier board serving as its parent where the chain management logic resides on the carrier, so no gateway logic should exist on the AMC. But in the AMC in the MicroTCA chassis operates as a system level blade. So the management of the chain of each AMC needs to be done with the JTAG switch module on the backplane. The use of the board determines whether it needs the gateway logic or not.
  11. [Peter] It all depends. The design may not warrant putting a gateway on it. If there's only one chain then maybe you don't need one.
  12. [Ian] We've really got to call a halt there and come back to this next week.

5. Key Takeaway for today's meeting

  • [Brad] This discussion begins to justify why the use of ID registers needs to be mandatory.
  • [Brad] Apparent consensus that a single TAP interface is required at system level (not precluding redundant interfaces).

6. Schedule next meeting

Next Meetings:
5th March
12th March
19th March
16th March

7. Any other business


8. Review new action items


9. Adjourn

Peter moved to adjourn at 12:08 PM EST, seconded by Brad.

Thanks to Brad for supplying additional notes this week.

Respectfully submitted,
Ian McIntosh