SCANWORKS TEST DEVELOPMENT STATION BUNDLE

Transcription

1 SCANWORKS TEST DEVELOPMENT STATION BUNDLE The ScanWorks Test Development Station is the most powerful set of boundary-scan test development and application tools available. It not only includes all the tools you ll need to quickly generate the tests needed to verify that the board was assembled correctly, but it also includes the software and hardware necessary to apply tests and diagnose faults to the pin level. In addition, you get tools to organize and manage your test data, control who has access to the data, APIs to create custom applications and user interfaces, support for system-level testing, support for the programming of PLDs, and features such as TopCAT, ScanWorks Assistant, and Scan Path Discovery all of which makes you much more productive. A Test Development Station is also the basic platform for adding other types of testing and programming operations, including IEEE High-Speed Interface Testing, IEEE 1532 Concurrent In-System Configuration, Extended JTAG Coverage based on International Test Technologies µmaster functional emulation testing and integration with any Agilent Medalist 3070 or i5000 in-circuit tester (ICT). Highlights Includes all the features needed for basic board assembly verification with boundary-scan Additional test and programming features are easily added Organizes and manages design and test data Creates and applies tests to verify circuit board designs and scan path integrity Provides a simple test executive and easy-to-use APIs to apply tests Enables easy transition of tests into manufacturing where they are applied by either a ScanWorks Manufacturing Station or an Agilent 3070 in-circuit tester

2 Boundary scan (JTAG) verifies the assembly of a printed circuit board (PCB) by testing the connections between devices (interconnects) to determine whether they work as intended. Effective and safe interconnect testing requires several steps. First, ScanWorks Test Development Station must be installed and set up. Second, ScanWorks will help you gather and organize information that describes your PCB design. Next, you ll use ScanWorks tools to create and verify an accurate design description. Then ScanWorks automatically generates tests or you can develop custom tests that accomplish your test goals. Once the tests are complete, ScanWorks organizes them into test sequences for application during design verification or manufacturing. ScanWorks JTAG - boundary scan tests are easily re-used throughout a product s life cycle. Tests generated in the development department can be moved to manufacturing or in a PCB repair operation. A ScanWorks Test Development Station ensures you accomplish your test goals quickly and easily. GETTING STARTED Getting started with a Test Development Station is straightforward and easy. The software can be downloaded from the ASSET support web site or from a CD. The PCI-100 controller card, which is bundled with the Test Development Station, is simply plugged into a PCI slot in your PC and connected to the PCB to be tested. Depending on the JTAG connector pin on the PCB being tested, an adapter cable may be needed. The entire installation process is described in a video on the ScanWorks installation CD. 2

3 When you start ScanWorks for the first time, ScanWorks Assistant appears to lead you through the system s set-up process. ScanWorks Assistant also helps you through entire test development process up to the point where tests are deployed in manufacturing. ScanWorks Assistant provides quick descriptions of each step so that you know why the step is necessary and how to accomplish it. If you need them, on-line videos will show you how each step in the process works. If you are already familiar with ScanWorks and JTAG (boundary scan), ScanWorks Assistant can be turned off. ORGANIZING YOUR DATA Before ScanWorks can generate boundary-scan tests, it needs a description of the boundary-scan features on the circuit board being tested. During test generation and application, design-specific information is created. ScanWorks organizes and manages this information for you by creating data structures called projects, designs and actions. A project contains designs, including all of the information about each version of a particular design. An action includes all the information about each test you ve created for a certain design. All of this information is compiled in a single compressed file so it can be moved easily among ScanWorks stations for further development, to repair boards, or to test manufactured boards. This compressed file also provides a convenient method for archiving and protecting your data. Figure 1. ScanWorks Data Management DESCRIBING YOUR DESIGN ScanWorks builds a description of your design from various types of information, including Boundary Scan Description Language (BSDL) files, CAD files of the design and models of non-boundary-scan devices. BSDL files are the only required files, but when more information is provided, such as CAD data and devices models, tests can be developed and deployed much faster. Many BSDL files, flash memory models, dynamic memory models and non-boundary-scan device models are available on ASSET s web-based model library available to maintenance customers only. Figure 2. Scan Path Discovery Block Diagram ScanWorks provides two methods for describing your design. If you know the boundary-scan devices and their order on the scan path, it is easy to list them in the proper order and to assign the proper BSDL file to each device. ScanWorks then automatically builds the required description files from this list. If the design is large or you don t have the CAD files, the ScanWorks 3

4 Scan Path Discovery utility can take a netlist and automatically discover the devices on the scan path, determine their order on the path, create description files and a block diagram of the scan path, and generate scan path verification tests. ScanWorks will accept practically any netlist format. Netlists are imported and converted to the ScanWorks internal format. ScanWorks also uses non-boundary-scan device information to ensure that any tests of the connections between boundary scan (JTAG) and non-boundary scan (JTAG) devices will be safe for the board. ScanWorks will not test any net if it is not certain that the test will be safe for the board. Device models describe non-boundary-scan devices IO characteristics. Many of the most common device models are available to ScanWorks users under maintenance contracts from ASSET s web-based model library. If a model is not available, it can be readily created. ScanWorks supports the description of more than one scan path in a design, and provides optional hardware to connect to more than one scan path. See the Multiple Scan Path support section of this document. CREATING TESTS Test creation in ScanWorks is semi-automated. Each type of test is organized as an action. The different types of tests include scan path verification, interconnect tests, PLD programming, I2C programming, custom tests using ScanWorks macros and Boundary Scan Language (BSL) files, tests generated with Serial Vector Format (SVF), plus the optional memory access verification and flash programming operations. Multiple actions of each type can be created and saved for each design. Available Action types Completed Actions types Figure 3. ScanWorks Actions 4

5 Each action is created through an intuitive user interface designed specifically for that action. The organization and format of the dialog box is consistent across all actions, making them easy to learn and use. Because most of the information needed to create a test is already available in the design description, the initial test can usually be built with one click of a button. Report logs indicate any errors or warnings that must be resolved. The test developer is given options to modify the test for increased coverage or to adjust the test for special circumstances. ScanWorks test coverage reports help you determine where additional coverage is needed and how to extend coverage to these areas. Also, tests can be applied directly from the development dialog so they can be validated rapidly against the hardware. You can also set preconditions to initialize your design for testing. And if more than one scan path is present on a board, you can select the scan path for testing. For more information on each test type refer to the detailed descriptions below. DEPLOYMENT TO MANUFACTURING Once tests have been created, they must be organized into a logical sequence for effective PCB testing. For prototype debugging and low volume applications, ScanWorks provides a simple operator user interface to control Figure 4. LabView using ScanWorks Virtual Instrument library the application of test sequences. A sequence can be automatically generated from the test actions created for a design. Later, sequences can be modified to set flow control options or to change the order in which the tests are applied. ScanWorksAPI allows tests to be easily integrated into test executives generated by the most prevalent tool sets such as LabView, TestStand, Agilent Vee, Visual Basic, or any language that supports Microsoft COM. With ScanWorksAPI, you can create your own sequence of actions or apply a sequence that was previously created in 5

6 ScanWorks. A Test Development Station can be used as a manufacturing station, but a more economical alternative would be to move the tests to the more cost-effective ScanWorks Manufacturing Station. The complete test set-up can be moved to manufacturing by exporting a single compressed file containing all the data needed for testing and then importing this file onto a manufacturing station. DIAGNOSING DEFECTS Finding defects is only half the battle. You must also be able to isolate the defect to be able to fix it and return the PCB to the manufacturing process. A ScanWorks Test Development Station includes several features that help isolate defects, including pin-level diagnostic reports and a test results window, which displays test results vector by vector. ScanWorks Graphical Fault Highlighting helps pinpoint the likely location of a defect by linking fault reports to a graphical view of the board layout or schematic. The ScanWorks Debugger and Scan Analyzer interactively control scan operations at level of a boundary-scan cell or register. These features also can generate a waveform view of the test results. Figure 5. Interconnect Test Results Dialog TEST GENERATION SCAN PATH VERIFICATION TESTS Scan Path verification tests are very important to effective boundary-scan testing. Before any test is applied, you should always verify that the scan path is working correctly. Scan Path verification tests are created automatically by the Scan Path Discovery tool or by a single button click in the Scan Path verify dialog. The test developer is given several options to configure a test for a specific application. To avoid placing devices in a test mode with unknown values on the devices outputs, Scan Path Verification tests begin by scanning data registers only. Once the basic data path is confirmed, instruction registers are tested and scans are performed to verify the length of the boundary scan register. The developer has several options to set alternative values for the device ID codes or user codes. Figure 6. Scan Path Verify development dialog 6

7 MODEL-BASED INTERCONNECT TESTS Three types of data are needed to quickly generate safe board tests with high fault coverage: An accurate description of the boundary-scan features of the board An accurate description of the connections between devices on the board Information about the IO characteristics of all devices on the board that interact with any boundary-scan devices The first two types of data were discussed above. The third type is derived from models of non-boundary-scan devices. Although ScanWorks does not need models of non-boundary scan devices to generate a test, tests are generated faster and with less manual intervention when ScanWorks has them. ScanWorks interconnect test generation will not attempt to drive any net (node) for which it does not have enough information to determine whether another device is simultaneously driving the net (signal contention). Since many boundary-scan nets are also connected to nonboundary-scan devices, information about non-boundaryscan devices is needed to automatically create safe tests with high fault coverage. This information can be added manually by defining constraints. Figure 7. Assigning device models Cluster models contain information on non-boundaryscan devices. Cluster models can describe the devices IO characteristics and certain basic logic functions. ScanWorks uses the logical descriptions contained in cluster models to determine whether test signals can be sent by an adjacent boundary-scan driver through a non-boundary-scan device to a boundary-scan receiver. This feature can dramatically increase test coverage. For a detailed description of how models are used to reduce test generation time while safely increasing test coverage, ask about our white paper on Device Modeling is Critical for Fast Time-To- Test. Models can be automatically included into ScanWorks tests during the design capture process or they can be added manually during test generation. Cross-reference files map netlist device type names to available models. Thousands of non-boundary-scan device models are stored in ASSET s web-based model library, which is available to maintenance customers. Models can also be easily created or modified. 7

8 ScanWorks also provides many other useful features for interconnect test generation. For example, a visual user interface simplifies the creation of test constraints to prevent toggling of specific nets or pins. And to minimize ground bounce, parameters can be set to limit the number of pins or nets that toggle during any scan. Test coverage reports clearly identify the coverage at the net and pin level. Nets are classified according to coverage and reported as a percentage of coverage in each class. An interactive debugger gives you a view of the vector as it is applied. The optional IEEE High-Speed Interface Testing feature adds the ability to test AC-coupled/differential signaling connections between devices. See the description below for more information about IEEE testing. Net-level and pin-level diagnostics are included in the Test Development Station. To rapidly isolate defects, the Graphical Fault Highlighting feature links a pin or a net from a fault report to a graphical view of the board layout. For details on interconnect testing see the Interconnect Test Fact Sheet on the ASSET web site. CUSTOM TEST GENERATION Although most boundary-scan interconnect tests can be developed with ScanWorks automatic test pattern generation (ATPG) tools, many times additional coverage can be achieved by manually generating tests. This is especially useful when a boundary-scan test can observe patterns applied to non-boundary-scan logic or analog circuits. Boundary scan or JTAG often is used during prototype debug or board repair to set static conditions on a board in order to initialize it for other types of tests such as instrument probing. The Test Development Station provides several convenient ways to generate custom tests or to apply certain boundary-scan patterns to a PCB. The test generation methods include Process Automation Scripting, a macro programming language and a boundary scan stimulus language. Process Automation Scripting is a very powerful tool with many applications. It supports custom test generation by providing access to all of the boundary scan (JTAG) features on any device that is accessible to ScanWorks. Test patterns can be applied and the results observed at any level of the design, from specific scan cells to nets at the board or system level. Any test programming language can be used to create these tests, including languages that support Microsoft s Component Object Model (COM), Tcl, Perl, Visual Basic, C, C# and C++. For details on Process Automation Scripting, see the Process Automation Scripting Fact Sheet on the ASSET web site. The ScanWorks Test Development Station s macro programming language is a powerful, high-level language that provides access to a design at any level; including individual scan cells, entire test registers or subsets of test registers. With specialized functions and procedures you can control or observe a specific pin or create a complete test for a cluster of non-boundary-scan logic. With a macro program you can establish safe conditions before entering the boundary-scan test mode or maintain a safe state throughout testing. 8

9 ScanWorks also includes a Bus Manager to enable you to define groups of signals, or busses, and assign meaningful names. Defining bus names brings the level of abstraction up from the boundary-scan cell level up to the design s functional level. Assigning stimulus values and comparing expected values with actual response data is much easier when working with signals such as data and address at the functional level. You can also assign symbolic names to specific data values to make custom test generation even easier. For example, you can name a 64-bit data bus data_64 then assign the symbolic name of zero_64 to HEX A Macro statement assigning a value of zero to the 64-bit data bus would be: data_64:= zero_64; Another option for custom testing is the Boundary Scan Stimuli Language (BSL). A BSL action can easily test a cluster of non-boundary-scan logic. BSL automatically creates a template file, which specifies the boundary-scan pins that control and observe the non-boundary-scan logic. This file also will contain the vectors to test the logic cluster. Tests generated in Serial Vector Format (SVF) can also be imported from other test generation tools. SVF is the de facto standard for transporting boundary-scan tests among boundary-scan systems. While SVF is convenient, it is limited in the diagnostic information it provides. In addition, imported SVF files are applied as is without the usual safeguards that are built into ScanWorks actions. Most ScanWorks actions can be saved as SVF files and applied in an embedded test environment or by any tools that can apply SVF programs. The Serial Test and Programming Language (STAPL) was originally developed and standardized as JEDEC Std. JESD71 to support in-system programming of PLDs with boundary scan. However, it has become quite popular as a custom test programming language. STAPL supports branching and looping statements, which SVF does not support. Most ScanWorks actions can be saved as a STAPL program and applied in an embedded test environment or by any tools that can apply STAPL programs. LOGIC DEVICE PROGRAMMING Strictly speaking, PLD programming is not a test operation, but it can be combined with boundary-scan testing to save time and avoid re-connecting the PCB to a programming station. Most PLDs, including CPLDs and FPGAs, can be programmed through the JTAG pins on the device. Tools from PLD vendors such as Xilinx, Lattice, Altera and Cypress create programming files in either SVF or in Serial Test And Programming Language (STAPL) (sometimes referred to as JAM files). ScanWorks imports these files and manages the scan path on which the programmable device is located. The target device can be located on any accessible scan chain. ScanWorks optional IEEE 1532 Concurrent In-System Configuration feature loads configuration data into multiple PLDs from different vendors concurrently, significantly reducing overall PLD configuration time. Devices are not 9

10 loaded sequentially. So, in most cases the total programming time for multiple devices is approximately the time to program the slowest device. For more information about this feature see the description in this document. The ScanWorks Test Development Station can also load data into devices using the I2C or SPI protocol. If the I2C or SPI pins are accessible from the boundary-scan pins of an adjacent device, ScanWorks can automatically detect these pins and execute the I2C or SPI protocols to load data files into the device. These features are often used to load board-specific data such as serial numbers and version numbers at test time. MEMORY ACCESS VERIFICATION ScanWorks Memory Access Verification feature can increase test coverage by generating tests that verify the connections between memory chips and boundary-scan devices. Memory devices are very often connected to a processor, PLD or ASIC-based memory controller, which usually include boundary-scan functionality. Tests based on a device s boundary-scan description language (BSDL) file and a memory device models are automatically generated to write data to and read data from memory devices, adding opens coverage to the shorts coverage provided by interconnect tests. Memory models for most memory types, including SRAM, DRAM, SDRAM, DDRAM and others are provided on ASSET s web site to maintenance customers only. ScanWorks automatically detects access to memory devices and tests are generated that detect and diagnose defects on the memory devices data, address and control signals. An interactive debugger is built into ScanWorks to simplify the debug process. For details on Memory Access Verification see the Memory Access Verification Fact Sheet on the ASSET web site. FEATURES Several capabilities of the ScanWorks Test Development Station increase test coverage or improve the efficiency of test generation and deployment to manufacturing. COMPREHENSIVE FAULT COVERAGE REPORT ScanWorks generates a comprehensive fault coverage report so you can easily identify the test coverage afforded by all of the tests that may be applied to a board. Because you may not always apply all of the test actions, the report generator allows you to select the test actions that will be included in the report. Any coverage resulting from a Scan Path Verify, Interconnect, Memory Access Verification or Flash programming action is included in the report. Any coverage obtained by using the IEEE High-Speed Interface Testing feature is also included in the report. The report specifies the number and percentage of pins with full, partial or no test coverage. Pins with full, partial or no shorts coverage and devices with full, partial or no opens coverage down are also reported and can be highlighted as a group in the Design Browser. 10

11 CONNECTING SCANWORKS TO THE UNIT UNDER TEST Although ScanWorks is primarily a software product, it must be connected to the UUT to apply the tests created with it. ScanWorks offers several hardware options for connecting ScanWorks to the UUT to meet your requirements for price, performance, and portability. If you need low cost, portability and convenience, the USB-100 Boundary-Scan Controller is the right choice. It plugs into any USB port, avoiding the need to open the PC to install a card in the backplane. It consists of a single pod, about the size of a deck of playing cards. It can be easily moved from your office to a station in the lab or used with a laptop to debug a problem at a customer site. It supports a single set of TAP signals with a voltage range of 0.8V to 3.3V and has a maximum TCK frequency of 20 MHz. Because of the USB overhead, the throughput is limited to about 3 Mbits/sec. It is not recommended for on-board programming applications in high-volume production. For more information see the USB-100 Boundary-Scan Controller fact sheet. The PCI-100 and PXI-100 are single TAP controllers with a voltage range of 1.8V to 5V and a maximum TCK of 16.6 MHz. It has a throughput of about 12 Mbits/sec at 16 MHz and is well suited for high-volume applications. It consists of a controller card that plugs into a PCI or PXI backplane and an interface pod to connect to the UUT. It can be expanded to support multiple TAPs with the optional Four TAP Buffer/Pod. For more information see the PCI-100 Boundary-Scan Controller fact sheet. The PCI-400 is a high-throughput boundary-scan controller that supports four TAP ports per pod, and can support two pods per controller card. It supports a maximum TCK frequency of 50 MHz and a throughput that approaches 50 Mbits/sec. It supports broadcast mode for flash programming, enabling it to program four identical flash memory devices simultaneously. It supports a voltage range of 1.8V to 5.0V and software selectable termination for TCK and TMS. For more information see the PCI-400 Four Port Boundary Scan Controller fact sheet. DESIGN BROWSER The InterComm Design Browser from PTC, Inc. provides many benefits. First, it provides a direct link between CAD tools and ScanWorks test generation tools. In addition, test engineers have access to all design data in an easy-to-use interface without having to learn how to use the CAD tools. Testability comments can be annotated in the files and returned to designers for review. Design changes can be immediately communicated to test engineers. In addition, the Design Browser extracts the interconnect information (netlist) that s needed for test generation and then displays the location of faults in either a layout or schematic view. 11

12 PROCESS AUTOMATION SCRIPTING API Process Automation Scripting makes ScanWorks features available through some of the most common languages used by test engineers. Whether using an interpreted language like Tcl, Perl, or Visual Basic or a compiled language such as C++ or C#, you can create and control the software objects exposed by the scripting interface. Process Automation Scripting uses Microsoft's Component Object Model (COM) making the objects available to any language that supports COM. Some of the common uses of Process Automation Scripting include: Gathering the design description data Use standard scripting features to retrieve the input files needed create ScanWorks tests, such as CAE/CAD design files, BSLD files, and netlists Creating and managing ScanWorks projects and design descriptions Use Process Automation Scripting functions to automate the process of creating ScanWorks projects and directory structures, and to create ScanWorks Actions Applying scan vectors use the language you are most comfortable with to create custom boundary-scan tests and custom applications such as controlling BIST operations Logging fault coverage and test results data - use standard scripting or programming features to organize and manage test results. INTERACTIVE DEBUGGER AND SCAN ANALYZER The Debugger/Scan Analyzer gives you powerful tools to debug tests that have been created with macros or as SVF files. The debugger gives access to boundary-scan cells and registers from the device, board or system level. You control when the scan operations occur and the values shifted into the device. Then, you can observe in either a register view or a pin view the results that are shifted out. You can even single-step macro programs or SVF files to see the results of each scan. The Scan Analyzer provides either a waveform or a state table view of the program or file s execution. Any mis-compare is highlighted so you can see what caused them. Figure 9. Scan Analyzer 12

13 FLEXIBLE NETWORK LICENSING A Test Development Station can be licensed as a single-user or as a network station. As a network station, the features of the Test Development Station would be available to any users who have access to ScanWorks and the network license server. This makes a single Test Development Station license available to multiple users throughout the workplace or across the globe. ScanWorks supports network licensing with FLEXlm from Macrovision, the de facto standard for network licensing. With network licensing, you can manage your investment in JTAG (boundary scan) tools and make them available to those who need them. You can control who within your company has access to ScanWorks by identifying users and groups of users, by allowing users to borrow a license for use outside the network, and by automatically retrieving a license after a specified period of inactivity. You can maximize the cost effectiveness of your investment by tracking ScanWorks usage through FLEXlm reports and, if it s necessary, purchasing discounted limited-term licenses for peak usage periods. ScanWorks also supports Emergency License Tokens to obtain an extra license immediately to support peak usage periods or to get a manufacturing station up and running quickly. You can pre-purchase a token and use when it is needed, or purchase it on-line with a credit card when the need arises. With Emergency License Tokens you should never have to stop production tests because your ScanWorks Manufacturing stations are not available. MULTIPLE SCAN PATH SUPPORT Although a single scan path provides the best test coverage and easiest test generation, there are many valid reasons for incorporating more than one scan path in a design. ScanWorks supports multiple scan paths through a combination of specialized hardware and software. It also provides easy and convenient methods for describing multiple scan paths in a single design. The primary method of accessing more than one scan path is through the PCI-400 Four-Port Boundary-Scan Controller. This controller card connects to four independent scan paths and can be expanded to support as many as 24 scan paths. The user maps each scan path to a PCI-400 port and then selects which ports will be active for each ScanWorks action. If more than one port is active, the scan paths are automatically concatenated together and treated as one scan path in the action. Describing multiple scan paths in a design is simplified by either the ScanWorks Design Wizard, which helps the user list the devices in each scan path in TDI-TDO order, or by the Scan Path Discovery tool, which examines the net list and automatically determines the devices in each scan path and their order. An alternate method of supporting multiple scan paths is to use the Four-TAP Buffer/Pod with PCI-100 or PXI-100 controller cards. The Four-TAP Buffer/Pod connects to four independent scan paths and can be expanded to 96 scan paths with additional hardware. You select which scan paths will be active by setting static switch on the Four-Port 13

14 Buffer/Pod or by manipulating ScanWorks Discrete IO signals. While the Four-TAP Buffer/Pod is not as convenient a solution as the PCI-400 Four-Port Boundary-Scan Controller, it does allow the PCI-100 or PXI-100 controller cards to be expanded to support multiple scan paths. OPTIONS FLASH MEMORY PROGRAM GENERATION On-board flash memory can be programmed with the addition of an optional feature to a ScanWorks Test Development Station. The flash memory feature takes netlist information and flash memory models and automatically detects the boundary-scan signals that program flash devices. Then, programming operations are generated to read and write to flash memory. For detailed information refer to the Flash Memory Programming Fact Sheet on the ASSET website. EXTENDED JTAG COVERAGE ScanWorks Extended JTAG Coverage incorporates the emulation-based functional test technology of µmaster (pronounced micro Master) from International Test Technologies. ScanWorks Extended JTAG Coverage takes advantage of the JTAG port that many microprocessors use for emulation. µmaster uses the processor s JTAG port to take control of the processor and instruct it to carry out various functional test routines. Now, with ScanWorks Extended JTAG Coverage, boundary scan tests can be executed on components such as memory devices that do not have boundary-scan capabilities but which can be accessed by the system s microprocessor. Combining JTAG test and microprocessor emulation technology gives ScanWorks the ability to reach places on a printed circuit board where boundary scan could not reach on its own, not only extending JTAG structural test coverage significantly, but JTAG TAP Debug CPU Boundary Scan for structural Emulation for functional CPU Emulation Either method is acceptable PCI Bridge Memory Control ASIC SDRAM Flash Ethernet Controller I/O CPLD Video Controller VRAM 16-Channel A/D 14

15 also adding functional test capabilities on the same ScanWorks test platform. This extended test coverage can reduce the requirements for other test types such as ICT, MDA or flying probe, significantly reducing test development time and overall test costs. The integration of µmaster into ScanWorks provides a seamless method of applying µmaster emulation-based tests from a ScanWorks-based test platform. Emulation-based tests are fully developed within the µmaster environment and then imported into ScanWorks as a ScanWorks action with all the capabilities of ScanWorks actions. Within ScanWorks, the user selects the emulation-based tests to be included in an action. When the action is applied, ScanWorks calls the µmaster run-time software to execute emulation tests through the µmaster Functional Test Controller Card and interface pod. When the emulation test is complete, µmaster returns Pass/Fail information to ScanWorks along with any diagnostic messages. ScanWorks incorporates this response into the ScanWorks run-time log. NAND FLASH PROGRAMMING NAND Flash memory differs from traditional NOR flash in several ways, requiring a separate application to program NAND flash device on-board. NAND flash is much denser than NOR can flash, with more memory in a smaller package, but it may also have memory locations that do not work properly. When a bad location is found, the entire block of memory is flagged as bad and is not used. Tools used to program NAND flash must be aware of the blocks of memory to avoid and not use them for data storage. Because of the density of the devices, the address and data signals are multiplexed to reduce the number of package pins required. This also requires special programming algorithms to use load data using boundary-scan access. In spite of the differences, NAND flash programming in ScanWorks is much like Nor Flash programming. Boundary-scan access to the NAND flash device is automatically detected and NAND flash device models provide the programming algorithms. The same source file formats are supported. IEEE HIGH SPEED INTERFACE TESTING The IEEE Standard for Boundary-Scan Testing of Advanced Digital Networks defines an extension to IEEE to standardize the boundary-scan structures and methods required to ensure simple, robust and minimally intrusive boundary scan testing of advanced digital networks not adequately addressed by existing standards, especially those networks that are AC-coupled, differential, or both, in parallel with IEEE testing of conventional digital networks and in conjunction with IEEE testing of conventional analog networks. The ScanWorks IEEE High-Speed Interface Testing feature adds the testing of compliant devices to the already robust interconnect testing features found in ScanWorks, increasing test coverage for nets that cannot be fully tested with techniques. 15

16 Many new designs are using high-speed serial interfaces for data transfer between devices and boards. In many cases these connections include coupling capacitors to compensate for electrical noise or logic level mismatches. The IEEE standard was developed to provide a method for testing through these coupling capacitors with boundary scan. Specialized boundary-scan cells are built into IEEE compliant devices that enable logic level transitions to be transferred from device to device at the speed of the interconnect net. ScanWorks implements tests as part of a standard IEEE interconnect test. ScanWorks automatically identifies the nets that can be tested with IEEE and creates interconnect tests for them, adding test coverage for nets that may have been untestable by any other means. ScanWorks supports testing of interconnects between IEEE and device pins because IEEE compliant boundary-scan cells are not yet available on many devices. IEEE 1532 CONCURRENT IN-SYSTEM CONFIGURATION The IEEE 1532 Concurrent In-system Configuration product makes in-system configuration of programmable logic devices (PLD) easier and faster. Concurrent PLD configuration not only saves programming time, but it also simplifies the process by incorporating the operations for programming several devices into one. The total programming time for a board or system is often reduced from the sum of the times for programming each device individually to simply the longest time it would take to program any one device. The product is based on the IEEE STD , Standard for In-System Configuration of Programmable Devices, in which ASSET InterTech played a key role in developing. Support for IEEE 1532 is seamlessly integrated into ScanWorks so that PLDs from all major vendors can be configured concurrently on the same platform that performs boundary-scan test. 16

17 EXTERNAL IO MANAGEMENT Many boards testable with boundary scan have great fault coverage between the IO connectors but coverage from the connector to the first boundary-scan device is limited to coverage for shorts. Adding coverage for opens between the connector and the first boundary-scan device requires access to test points on the connector or beyond. External IO Management maps boundary-scan based external test resources to the UUT signals to be tested for opens at the board edge. Boundary-scan based external IO is implemented with external hardware such as the ScanWorks Boundary Scan 400 IO Module (BSIO 400) or the Access Extender products from JEK Technologies. Custom BSIO hardware can be used by a simple resource definition process described in an application note available on the ASSET Maintenance Benefits web site. Defining connections between the external test resources and the UUT is done in an easy-to-use user interface or by defining the connections in a text file and importing the file. Net list merging is not required and the external test resources are not included in the UUT coverage reports ASSET InterTech, Inc H 17