XJEase Functions

For a function to be eligible to be made available to XJRunner it must be in the main project (.xje) file or a device file, or in a code file specified either in the main project (in the Circuit Code Files Screen) or from within a test device file (in the Test Device Files Screen).

Not all functions can be used by XJRunner. In order for an XJEase function to be available it must take no input variables and must return a single integer to indicate pass (value 0) or fail (value 1 or any non-zero value).

i.e. it must be in the format:

FunctionName () (INT result)

CONNTEST

There is always one preset item in the available tests – this is the global function CONNTEST. This runs the automatic connection test.

This entry will focus on using BOM (Bill of Materials) information in the selectors, using the demonstration board that comes with the XJTAG development system as an example.

In this example we will create a new category on the demonstration board for all the KingBright devices on the board.

Open the demoboard project

• Open the project in XJDeveloper.

This should be located somewhere similar to:

C:\Documents and Settings\All Users\Documents\XJTAG 2.2\Demo Board\TestCode

Edit the BOM settings to use the manufacturer information

• Click BOM Settings… for the XJDemo board.

• Click Next> and set the column that contains the manufacturer information and set this columns data type to be “Device Description”.

Further information about using BOM can be found in the XJTAG help system.

The Import BOM File dialog

• Click Next> and then Finish

Create a new Device Category

• Click the menu item, Tools -> Options

• Click on categories, and choose “Device Selector”

• Click Add…

Set the Name and Pattern

• Set the name to be, “KingBright Devices”.

This will be the name of the category in the selectors.

When we edited the BOM settings we changed the “Device Description” field to be the manufacturer. We can use this in the category.

• In “Bom Description Pattern” enter the text “KingBright”

Using the category

• Click OK to close the dialog.

• Click the menu item, Tools -> Explore -> Device…

A new “KingBright” category is now present with all the LEDs on the board.

You can use any (or all!) of the “device reference”, “Bom description” and “Bom Value” to create categories.

This post is a quick reminder that you can use XJTAG as the focal point for your DFT analysis across all your test systems.

The Functional Tests screen in XJDeveloper allows you to mark devices, pins or nets as being tested outside of XJTAG. This means that the coverage shown on the DFT Screen will reflect all the testing being done for the board.

The DFT screen provides detailed analysis of the test coverage for your project and the statistics can be “drilled down” to a particular board, device or net to give you the detail you need to identify where test coverage could be improved. Data can be viewed in tabular or graphical form or exported to be used in other applications. In future versions we plan to improve DFT analysis and reporting.

If you have any suggestions for how we could improve our integration – or have suggestions for improvements to DFT then please feel free to get in touch.

Devices are grouped into categories

Entries are placed into categories based on their name in the netlist. The categories can be edited or new categories can be added from the Tools -> Options menu item. This can be useful if the naming convention of nets or devices in your netlists differ from the defaults used in XJDeveloper.

Options for editing Net categories

Each category has a name and a pattern to match names against. This pattern can either be a simple pattern, or a regular expression.

Simple Pattern

A combination of characters and the wildcards * and #

* matches 1 or more characters (letters, numbers,  any other characters)

# matches 1 or more numbers

Some Examples

NET*    – Anything that start with “NET” and has at least 1 character after it will be included in the category. e.g. “NET1″, “NETA”, “NET_TDO”

R#    – Anything that start with “R” and has at least 1 number after it will be included in the category. e.g. “R1″, “R20″, but not “RP1″

Regular Expressions

Clicking the Regex… button will convert your simple pattern into a regular expression. Regular expressions allow more flexibility, for instance you could have an expression that says:

match to an optional “+” or “-”, followed by either a series of numbers then “V” or the text, “VCC”

As you can see this is far more powerful than the simple pattern approach!

Regular expressions use regular expression syntax, which is beyond the scope of this blog entry. There is extensive documentation on regular expressions on the internet if you wish to find out more. You can also look at all the regular expressions used by the default categories in XJDeveloper.

Take a look at the patterns used for the default categories that XJDeveloper uses, and don’t be afraid to edit them or add new ones. If you make a mistake you can always press the Reset all categories button. The next entry in the series will look how BOM information can be used to refine categories further.

XJPack files are used by XJRunner in production. When you have finished creating your project in XJDeveloper, “pack” it and then this file can be used in production.

Zipping a project will create a single zip file that contains all the files used by the project. This can be useful if you are sending a project to another department, or for creating regular backups of your project.

Files which are not directly used by the project, such as schematics, can be included in the zip file by clicking the Add button on the Zip Project dialog.

Frequently during that time, customers would not have a netlist available in any of those formats, and so we began writing simple conversion scripts in Perl for the netlists that customers did have, to convert the simpler ones we found into RINF. With version 2.0, these scripts were formalised and integrated into XJDeveloper, which meant that such netlists were effectively officially supported. Over time, the number of supported formats has grown to nearly 60.

However, these netlist parsers are almost never based on a formal specification, but on the syntax we can infer from the customer’s example netlist. Often the customer is detached from the CAD process – they’re a manufacturer for example – and so they may not know what application the format is from, which means we may not even have a reliable name for the format! XJDeveloper is now smart enough that the user does not need to specify the netlist format – the format is recognised and imported automatically. If the format is not one of the original four well-supported formats or one of a handful of others – because of the uncertainty of naming the format – XJDeveloper will typically just display the name of the format as “ASCII”.

We are proud of the range of formats that the system is capable of parsing – our aim is that the user simply provides the netlist in whatever format they have and the system accepts it. If you have a netlist that is not recognised, then please contact XJTAG Support, and we will be happy to take a look and hopefully add that format to a future release.

If you have a netlist that is recognised, but comes back with errors, then again please contact us and we will do our best to fix it – we are always keen to improve our products.

XJDeveloper is used to write your tests and can run your tests whilst you are creating them. In a future version it will also integrate the debugging functionality of the command line tool XJDebug to allow you to debug your tests from within XJDeveloper.

When you have finished writing your tests you will want to send them to production and this is where XJPack files come in. Projects created in XJDeveloper are “packed” into a single file which can be opened by XJRunner in your production environment. This file will contain all the files in your project including any device files and passive files you have written. It will also contain the list of XJRunner tests along with all the XJRunner settings defined in XJDeveloper (for example the default set of tests to run).

To create a pack file from XJDeveloper go to the “File Menu”, and choose “Export Project” followed by “To XJPack File…”. From the dialog you can add any additional files that they are required by your tests (such as SVF or STAPL files). If you add any files they will be included in the XJPack file. If you do not add them then you can still distribute these along with your XJPack file and they can be accessed from it. This allows you to change the SVF or STAPL file after the pack file has been created.

One common confusion happens when the runner settings are altered in XJRunner. Because XJDeveloper exports the pack file the settings are contained within the pack file. Therefore changes made to the pack file from XJRunner will not get reflected in your XJDeveloper project. It should be seen as a “one-way” process – XJDeveloper produces a pack file and after that any changes made to the pack file do not get updated in XJDeveloper.

Launching the explorer

Currently the Netlist Explorer is a modal dialog which means you have to close it before you can use the rest of XJDeveloper. We hope to remove this restriction in a future release. You can launch the Netlist Explorer from most screens in Developer. All relevant toolbars have an “Explore” button, and right-clicking on items in controls will display a drop-down menu with an “Explore” button as well.

It can be very useful for determining what various pins are connected to – without having to refer to a schematic.

Two examples are of when it would be useful are shown below.

Example 1: Do I have access to the chip enable pin on a memory device?

• Either go to “Categorise Devices” screen and select the device, or go to the “Test Device Files” screen and select the file associated with the device and select the device from there.
• Click “Explore…”
• Select the chip-enable pin
• In the properties pane check the JTAG Access – if it has Write Access then you will be able to control the pin from your tests.

Example 2: Are all the I²C devices on the same bus?

• Select one of the I²C devices
• Click “Explore…”
• Double click the appropriate pin and the explorer will show all pins on all devices which are on the same net. Check that all the other I²C devices are listed.

The “Functional Tests” screen is in the “Design For Test” section in XJDeveloper. It is used to indicate to XJTAG that part of a board has been tested in some way outside of XJTAG. Doing this will make the DFT test coverage figures more accurate, and means you can use XJTAG as the focal point for all your DFT analysis across all your test systems.

An example would be the testing of a USB port on a device. Part of the test procedure may be to plug in the device and check that a computer recognises it. Therefore you could add the USB connector and USB devices to a functional test. The DFT Analysis would then show that these parts have been tested.

The DFT Analysis screen from XJDeveloper allows a developer to assess the test coverage of the devices and nets in the circuit, and determine whether there are areas where test coverage could be improved. This screen will be highlighted in a future post.