[SJTAG]

 The System JTAG Working Group

Minutes of Weekly Meeting, 2010-05-17

Call to Order: 10:49am EDT

1. Roll Call

Excused Absences:
Eric Cormack
Ian McIntosh (proxy comments marked [Ian, P])
Heiko Ehrenberg
Peter Horwood (proxy comments marked [Peter, P])

Roll Call:
Carl Walker
Patrick Au
Brian Erickson
Tim Pender
Brad Van Treuren

2. Review and approve previous minutes:

Approval of May 10 minutes (draft sent 10 May):

  • Deferred approval due to lack of quorum.
  • Corrections:
    None supplied

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

4. Discussion Topics

  1. White Paper Volume 3 Review
    • Review and discussion of "generic" system diagrams.
    • How do we turn this into White Paper (wiki) material?
    • (Carl displayed SJTAG Volume 3 Consolidated V5.pdf)
    • (Slide 32)
    • [Brad] Easiest way to show control of the logic signals was to use a jumper block.
    • [Patrick] I am not thrilled with using jumpers. Is there any way to use some programmable GPIO?
    • [Brad] That is were we are moving to in the slide set.
    • (Slide 33)
    • [Brad] Control of the GPIO control signals is done using some GPIO Expander mechanism.
    • [Brad] I2C was used in this example, but I have noted at the bottom with the bullet item that other technologies could be used to provide access to the GPIO Expansion.
    • [Tim] I think you are missing the point that there needs to be some type of synchronization between the I2C and the JTAG operations.
    • [Brad] I could add another bullet that states there is a requirement to synchronize the actions between the I2C control of the GPIO and the JTAG operations.
    • [Tim] That would help.
    • (Slide 34)
    • [Brad] I struggled with this slide a lot.
    • [Brad] The CPLD is representing some boundary scannable logic that can be preconditioned to drive a particular state on the GPIO pins prior to performing the scan operations to the rest of the configuration.
    • [Brad] My struggle was were to place the CPLD - closest to TDI or closest to TDO?
    • [Tim] Design Engineers hate this kind of stuff that requires preconditioning of signals.
    • [Tim] They especially don't like it when they have to use tooling like emulators and programmers that don't support preconditioning.
    • [Carl] It is really something they can't test without performing some sort of preconditioning with this design.
    • [Brad] Tim, I actually found Design Engineers coming up with this design in the early days of chain management solutions so they could isolate emulation ports and debug ports automatically realizing the burden they are placing on the test engineers. I find more that Test Engineers hate this type of design more than Design Engineers.
    • [Brad] I guess what is missing here is a lot of red bullets indicating why one should not use this type of control for managing their chains.
    • [Brad] The purpose of this slide is to try to ease the reader into the understanding that JTAG registers could be used to control these signals. The later slide begin to migrate the JTAG register from an externally driven device into an internal register.
    • [Tim] You might want to explicity state that then.
    • [Brad] Well, this gets us back to my original struggle. Do I draw it closest to TDI or TDO?
    • [Brad] I chose to draw it closest to TDI so at least with a broken chain down stream, the CPLD could still be manipulated with the data coming in to possibly cause a reset signal to clear things up.
    • [Tim] If you implemented slide 34 with a CPLD you would need it closest to TDI.
    • [Tim] The new data register in a new TAP controller for a new linker would be able to be placed before or after the linked chains because you could always bypass around the linking section internally.
    • [Carl] Nearst to TDI makes the most sense since you can drive the precondition patterns to the CPLD even if the chain is broken or not configured right. If it was closest to TDO, you could not perform the preconditioning that could get sanity back to your circuit.
    • [Brad] There is a reason the commercial linker devices place the internal data register closest to TDO in their designs. But, I am not sure why that is the case. I really have not spent much time thinking about it until now.
    • [Ian, P] I'm not sure but it may be so that that you can at least get the linker's ID back during an infrastructure test even if the selected "Local" Scan chains are broken. In the example with the CPLD, placing it near TDI may make sense in many ways, but also means that you're "working blind" if you get no TDO at all.
    • [Peter, P] I would like to add, between the commercial linker vendors there is a mix; some have their data registers closest to the TDI whilst another has its registers closest to TDO.
    • [Brad] One difference between slide 34 and the commercial linkers is that the linkers can be reset back to a sane state where the only registers in the chain are the internal registers of the linker. You cannot do that easily with what is shown on slide 34.
    • (Slide 35)
    • [Brad] I added the first bullet that states, "TAP Controller is another path selection mechanism."
    • [Brad] I also added the last bullet that states, "May provide access to built-in configuration registers for a Linker."
    • [Patrick] That makes sense.
    • (Slide 36)
    • [Brad] I didn't change anything on this slide.
    • (Slide 37)
    • [Brad] The progression you have been seeing is the implementation moves from manual control to an externally controlled programmable interface using discrete GPIO signals. Now I am introducing the ability to use an internal data register in the same device where the linking logic exists. That is what the first bullet is trying to point out to the reader.
    • [Brad] I give reference to the ScanPathLinker designs used commercially use this method of addressing. In the red bullet, I changed the word "is" to "becomes".
    • [Tim] This slide is easier to understand than Slide 34.
    • [Carl] Slide 34 does not explain why you need to go to Slide 37.
    • [Tim] Slide 34 is initially confusing because it is putting a CPLD and a Linker in a single chain.
    • [Carl] In context, that is OKay for Slide 34.
    • [Brad] What I need to do is pose the problems on Slide 34 and forward reference the solution on Slide 37.
    • (Slide 38)
    • [Brad] I split up the previous single slide fo the Scan Path Bridge into two slides now. The first just has the graphic showing structurally how things are tied together and the corresponding text for the structure and addressing.
    • [Tim] What does BT stand for?
    • [Brad] Good question. I know it was on the slide before.
    • [Brad] I see it is shown in the caption on Slide 39, so I need to move the definition to Slide 38. Good catch!
    • [Brad] I added the first bullet item that states, "Combine TAP Gate Element with TAP Bypass Elements to provide an addressable DYNAMIC PATH to multiple Local TAP ports."
    • [Tim] Do you mean that these are truly two independent elements in the design or could they be combined to share some resources like the TAP Controller?
    • [Brad] That is a good question that I really did not consider.
    • [Tim] What confused me the most was the arrows between the two blue boxes. Is the only linkage between the bridge and the linker really only the TAP signals? I thought there might be some additional select signals necessary. What box has the TAP Controller?
    • [Tim] Can you take Slide 37 and reproduce it inside Slide 38?
    • [Brad] Maybe we need a new slide between slides 37 and 38 that shows 37 as part of the right blue box from 38?
    • [Brad] I could see drawing a graphic that has 2 blue boxes next to each other with another box overlayed across them representing the shared TAP Controller. From that controller, a data register could be shown for addressing and another for control of the select lines.
    • [Brad] Clearly, there is a lot more work that needs to be done for slides 37 and 38.
    • [Tim] How are you going to cover the synchronization issues that the multidrop devices handle today?
    • [Brad] I'm not sure this is the right place to begin to bring in those kinds of issues. I am afraid it is going to cloud up the reader's understanding if we introduce too much information in a single section. The goal of this section was to lead the reader into the realization that the configuration needs to be controlled by manipulating some signals. We also need to show them that it is possible to manipulate these signals using only the JTAG lines.
    • (Slide 39)
    • [Brad] I played around with how I could represent the association between the bridge state machine and the TAP state machine on a single slide. I settled with a mini-graphic of the TAP state machine with some color coding to show where the changes are made for the transition in the BT state machine. I also spaced out the bullets so they aligned with associated diagram.
    • [Tim] I am more familiar with the ASP protocol. Could we spend some time going through how this protocol works so I could better understand how it addresses the synchronization issues?
    • (There was a discussion of the protocol that followed that is explained in the datasheet for these devices.)
    • (Slide 40)
    • [Brad] I added some words to the last bullet on the right to explain why the RESET and Broadcast addresses are important.
    • [Brad] I also added the reference to DYNAMIC_PATHs as the last red bullet on the left.
    • [Tim] I think your graphic is wrong. The ASP ties PTDI to STDO and STDI to PTDO. You have PTDI going to STDI and STDO going to PTDO.
    • [Brad] You are right. I will have to change that during the next round.
    • [Brad] Well, we are running out of time. Let's move on the the next item.

5. Schedule next meeting

Schedule for May 2010:
Monday May 24, 2010, 10:30 AM EDT

Reminder: No meeting May 31

Proposed dates for June:
June 7
June 14
June 21
June 28

6. Any other business

Newsletter is due at the end of this month.
Please send your ideas to Ian.

7. Review new action items

No new action items for this week.

Adjourn 11:34 AM EDT
Carl made the motion
Tim seconded

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.