Device Versioning

[Ian McIntosh]

Meeting Minutes reference:
http://www.sjtag.org/minutes/minutes080430.html

Typically device version can be done via the use of a small prom that can contain vital product data including all revisions of firmware/build; this information is normally read via the on board processor and as such requires that the board be operational. However, there is the case where the card is not bootable - how can the card's versioning information be accessed? The answer is JTAG: Using this can be done to support device identification and chain integrity via infra structure tests. However the programming of usercode, data typically found in FPGA/CPLD technology to indicate firmware levels is impractical as this data must be generated at programming file creation time.
It would be possible to provide JTAG access to a prom so that data can be read back via JTAG to enable complete system versioning information via JTAG.
For a system this implies that there must a standard access / method for all cards to present their version information.

[Tim Pender]

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.

[Ian McIntosh]

Developing the Application Fields topic:

Working with Brad's comments from his earlier post:

The Device Versioning Use Case was developed originally for the ability to discover the IDCODE of all the devices assembled on the board in order to validate that the order and type of devices assembled on the board were indeed what was expected to be there. This ordered set of defined devices might have an impact on what software must be installed on a board.

It seems to me that we can use this pretty much verbatim as the first item.

Device Versioning is really not just limited to a single type of operation (the reading of IDCODE values), but is useful for reading any information from a device that allows one to determine the structure. This also includes reading information indirectly using boundary-scan signals as the access point to the data (e.g., reading FLASH data by stimulating the address and control lines from boundary-scan).

This should be usable as an introduction into other applications. Thereafter it becomes more difficult to simply extract phrases from Brad's post. The elements are mainly in the first paragraph of that post, but need a bit of re-phrasing.

[Ian McIntosh]

In the short time I had today, I wanted to jot down some text behind some ideas.

The first application to consider is the determination or verification of the circuit topology regarding the set of devices constituting the circuit under test. The device IDCODE register contains information describing the manufacturer as well as the type and version of the device. The IDCODE information may be useful in identifying those installations which require a software patch because of some missing features in a particular brand of hardware. It may also be useful for identifying those installations where a recall is warranted due to a problem with specific device revision.

Second, a simple iteration through possible scan path verification tests can provide valuable information as to what version of a board is installed in a system (the passing test indentifies the UUT). Since the scan path verification test is non-intrusive, it may be run at any time.

Third, the same scan path verification technique may also be used to interrogate mezzanine installations to determine or validate the structure of the parent/child relationships.

Fourth, Device Versioning is not limited to just reading the device IDCODE regiser, but is useful for reading any information from a device, whether it be a directly accessible boundary-scan register or an indirectly accessible memory location which is able to be read using boundary-scan controlled signals to stimulate the device to provide the information (e.g., FLASH memory contents).

Fifth, most programmable devices provide a USERCODE register or some user defined accessible register that may be programmed by the firmware designer. The firmware may use this register to encode the revision information of the firmware used in the device. This information may be accessed with boundary-scan to aid in determining the firmware revision and cnfiguration of a device in the field.

[Heiko Ehrenberg]

It's probably obvious to all of us, but if someone has two or more different types of boards with the same scan chain but different types / values of non-Boundary Scan devices, then reading the IDCODE alone does not help in differentiating the various boards. Device Versioning for such types of boards would need to include reading some other information as well, if one wants to differentiate the various board types/versions.

[Ian McIntosh]

...reading the IDCODE alone does not help in differentiating the various boards.

A good point, but I'm really not too sure under which heading we should make it!

In a previous discussion (which I can't actually find a reference to right now) we used the term "auto-discovery" in the context of identifying the complement of boards within a system. Is that something we can use in relation to Brad's second and third points?

[Ian McIntosh]

OK, trying to pull together what we have so far, here's a proposal:

The Device Versioning Use Case was developed originally for the ability to discover the IDCODE of all the devices assembled on the board in order to validate that the order and type of devices assembled on the board were indeed what was expected to be there. This ordered set of defined devices might have an impact on what software must be installed on a board.

This base application may be extended to verification of the system composition: Iteration through possible scan path verification tests can help identify each board installed in a system (the passing test indentifies the UUT). This may be further extended to encompass the verification of installed mezzanines. It is worth noting that since the scan path verification test is non-intrusive, it may be run at any time.

However, device IDCODES alone may not always be enough to uniquely identify the type or version of a board, and it may be necessary to read some additional feature, whether it be a directly accessible boundary-scan register or an indirectly accessible memory location which is read using boundary-scan controlled signals to stimulate the device to provide the information (e.g., FLASH memory contents).

Most programmable devices provide a USERCODE register or some user defined accessible register that may be programmed by the firmware designer. The firmware may use this register to encode the revision information of the firmware used in the device. This information may be accessed with boundary-scan to aid in determining the firmware revision and configuration of a device in the field.

This maybe rolls some of Brad's points together: Does it lose anything in doing so? Is this crossing over too much into the Detailed Description?

[Bradford Van Treuren]

I think Ian's new paragraphs capture what we have been needing for this section. I don't feel it has gone too far in overlapping the detailed description as it does not explicitly map out the process - only the concepts. Any less of a description will not inform the reader as to the importance of this use case.