Minutes of Weekly Meeting, 2008-05-12

Meeting was called to order at 8:23am EDT

1. Roll Call (Participants):

Brad Van Treuren
Carl Nielsen
Ian McIntosh
Carl Walker (had to leave at 8:57am EDT)
Tim Pender
Heiko Ehrenberg

Proxy feedback provided by:
Peter Horwood
Yingwu Li
Al Crouch (IEEE P1687 IJTAG Vice Chairman)
Carl Nielsen

2. Review and approve minutes

  1. 4/14/2008 minutes approved (Ian moved, Heiko second)
  2. 4/30/2008 minutes approved (Tim moved, Ian second), with corrections as proposed by Ian

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)
  • Register on new SJTAG web site (http://www.sjtag.org) (All)
  • All need to check and add any missing Doc's to the site (All)
  • Respond to Brad and Ian with suggestions for static web site structure (Brad suggests we model the site after an existing IEEE web site to ease migration of tooling later) (All)
  • Look at proposed scope and purpose from ITC 2006 presentation and propose scope and purpose for ATCA activity group (All)
  • Look at use cases and capture alternatives used to perform similar functions to better capture value add for SJTAG (All)
  • Volunteers needed for Use Case Forum ownership (All)
  • Continue Fault Injection/Insertion discussion on SJTAG Forum page (All)
  • Continue Structural Test use case discussion on SJTAG Forum page (All)
  • We will need to begin writing a white paper for the System JTAG use cases to provide to the ATCA working group (All)
    Most likely, champions will own their subject section and draft the section with help from others. This paper will be based on the paper Gunnar Carlsson started in 2005.
  • All: review how to use the forum
  • Locate ATCA glossary of board and system states (Adam, Brad)
  • Continue POST use case discussion on SJTAG Forum page (All)
  • Adam review ATCA standard document for FRU's states

4. Discussion Topics

  1. SJTAG Value Proposition – Configuration and Tuning
    • [Brad] similar to what we talked before, but slight changes in Boundary Scan involvement;
    • [Brad] often very underutilized right now; Configuration and Tuning via Boundary Scan is starting to grow (via special registers); Boundary Scan be a real-time component for system maintenance; IEEE P1687 is addressing some of the infrastructure issues;
    • [Brad] The lack of availability has been keeping this use case from being used more. With the advent of voltage monitors and other instrumentation devices, more people are leveraging the 1149.1 bus as an interface to the instrumentation since it is available for testing purposes already.
    • [Ian] I agree the lack of devices has been keeping this from being used more. As more analog devices with settable registers are coming around we are seeing the use of programmable resistors and other programmable aspects showing up.
    • [Ian] There are not many components supporting Configuration and Tuning yet available; I think we use some components with programmable registers for configuration, but those may be our own design;
    • [Heiko] I've seen applications of configuration and tuning utilizing non-Boundary Scan devices (since very few devices provide 1149.1 TAP access to such resources)
    • [Ian] I think that is true
    • [Ian] many people currently use other functional interfaces / protocols (such as I2C) to tune/configure such non-Boundary Scan devices, because it is easier for them to implement it
    • [Ian] I've seen devices configurable with I2C. There are more and more things coming that may be configured digitally.
    • [Ian] I think in practice people rather have the controller do the access via I2C than through JTAG.
    • [Brad] Do you feel people would rather use I2C over JTAG if I2C is available?
    • [Ian] I think it is an issue of convenience. If the JTAG bus is there and it is relatively easy to implement, JTAG would be accepted.
    • [Carl W.] We would rather have a single interface to implement than multiple interfaces. The problem is there are many devices that have primitive control.
    • [Ian] Device vendors try to make it easy to implement their device.
    • [Carl W.] The problem is that most device tooling work well with their device but not with other devices integrated into the communications bus.
    • [Ian] This is even true for I2C implementations.
    • [Tim] I'd prefer to have one interface for all my production test needs, many different interfaces to work with different devices makes the setup and the tests more complicated
    • [Brad] I've seen FPGA designs implementing serial interfaces (half-duplex RS232, or RS485, for example, Xilinx GNAT: http://www.xilinx.com/publications/xcellonline/xcell_53/xc_jtag53.htm) that are then accessible via Boundary Scan for debug;
    • [Brad] What about the "speed" of JTAG? Can that hinder what can be done in regards to configuration and tuning?
    • [Tim] It's usually quicker than I2C, for example; a bigger issue may be the number of pins required (4 instead of 2 or 1)
    • [Ian] However, if you already implemented Boundary Scan to support other use cases, then the access essentially comes free, since the pins are already there;
    • [Tim] That's true as long as you already have it. The micros today provide a slew of different interfaces on them. They have an I2C already, but most times the JTAG interface is a slave and not a master. Thus, you need to have a JTAG master implemented early. Sometimes you don't want to get into the JTAG world while in the functional mode.
      I like to see the JTAG there to get into the test things. I think having I2C communications is a good thing instead of messing around with JTAG as well.
    • [Brad] I have seen a design that implemented the I2C via JTAG as a back door capability to the I2C for failsafe.
    • [Carl N.] Do you know some of the discussions in the IJTAG group about limitation of JTAG? Do you know what kind of speeds P1687 is talking about for configuration and tuning?
    • [Al Crouch/P1687 (P)] I have seen JTAG implementations for IJTAG operation of internal instruments, once the 1149.1 BSR is decoupled since it is usually the frequency limiting factor, that run anywhere from 5MHz up to 400MHz - and I have seen a TAP-Only (no BSR) Implementation on an NOC that runs from data supplied by a 4-GBit SerDes interface (and used an S2P to deliver TMS, TCK, TDI data to an internal TAP Controller). When the TAP is used to deliver control and configuration data to instrument interfaces, or when the TAP is used to deliver test data to instruments - and it has been designed largely for this purpose, it is made to operate at the necessary test speed (e.g. the TCK is supplied by an ATE and doesn't have board-level limitations). My own 68060 when I worked for Moto back in 1993 ran up to 50MHz (which was the speed of the processor). Test time on ATE is one of the major cost drivers.
    • [Brad] Some of the applications P1687 covers will require a parallel access mechanism in addition to the 1149.1 TAP
    • [Brad] I think the hardest part of this use case discussion is the description of the capabilities (i.e. how to describe what resources are available for configuration and tuning and how to use them, what is the meaning of those resources, etc.; BSDL would not work as it is; P1687 is struggling with the very same issue); such description is needed to support automated tooling;
    • [Al Crouch/P1687 (P)] this is exactly the issue that has the P1687 committee working on the language issue right now. On the one hand, a language like CTL, IEEE 1450.6, is made to describe the features of a core with a wrapper that are enabled by a local instruction register known as a WIR; on the other hand, BSDL is made to describe "flat" structural connections; the P1687 language must do both and include "hierarchical" connections, "scan path management elements", and "dynamic scan paths". There will be a TAP-IR instruction that selects a GATEWAY TDR; the GATEWAY TDR will be made of Shift-Capture-Update boundary-scan-like cells, but when updated, (using Update-DR only) cells called SIBs will add a WSI-WSO scan path into the TDI-TDO scan path; this scan path may include an instrument, multiple daisy-chained instruments, or an instrument, instruments, or Gateway that adds a hierarchical connections to yet another set of instruments or Gateways. The connection scheme can be driven by engineering tradeoffs during the architecture development (routing, area, power consumption, activity level, safety, risk, access latency, etc.). There may also be a requirement to "hide" instruments, and so there must be a graceful way to not provide clues to hierarchical connections or branches that are meant to remain hidden from an end-user (but that may be used by an ATE Test user). At issue right now should be the minimal "content" required that "a" language should describe - not the form or format of the language.
    • [Carl N.] This is an interesting problem especially from the perspective of a tool vendor; Scan Path Linker and Scan Bridges are other examples where their functionality cannot be described in BSDL and instead a tool vendor has to extract the device function from other sources and hard code it in software;
    • [Carl N.] I think this is a true statement from a tool vendor perspective. There have been many devices available where the capability of the device is not able to be addressed by BSDL. We have to add this to our tool internally to support these types of devices. It is interesting how to deal with these from a standards perspective for generic tooling support. There might be parallel accesses to a chip that must be done in a particular way, but they want to support a JTAG interface, so how do we interface this. Do these interfaces need to be described in BSDL or some other description languages?
    • [Carl N. (P)] The values that go into the Data Registers called out in the BSDL and how the device will function based on those values is not typically described (resulting in the need for that information to be taken from the device data sheet and implemented in the tool itself)…one possible and already available solution to consider is to utilize BSDL Extensions for this purpose.
    • ... 8:57am EDT: Carl Walker had to leave ...
    • [Ian] perhaps we should take a look at IEEE 1671 (Automatic Test Markup Language for ATE's, http://grouper.ieee.org/groups/scc20/tii/)
    • [Brad] XML files can quickly get very large
    • [Brad] What do tool vendors have experience in with configuration and tuning? In the early days of 1149.1 there was a standard way of implementing BIST so it could be automated. Now, that is not the case.
    • [Heiko] At this time we cannot do much of the automated testing with BIST and other things like this because the data only resides in the data sheets. You have to implement these things ad hoc in your tools to be able to support these. So having a description language will help a lot to be able to provide the options to the basic registers to make it easier for test tool vendors to support.
    • [Carl N.] I definitely agree that having a description would really be able to help automate the tooling much easier. Our current scripting allows us to support these devices, but they have to be hand coded. With new BIST designs many times the engines run using the System clock instead of TCK so the time to run the test is not able to be described in the BSDL which prevents automation of the BIST operation, so this mandates a manual effort for the test program.
    • [Heiko] Having a standardized description of configuration and tuning features would definitely help tools to generate such applications; right now such tests often times have to created by manually writing code, which can take longer than someone wants to invest, therefore not utilizing configuration and tuning features with Boundary Scan access;
    • [Heiko] if users need to spend too much time collecting information about configuration and tuning features from different sources and creating respective applications manually, they may be tempted to just skip them or implement such applications as part of functional test with access mechanisms other than Boundary Scan
    • [Brad] So how do people develop these applications with, let's say, I2C interfaces? Are there automated tools for this or is that done manually as well?
    • [Al Crouch/P1687 (P)] In my experience, I have seen many, many cases of embedded "inside-the-chip" content being accessed by JTAG and by other mechanisms (one big common example is debug logic which can be brought out on a bus, a memory interface, the JTAG TAP or a specific debug Access mechanism such as ARM's CoreSight). In reality, the P1687 effort will first address how to get access to embedded content using the 1149.1 TAP and TAP Controller -- but the P1687 architecture starts at the Gateway and future iterations of P1687 may include other access mechanisms to talk to the Gateway (the Gateway being a JTAG TDR with Shift-Capture-Update cells that operates from the standard Shift-DR, Capture-DR, and Update-DR TAP control signals - and including at least one SIB that adds a WSI-WSO scan path to access an instrument). The Gateway interface can be viewed as a standalone Instruction Register whose bits select instruments and provide control signal generation, configuration signal generation, data value application, data-capture, and status-capture capabilities. The obvious control mechanism for the Gateway is the TAP and TAP Controller, but Dot-2, Dot-3, etc. efforts may map high-speed bus protocols or other controllers to the interface. This would make the P1687 Gateway Interface the beginning of the instrument access architecture and multiple different mechanisms could address it.
    • [Ian] I think I2C implementations are more hand crafted. There are typically libraries for typical access functions (e.g. write address abc with data xyz), but the intelligence for a test algorithm still lies within the test developer, who needs to manually code the actual test application.
    • [Tim] On the processor side, you just have to write to a register with data.
    • [Ian] Most times you have to write an address and then data. Usually, there is a library available to do this.
    • [Ian] In the end of the day, you don't want to hand craft low level stuff.
    • [Ian] Typically, I read a data sheet and then write the higher level application relying on the libraries to do the function calls of the protocol.
    • [Brad] I think the addressing for I2C is much simpler than JTAG.
    • [Brad] So if there were some form of a library to support the protocol to communicate with an instrument, this will make the JTAG more like I2C for tooling.
    • [Tim] For the Shadow Protocol ASP, I had to write my own code to write to it and communicate the protocol, so it was a pure manual operation and difficult to implement.
    • [Brad] Description of ports, Description algorithmic piece behind it, Description or library for the protocol communications seem to be the key elements missing in order to better support configuration and tuning at the SJTAG level.
    • [Tim] What would be really interesting if modeled as HSDL or something it would be nice to have someting that could be used for simulation of the interface before you actually get the hardware. You can validate your BSDL and validate your system interface ahead of time.
    • [Al Crouch/P1687 (P)] I am currently working with EDA Vendors to enable the insertion, simulation, design-space-exploration, and verification of the P1687 architecture as a step toward its adoption. One of the problems with BSDL today is that it is created by the design team to be used by the end user of the chip -- the design team and test team rarely use the BSDL themselves, so they have no interest in verifying it is correct and accurate (and hence, the end user figures this out at test development time). I want to ensure that the P1687 description can play a part in the design and verification and test of the P1687 architecture -- being able to generate/create compliance and verification vectors based on the P1687 description language is one way to drive this.
    • [Brad] I think we captured what we can for this use case at this time; I'll post something on the SJTAG Forum within the next few days;
    • [Yingwu (P)] If we have implemented SJTAG for testing, we would finish the Configuration and Tuning via Boundary Scan. But in many cases, there are other interfaces/protocols(such as I2C or CAN bus). In these cases in view of the cost we will finish the Configuration and Tuning via I2C or CAN bus.
    • [Peter (P)] There are many different configuration type devices out there using different interfaces SPI,I2C,JTAG one governing factor for implementation on a card can be as simple cost ,as this varies due to the interface for devices of the same type. For the generation of the tests to tune the parameters on the devices surly that should come from the silicon vendors and be exported as either SVF /STAPL etc so that the ATPG vendors can deliver the required vectors.

5. Schedule next meetings:

Monday, May 19, 2008, 8:15am EDT
Wednesday, May 28, 2008, 8:15am EDT

6. Any other business


7. Review new action items

  • Tim will add his comments regarding use case "device versioning" on respective SJTAG forum topic
  • Ian will add a Forum topic for "attendance and membership to core group" discussion
  • All: Review proposals (by Brad and by Ian) for attendance and membership to core group; possibly come up with your own proposal

8. Adjourned at 9:37am EDT (moved by Tim, second by Ian)

I want to thank Heiko for his assistance in writing these minutes.

Respectfully submitted,