The System JTAG Working Group

Return to index of Meeting Minutes

Minutes of Weekly Meeting, 2008-04-30

Meeting was called to order at 8:30am EDT

1. Roll Call (Participants):

Brad Van Treuren
Carl Nielson
Ian McIntosh
Heiko Ehrenberg
Peter Horwood (joined 8:40)

Proxy additions provided by:
Yingwu Li
Timothy Pender

2. Review and approve minutes

4/14/2008 minutes (deferred due to no quorum of that meeting attendance)
4/23/2008 minutes approved (Heiko moved, Ian second)

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
Brad come up with proposal for attendance and membership to core group. (Done)
Brad send out to the reflector the remaining use case topics for discussion for a vote on what to discuss next week. (Done)

4. Discussion Topics

SJTAG Value Proposition � Device Versioning

[Heiko] Is this for silicon level device identification only or does it include board/module level identification?
[Brad] This is what we have to define. For silicon we have both a device ID (IDCODE) and a definition of a USERCODE (can be variable). Unfortunately, these are all optional in devices.
[Brad] USERCODE provides version information for FPGA loads
[Heiko] Not many devices have USERCODE and if they do, how easy are they to reprogram in the field?
[Heiko] I've seen boards that have a silicon ID that has one wire that goes out to another chip for a board ID level.
[Heiko] This is not an 1149.1 IDCODE but more of a board version/id. It is a unique ID not one identifying the board type but the serial number of the board.
[Ian] It could be useful if you get serial numbers of particular batches
[Heiko] You still need to get Bscan access to this information and need an understanding of what the basic board structure is.
[Heiko] "Silicon ID" chip (device with single wire protocol and unique ID/serial number) - more to identify a board or module really to uniquely identify the module;
[Brad] device ID helps identify the type of components actually mounted on a board, information that can be used, for example, to manage test applications that can be applied to the board;
[Peter joined the call at this time]
[Brad] We had a case of a CM changed devices without informing us. These alternate devices were suppose to be functionally equivalent and the boundary-scan was equivalent except for the IDCODE. There were enough changes in the IDCODE that were breaking manufacturing tests for the primary device that the test engineer got the idea to mask out the IDCODE (an unfortunate event) from the manufacturing tests. It turned out that a special feature some new software needed in the field could not work with this alternate device because the device did not have the supporting hardware feature in it (not really equivalent functionally). Thus, we had to identify what boards in the field contained the alternate part and provide a special software patch on these boards to overcome this deficiency. We were able to use the embedded boundary scan to SAMPLE the IDCODE to identify boards that had the alternate part code. Since SAMPLE is non-intrusive, we were able to do this on live systems without stoppage of service.
[Peter, Ian] we have seen similar problems;
[Peter] I have found cases where CMs have changed parts without notifying the customer and the BScan scan path test identifies the IDCODE changed to notify there was a change.
[Peter] You can't always get the version information from a device from the functional interface.
[Peter] Some people store version information in small SPI roms that the software is able to access to know what BScan test to run. What happens when the board is down and the SPI is unaccessible? This is when the BScan adds value.
[Heiko] The point you make about the FLASH ID is important. We have seen this case with customer boards where software cannot be shipped with a particular version of the hardware.
[Brad] Current tooling for BScan does not allow for easy integration of dynamically reading USERCODE to identify if an automatic version upgrade needs to be done for an FPGA.
[Peter] How easy is it to program user codes? Typically, I only see this with FPGAs and CPLDs. Technically, the designer has to get involved with this change which requires the board to go off-line. Unfortunately, it is an optional feature that not all designers use.
[Ian] I have to admit, we don't really use USERCODE as much as we should. We we have a custom ASIC that contains the board information that is not accessible by JTAG but we found it a handy device because it can be accessible even with the board powered off. It is too expensive to reproduce now. There was a serial bus on the outside as an access bus and it could be updated by the on-board processor.
[Peter] How do people implement board ids now?
[Heiko] some people just use pull resistors to identify a board or module (on spare Boundary Scan pins or on dual-purpose Boundary Scan pins)
[Brad] device internal ID also offers a way to identify components and provide other information without the cost of added material (components) at the board / system level;
[Brad] I have heard talks about CPLD vendors adding USER instructions. This could provide access to board codes.
[Peter] This is a problem given each CPLD vendor has a different IR length.
[Brad] Device ID / Usercode is limited in the information the can convey; it would be beneficial to define a set of data and a methodology to collect it (e.g. in a Boundary Scan accessible PROM [Configuration PROM])
[Carl] I agree with all this point and that the IDCODE is quite useful to aid in the dynamic cases for boards in an embedded perspective. The ability to poll the system dynamically is quite important. Some devices don't have an IDCODE which makes things quite difficult to manage change in the system. Using device IDs is pretty key when it comes to dynamic decision applications. Fortunately, most new devices coming out today are coming out with device IDs.
[Heiko] 1149.7 is making IDCODE mandatory - maybe that helps pushing people to implement ID registers;
[Peter] Every card must look the same with ... (correction to be made)
[Brad] We should be able to standardize conceptually how to implement Device Versioning without specifying the actual implementation;
[Brad] In my 2005 ITC paper I described a way we used a BScan accessible configuration PROM to store the test data for a UUT and be able to extract it over the multi-drop bus using only boundary-scan. This same concept could also be used to extract information from the UUT other than just test data as long as the data gets a standardized format. PCI bus has a specific format for a board ID PROM that the OS is able to query to identify type and attributes of a board. I think device versioning value add gets into similar type of configurations that would be accessible from the boundary scan interface without requiring the operation of the board to be available.
[Brad] Are there other value-added features? figuring out board configuration for test management, programming and reconfiguration, etc.?
[Brad] Value add for versioning is the ability to support dynamic decisions to support automation in the embedded software. It is with this information that alternate paths in the control flow of the tooling may be performed. STAPL is able to take advantage of this dynamic decision quality, but SVF will not.
[Brad] Value add for alternate component configurations to identify what version of boards and associated software are required.
[Brad] I've seen cases where software upgrades were applied to a board of the wrong configuration and required a roll back even though the product database indicated the board was OK.
[Peter] The database is only as good at the information put into it. A field engineer might not have updated the information.
[Ian] We've seen where boards have new firmware installed, but the software was not upgraded and is incompatible with the new firmware. We need to get the fastest level of turn around so we end up changing out a much higher level of the module which creates added cost for the resolution. We are going through upgrades of some radar equipment that requires the firmware to be upgraded first before the software can be upgraded. The operator will not be able to tell because they rely on labels. Once you perform the upgrade, the label is now wrong and needs to be upgraded as well.
[Peter] So the automated boundary scan solution becomes almost like an automatic barcode for the configuration.
[Ian] Exactly
[Peter] There has to be a good value proposition for the management
[Ian] I think the need for it becomes almost obvious - especially when you look at how bad things can become if you don't have it.
[Brad] I think the use of versioning is low because the tooling aspects are not there to support it.
[Ian] I think that is relatively true. Everything we have done has been hand crafted. Especially when we go outside the device space.
[Brad] Mandating how to access the information and not the data content is what is missing in the tooling.
[Ian] Once you have the access structure you can use callbacks to define how you deal with the data.
[Brad] That is exactly right.
[Ian] The important point is how you get the data in the first place.
[Brad] SJTAG should be able to define the concepts that need to be available in a system design but not define specifically how to implement that.
[Peter] I agree. That should be able to be easily defined without specifying the gateway device, but ensure all the boards implement the same structure for each instance.
[Ian] OEM vendors need to worry about the organization of how this information is used and what needs to be the structure of the interface.
[Peter] Can you really get access to the information for a COTS board?
[Ian] If you want to provide an SJTAG compliant board, you must have these ID capabilities.
[Peter] This is really an enabling technology.
[Ian] I think most of what we are talk about in SJTAG are enabling technologies.
[Peter] SJTAG is a very wide capability of features.
[Ian] That is why I think we need to advertise SJTAG as enabling capabilities that people can leverage to reduce their test costs.
[Brad] I'm still concerned that the support infrastructure is missing for getting access to and processing of device information;
[Heiko] Having a standardized way to get to the device versioning information will help the tooling to provide that infrastructure;
[Brad] Is SJTAG the right place to define access mechanisms and processing concepts?
[the group seemed to agree that SJTAG can be the right place]

Yingwu Li Proxy comments:

I agree also that SJTAG can be the right place. The IDCODE is very
useful and usually we use it to identify the board type. Unfortunately Some
devices don't have an IDCODE. We need infrequently use the usecode.
End Yingwu's comments!

Timothy Pender Proxy comments:
I can't quite remember all the details but I thought in one of the 1149 specs IDCODE is optional but if it is included then USERCODE was mandatory. I also believe that 1532 requires both IDCODE and USERCODE, both are 32 bit registers. Most programmable logic devices are moving to be 1532 compliance.

PLD vendors USERCODE interface
USERCODE is simple to implement but if the designer or DFT engineer does not specify what the value should be, it will be defaulted to whatever the default is in the software could be FFFFFFFF or some PLD vendors will offer an option to automatically fill the field with the CRC signature, typically not enabled by default. In the altera GUI there is a dialog box allowing all of the device programming options (i.e. what file format SVF isc jam jbc etc) as well as the user code. Depending on the PLD vendor software you are using you may also have to modify the BSDL file to implant your USERCODE value. The BSDL file has the instruction to access the USERCODE but does not have the visibility to know what the value is. This is typical with any generic BSDL that you download from the websites. Actel took a different approach. You can not download BSDLs they are created on the fly with the design tool.

Soft BSDL
An Actel bsdl since it is created on the fly and will have actual signal names from your design in the bsdl and the USERCODE value is automatically inserted because the tool has visibility. We would generally have a TCL script to automate the place and route rather than having a designer manually press each button in the gui , typical flow would be to Load the design, assign device/pkg, assign pin numbers, compile, back annotate, route, create timing reports and logging, assign USERCODE, create programming file, save project)

One caveat, even though the USERCODE value is assigned within the TCL script the designer would have to remember to update the revision each time the script was run, I admit that during debug I released a couple different programming files with the same USERCODE because I forgot to update the version. By time these reach production there should be a checklist to make sure the usercodes are unique especially if Boundary Scan will use the USERCODE to determine whether it need to be updated. Auto CRC would guarantee that you have a unique value but you need a magic decoder ring to cross reference CRCs with Date/rev stamps.

One implementation of USERCODE
One of our schemes was to use 5 hexadecimal numbers for the date and 3 others could be used for version. For date stamps we would use one hexadecimal for the month, this would always be 1-C 1 = jan ,A=oct, b =nov, c=dec, you could use two hexadecimals as BCD ( 1 2 = Dec) but we saved on hex number for something else. Day would be 2 hex values, as well as year, Since we may have a couple different flavors within the same day we reserved some of the firmware rev. C2007001 C=Dec, 20 = day, 07 =year, 001 version (obviously we don't need 12 bits for version but it could be used for product ID, Plant ID , or whatever)

ASIC IDCODE OEM or Foundry
Regarding IDCODE in ASICs, you may have been part of all the email communications about a year ago when I sent a message to the BTW distribution list asking for feedback on whose IDCODE should be in the IDCODE field. Should it be the foundry or should it be the company OEM of the design. I got mixed answers some would say a Kodak ID should be in there and some would say it should be the ASIC foundry.

I know that It would be nice to have both, since we may have an asic created by two different foundries, It would be useful to have an IDCODE of the foundry and a second IDCODE of the OEM (Kodak)

Functionally readable IDCODE/USERCODE Registers
I think it would also be good to allow these IDCODE/USERCODE registers be able to read functionally. I know some devices allow you to read the IDCODE via a registers in the device.

Board Versioning
For Board versioning we would bring a nibble of external pullup or pull down resistors to a boundary scan node. We did not want to hard code these values in the design because we had one design that can be used on different boards. The terminators for the board version would tell the FPGA which features to enable or disable. This reduces the number of firmware variants that CM needs to control, rather than having several different programmable part numbers we only need one. In this case where you want one programming file across many different products your USERCODEs needs to be a little more generic, you don't want to have a board ID field specified in the usercode because it will require a different programming file for each unique usercode. since usercode is really treated as a programmable register and its value is determined by the programming file.

Config Prom IDCODEs
When dealling with configuration proms you can specify Two usercodes one will be for the configuration prom and the other will be for the FPGA(SRAM based).

In this case you would need to modify the BSDL for each the config prom and Fpga and update the corresponding values.

EPLDs don't use config proms so you will specify one usercode.
End Tim's comments!

5. Schedule next meeting

Monday, May 12, 2008, 8:15am EDT: Topic is Configuration/Tuning Use Case

6. Any other business

ATCA FRU states if available (Adam)
Review proposal for attendance and membership to core group (Brad)

Proposal sent out under separate email (Please review for next meeting)
There are some counter proposals being made, so please have your's ready

7. Review new action items

8. Adjourned at 9:38am EDT

(moved by Ian, second by Peter)

Many thanks to Heiko for assisting in taking notes for these minutes.

Respectfully submitted,
Brad