[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2010-06-21

Meeting called to order: 10:38 EDT by Brad

1. Roll Call

Carl Walker
Brad Van Treuren
Adam Ley
Eric Cormack
Michele Portalan
Patrick Au
Tim Pender
Peter Horwood
Brian Erickson
Heiko Ehrenberg (10:50)
Ian McIntosh (11:10)

2. Review and approve previous minutes:

6/7/2010 minutes: Motion - Eric, Second - Patrick, No against 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 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)
  • 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
  • All: Add to, or comment on, the bullet point list of architecture drivers. - Ongoing.
  • All: Provide forum comment on the graphics used during the meeting; suggest "building blocks" that may be used in future:
    http://forums.sjtag.org/viewtopic.php?f=29&p=257#p257 - Ongoing.
  • ALL: review / comment in preparation for upcoming meetings. - Ongoing
  • Tim: Draft matrix of SJTAG features against evolving solution options. - Ongoing.
  • [Brad] I am not sure if Ian completed adding the forum for ITC 2010, but I thought I remember some email about this being done. Can anyone confirm?
  • [Tim] I see he has the forum site up and made some postings to it.
  • [Brad] I know Ian was submitting something this weekend for the ITC Poster session. I thought we all agreed that a poster session was probably the only forum we would be able to support for ITC 2010.
  • [Eric] Yes, that is right.
  • [Brad] Tim, did you make any progress on the matrix?
  • [Tim] I started writing something up, but it is not ready for review yet.

4. Discussion Topics

  1. White Paper Volume 3 Review - Discussion of system description diagrams
    • [Brad] In light of Ian's absence, I guess I should lead the discussion, but I will need Carl's help in sharing the slides.
    • [Carl] I would be happy to. Just send them to me.
    • {Brad emailed "SJTAG Volume 3 Consolidated V6.zip" to Carl for posting the slides on the WebEx site}
    • [Brad] Ian and I have been corresponding about changes on the slides and this set has these changes that we made so far.
    • [Brad] I guess we can start with slide 27. This is the same primitives slide from the previous sets. I am starting here so you can see the progression we are now making.
    • [Brad] We rearranged the slide order to try to make the flow a little easier. So we now begin by introducing the TAP Switch Element on slide 28. I have made changes to the diagrams you will see today to try to use a common notation with PTDI, etc. on the left representing the Primary TAP Port and STDI, etc. on the right representing the Secondary TAP Ports.
    • [Brad: Missed during discussion] I added Tim's comment about a loop back between TDI and TDO is useful for testing this interface. So it truly is a 2n number of combinations of configurations.
    • [Brad] Next we show the TAP Bypass element on slide 29. This is the same slide from the previous set. Ian raised a point that we seemed to introduce the ParkVal signals without actually describing it. So the second bullet tries to provide a description.
    • [Brad] Slide 30 is the same with the corrected P and S names.
    • [Brad] Slide 31 is Ian's slide on complexity to show how the TSE trebles the amount of logic in migrating from 2 to 4 secondary ports.
    • [Brad] Slide 32 was added to try to show the scalability properties of the linker.
    • [Brad] On slide 33, we introduce the concept of the TAP Gating Element or as its alias name the Gateway. The first bullet tries to reveal that the gateway enables or disables a TAP to/from a bussed interface. Note also that we have introduced a simplified graphic on the lower right that just shows the data paths similar to what was shared on the board and system diagrams in previous slides.
    • [Brad] Slide 35 talks about the use of jumper blocks to set the configuration like in the previous slides. I think I missed a point that Eric made in a previous meeting that we do not recommend this approach as a good practice.
    • [Eric] Yes, that is right.
    • [Brad] Slide 36 has been relocated to here from where it was in the previous slide set. After much discussion, Ian and I felt it was better to introduce the concept of control of the chain configuration with the external boundary scan device at this point rather than later. This way we could introduce the need for synchronizing the control of the configuration with the scan operations. I added the callout box at the lower left to show the CPLD could be placed in a separate chain, but that the GPIO signals being controlled from it must be synchronized with the scan operations. I also added the bullet item that discourages this type of design. I also added Eric's comment from a previous meeting how the precondition is not supported by all tools.
    • [Brad] We made some major changes to slide 37. Instead of specifically using I2C as the bus interface, we have generalized this slide to cover all the different kinds of access mechanisms to the GPIO that are available and just showed a GPIO Expander representing the GPIO interface to the linker. Ian also had me extend the Primary TAP arrow to be even with the Simple Bus arrow and add in the Hosting TAP Interface box representing the external interface. The first bullet was changed to add in the examples of GPIO interfaces. The second bullet was added to reinforce the need for synchronization.
    • [Brad] In the previous slide set there was a slide that had 2 boxes next to each other where the left box represented the control logic and GPIO interface and the right box represented the configuration logic. Everyone felt the diagram was confusing. So on slide 38 I try to just address the left hand box as a new kind of control primitive. In this case I am showing the I2C interface. The point of this slide is to try to define how the control side maps to the chain selection side of a design.
    • [Brad] On slide 39, I take the same diagram as was on slide 38 and remap it to the gateway concept.
    • [Brad] It now isn't until slide 40 that we introduce the use of an integrated boundary-scan register within the device as the control mechanism providing the GPIO signals. On this slide I tried to just give an overview of what is required to add the GPIO signals to the same device. I note there needs to be instructions added to the Instruction Register that map to new data registers representing the GPIO interface. Ian raised the point that we talk about a TAP Controller in these slides and never really distinguish what element in the architecture we are referring to. Is it the state machine controller in the devices or is it the external host that drives the TAP? I am hoping that this slide reveals that we are talking about the logic within the device.
    • [Brad] Slide 41 is the same slide as before, except I have shaded bullets 1 and 3. Ian and I really don't know how to reveal to the reader that the TAP Controller is really just another path selection mechanism. It is yet another implementation of how you can control the routing to specific scan chain segments. We are showing the TAP Controller here as the mechanism to access the GPIO data register, but we also want to provide the insight to the reader that this is just another primitive. The only way I could think of highlighting this insight was to provide different shading on these bullets.
    • [Brad] Slide 42 is no different than from the previous set.
    • [Brad] The only change made to slide 43 was to add the text "Linker GPIO control signals" at the lower left to show what the signals coming from the Test Data Register are for.
    • [Brad] With slide 44, I tried to show how slide 38 and 44 are the same with the only change being with the GPIO box that now shows the IEEE 1149.1 TAP Controller as the source for the select and park signals.
    • [Brad] Slide 45 tries to show how the same structure can be used to control both the gateway and linker functions with the same control logic.
    • [Brad] Slide 46 shows an added section called "Commercial Implementations". I did not feel I should be highlighting specific vendor devices in this section.
      I am trying to highlight the various ways people are supporting the concepts already learned using commercially available devices.
    • [Brad] On slide 47, I introduce the Scan Path Bridge Protocol. The graphic is the same as seen on slide 45 with the addition of the 4 port linker.
    • [Tim] Is the name ScanBridge™ trademarked or copyrighted? Should we be needing to note this in our slides?
    • [Brad] The name ScanBridge, as one word, is trademarked by National Semiconductor. This is why I am using the term Scan Path Bridge Protocol to represent the protocol that was described by a paper from Digital Equipment Corporation in the late 80s or early 90s, I can't remember exactly when.
    • [Peter] That is correct. This is why we use the term gateway for our devices and not bridge.
    • [Brad] I personally think gateway is a more accurate term since you are enabling and disabling and not really bridging signals permanently.
    • [Brad] The point is we are referring to the protocol here and not a specific implementation.
    • [Brad] Peter, correct me if I am wrong, but your Firecron devices use this same protocol to manage the gateway connection to the primary TAP.
    • [Peter] Yes.
    • [Brad] I believe Lattice Semiconductor also has a CPLD image that supports this protocol as well. So the point is there are many commercially available implementations of this protocol for use by designers.
    • [Brad] Slide 48 is the same slide as from the previous set. Tim asked about what BT meant in the previous slide set, but that slide is no longer in this set, so the first introduction of the term BT is on this slide. So I think we have eliminated that point of confusion.
    • [Brad] Slide 49 is the same ASP slide from the previous set.
    • [Tim] I think you missed the P's on the left TAP signals.
    • [Brad] You are right. At least I fixed the STDO and STDI names.
    • [Brad] Slide 50 introduces the LASP concept as using a variation of the ASP protocol combined with the linker element.
    • [Brad] I am wondering if we need to explain the operation of the ASP protocol similarly to what we did for the Scan Path Bridge Protocol.
    • [Tim] I think you need to add a slide to show that the scans in the ASP protocol take place during one of the 4 stable states and not at the normal scan states.
    • [Brad] Perhaps I should add a slide that shows the TAP state machine and highlights the 4 stable states where the ASP scans take place.
    • [Tim] Is there also a need to add copyright information for TI on the ASP and LASP slides? Do we need to add a disclaimer on our slides for references to copyrighted and trademarked names?
    • [Peter] I think you could add a single page that states a disclaimer that all copyrights belong to their owners.
    • [Brad] That is really all the slide changes I have to show for you today. I was really trying to be a time filler for when Ian could join. I think what Ian was wanting to do for today was to identify what slides could be used in Section 3 of the white paper.
    • [Ian] Yes. That was my intent.
    • [Brad] I will hand the meeting over to you then to continue that discussion.
    • [Ian] As Brad said, we need to figure out where the white paper is going and identify what slides we can use as the basis for discussions in the white paper.
    • [Brad] You already include the simple primitives and the TBE. I would recommend you add Slide 32 as the next slide to cover in the paper. It's useful because it shows the scalability.
    • [Ian] That certainly seems like a good slide for the paper.
    • [Ian] Slide 37, being the kind of generic base diagram for linker control seems like a good one to use. Maybe 44 or one of the others like that, to show a more fully developed solution, such as you might find in a device that the user is likely to encounter.
    • [Brad] Maybe we can redraw slide 37 so that it looks a bit more like 44. Or use 38 and adjust the text to make it a bit more generalized?
    • [Ian] Yes, that would work. But remember that we only need the diagram for the wiki, since the bullets will be expanded out in the body text.
    • [Tim] I think you are missing a Bypass signal; some I/O going into that GPIO block. For example, if I want to support an Altera programmer, it does not know how to control all of the GPIO signals. It would be nice to be able to provide a way to connect up to the chain manually so the programmer will work.
    • [Tim] This could be something that might put people off: Not seeing how to work with the Altera programmer.
    • [Ian] I'm just not sure if we want to tackle it right at this point in the presentation. Maybe it's more of an appendix item.
    • [Ian] Certainly, this is a point we need to come back to. We might need to discuss this whole point as a side bar issue in the white paper.
    • [Brad] What you are talking about is a specific implementation of how to connect that controller interface. For us, we would rather connect the Altera programmer on the secondary side and ensure the secondary TAP is tri-stated. This way we have a shorter length trace for the signals and a single control point for that feature.
    • [Ian] We have done the same in some designs.
    • [Brad] It's setting up a default configuration for ICT.
    • [Tim] It's giving maximum flexibility. You need the alternative method for programming.
    • [Tim] Need another section talking about supporting multiple hosts.
    • [Brad] I agree. I have even other issues like how I can reuse the same vectors at the multi-drop level and the local board controller.
    • [Ian] I have some of the very same issues.

  2. Potential for ITC Participation
    • {Shared http://forums.sjtag.org/viewtopic.php?f=32&t=120}
    • [Ian] I've put together a poster session submission based around the assessment of the survey results. I tried to leave some wording in that might allow some reference to the wiki work as well, should that mature enough.
    • [Ian] I sent out the sample to Brad and Heiko for comment, but I guess Brad didn't get a chance to review it before I had to make the submission.
    • [Brad] No, I had to do some other things.
    • [Ian] Anyway, the title and summary are posted here, not that it really says that much.
    • [Brad] I thought that you'd worded things quite well in what you had. You included the diagram that showed the confusion over the layer interfaces and you mentioned that the responses on gateways were all over the map.
    • [Ian] Yes, I thought it was more relevant to talk about where the public view was at odds with our own, rather than where it was aligned. They're the bits where we need to do more work.

5. Schedule next meeting

June 28, 2010

Schedule for July 2010:
No meeting July 5, 2010
July 12, 2010
July 19, 2010
July 26, 2010

6. Any other business

The motion on signal naming conventions from the meeting of May 3rd remains tabled.

No other business.

7. Review new action items

None

8. Adjourn

Carl moved to adjourn at 11:47 AM EST, seconded by Eric.

Many thanks to Brad for leading the earlier part of the meeting and for taking substantial notes!

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.