Please Note: You must be logged in to edit this wiki. To login, you must have an account on the SJTAG Forums and have been granted membership of either the Core_WG or the Extended_WG usergroups on the forums. You may then login to the wiki using the same credentials* you use for the forums.
* In some rare cases, it may be necessary to assign a wiki username that is different to your forum username.
Volume 4 - Languages Document
- 1 Context
- 2 Language Mapping to Circuit Model
- 3 Role of Languages
- 4 Dynamic and Static Information
- 5 Implementation Issues
- 6 References
About this Document
This document, Volume 4 of 5 volumes, provides a comparison of existing, ad hoc language specifications, and identifies essential features for language support for SJTAG, covering aspects of management and execution of JTAG operations, sequencing and flow control, results handling and data exchange.
Readers seeking further information on specific topics are directed to the following volumes:
- Volume 1 – Overview
- Scope of SJTAG
- Purpose of SJTAG
- Primary Constraints
- Relationship to Other Standards
- Volume 2 – Use Cases
- Structural Test
- Software Debug
- Built-In Self Test
- Fault Injection
- Root Cause Analysis/Failure Mode Analysis
- Power-on Self Test
- Environmental Stress Test
- Device Versioning
- Volume 3 – Hardware Architectures
- Hardware Topologies
- Device Under Test Connectivity Schemes
- XBST - External BST
- Built-in Self-Test
- In-System Programming/Configuration (ISP/ISC)
- EBST - Embedded BST
- Tooling Requirements
- Conformance Levels
- Volume 4 – Languages and Data Formats
- Language Mapping to Circuit Model
- Role of Languages
- Dynamic and Static Information
- Implementation Issues
- Volume 5 – Business Case
- Topic 1
- Abbreviations and Glossary
Language Mapping to Circuit Model
This is the section I want to flesh out with the UML diagram to illustrate the entities we are going to be talking about. This section will introduce the problem domain elements that have to be considered when designing a system level test system and the supporting elements/languages/formats to enable the use of the testing/control infrastructure. Much of the text I added was taken from my feedback to Gunnar about STAPL++.
Describing the structure and content of a system to JTAG tooling, such as ATPGs or device programming tools, in a consistent manner is one of the more fundamental challenges facing an SJTAG implementor. There is no single descriptive form that provides all of the information necessary: While circuit descriptions and some device models may be available from the CAD data, other device descriptions need to be provided by the vendor or derived from other sources. Frequently, the overall system structure may not be modelled in CAD, and in any case such rigid descriptions would not be helpful in cases where system integrators or end users can modify the system configuration.
The UML diagram of Figure 1 is an attempt to capture the hierarchical composition of the generic system and the possibe data sources for the device descriptions. Such a detailed description is necessary to allow tooling to generate the vectors required for device, board and system-level operations. However, if the objective is simply to establish that boards are properly installed within a system, then it may only be necessary to describe the board boundary in order to conduct interconnect testing with the remainder of the system. This may be attractive to the OEM board vendor who does not want to expose the CAD data of their designs and the inherent IP.
Role of Languages
The purpose of a language is to provide a formal way of describing a solution to a problem domain. For humans it is to effectively communicate thoughts and ideas to one another. For test, it is to describe what the tooling must do at specific instances in time and to respond appropriately to the outcome of the tooling events.
System Test Language Role
The first question that needs to be asked is, "What is the problem domain the language will be working in?" To say "System Test" is so broad of a subject that no single language would be able to encompass the whole domain and still fit within the limited resources available in a system – The IEEE Std 716-1989 Common Abbreviated Test Language for All Systems (C/ATLAS) is a case in point. If we narrow the focus to, specifically, JTAG applications, we still have a broad problem domain, but also leave out some necessary synchronization to functions handshaking with the JTAG based tests. A good example of this is coordinating the parallel interface test port of an IEEE Std 1500 instrument with the IEEE P1687 IJTAG control interface. Another is the need to coordinate I2C operations with JTAG scan operations as demonstrated by Brocade Communications Systems, Inc. in their 2006 International Test Conference Paper. The most obvious example is the coordination of 1149.1 scan operation with the Addressable Shadow Protocol devices from Texas Instruments.
A System Test Language needs to support the operations required at the problem domain as well a provide for extensibility to new innovations required due to changes in the domain over time and must provide the ability to interface to sibling domains that must interoperate with the targeted domain of the language.
There are different domains even in the pure JTAG realm that require different capabilities from a language. For example, interconnect testing just requires a static and very deterministic flow of JTAG scan operations (thus, SVF). Programming devices with closed loop feedback on ad hoc programming sequences to get improved performance requires an extension of operations from that used for traditional test to be able to make decisions based on the results of a scan (thus, STAPL). But, STAPL is based on a deterministic programming model (see definition in the IEEE Std 1532 standard). What is needed for true concurrency of programming is the support of an adaptive programming model. This is the reason for 1532. Thus, the devices are programmed concurrently and also the decisions are made as to the flow of control at a device level and not at a predetermined scan level. Therefore, the scan operations change at run-time based on the feedback from the device. If you look at the open source implementations of 1532 support from the Lattice ispVM™ and the Altera STAPL player "support" of 1532 you will find they do nothing more than support a deterministic programming model with the advantage of programming multiple vendor devices concurrently but only based on the slowest device and not optimized for each device. This is still better than using the pure ad hoc approach for programming. The reason the implementations settle on a deterministic approach is because both implementations are based on a binary language design following the STAPL feature set. The Xilinx JDrive implementation performs an adaptive programming model, but does not program the devices concurrently. Thus, industry still does not have a truly IEEE Std 1532 supportive tool set.
Programming of devices with the JTAG interface has introduced the change in thinking of the use of IEEE Std 1149.1 to support dynamic vector operations (vectors selected based on register state) that is no longer a single deterministic flow of operations involved for a device in contrast to the static vectors generated for traditional test and represented by SVF.
With the advent of IEEE P1687, a role for the dynamic vector operations is extended to support the access, control, and monitoring of instrument registers embedded within devices. These activities no longer follow the traditional deterministic flow of control as demonstrated by interconnect testing, but instead open the need for managing the interface of data at a register level with real-time decision making based on the values observed in the registers. Further, the P1687 execution domain demands the need for coordination between instruments as well as concurrency of execution an decision making. Further, this domain reveals a need for supporting some form of reuse representation as there may be multiple instances of the same instrument located at various points in a board level scan chain.
There is another problem domain using the JTAG interface that also requires the use of dynamic vector operations, but the operations are determined in a much different fashion. This domain is processor emulation. IEEE P1149.7 is addressing many of the device level issues regarding the standardization of these emulation mechanisms. With emulation, the vectors are not determined by some algorithm but by the request of a software developer for information or setting specific values or changing the state of a processor. Therefore, entire JTAG sequence flows are neither repeatable nor deterministic. The traditional languages used for test are not appropriate for supporting the emulation domain. However, the primitives used in the test languages are still required by the emulation tooling. Therefore, we may conclude there is some level of commonality of all JTAG domains for a specific set of primitives in the language that must be supported for the entire JTAG problem domains to be supported.
Flow Control Perspective
The following sections attempt to enlighten the reader about the different aspects of flow control required by the broad System Test overall problem domain.
Flow Control within a TestStep
Specific operations applied to a Unit Under Test (UUT) to perform the operations representing functional aspects of a test (e.g., Interconnect test, Erase, Program, Verify) are applied as a set of operations as a whole on a single UUT. This set of operations is defined as a TestStep or Action of a sequence of operations performed during system test. This has been traditionally provided by SVF and STAPL languages. To support dynamic programming algorithms and adaptive programming algorithms there must be a level of flow control support in a test vector language to be able to provide the necessary decision process required to adapt to dynamically changing states of the UUT. This is quite different from the ability to select a different TestStep based on the result of another TestStep. Most of this capability is provided via STAPL.
Flow Control outside a TestStep
Once a TestStep has completed its application, the system needs to determine which TestStep needs to be applied next. This decision process is at a higher level in the software hierarchy then at a UUT control level and is outside the scope of a TestStep (set of test operations).
The STAPL language provides an overlap in this area as it allows for multiple TestStep facilities to be co-resident in the same STAPL file (e.g., ERASE, PROGRAM, VERIFY). A user of a STAPL program may request that the ERASE, PROGRAM and VERIFY operations take place as a single autonomous operation that is specified at run-time on the STAPL player’s command line. This is an implementation of the STAPL player and should not be confused with the application by the language itself. The advantage of STAPL is to be able to reuse common procedures required by all operations (e.g., IDCODE verification). Lucent Technologies (now Alcatel-Lucent) has demonstrated how they use their own Test Flow Control Language™ (TFCL™) to treat the functional aspect as the TestStep object for STAPL files and tune the TestStep object in using the appropriate command set to the player. TFCL may reuse the same STAPL file but implemented as separate TestStep objects where each TestStep embodies the unique procedure call (e.g., ERASE, PROGRAM, VERIFY) for that specific application target. Thus, STAPL can control the flow control within the UUT sequence of operations and TFCL takes control of the flow control between the TestSteps.
These solutions spaces work fine until you need to support the dynamic feedback applications where data needs to be observed from various levels of complexity within the UUT. A design may also require a reworking of the current chain configuration to obtain the values of registers needing to be controlled due to inefficient design choices made in the system architecture.
Language Attributes and Features
Scripting languages came into existence to solve the needs of specific problem domains. Many languages have been more flexible than others and have been able to be used outside of the domain they were designed for. One such language is Tool Control Language (TCL). Other scripting languages that have proven to be quite useful in their problem domains are: Python, Perl, and Ruby. General purpose languages that primarily target the web domain are Java and C#. What makes these languages so useful and yet flexible? They all have the attribute of extensibility – they all can have features added without modifying the language itself. Each of these languages allow for a programmer to define additional packages, modules, or libraries that may be used within the semantics and syntax of the language definition to provide additional features to the language. For example, TCL is able to define the use of a TCOM module that provides access to the Microsoft COM interface. Invocation of the COM methods is no different than calling existing TCL functions. Thus, the extended capability is provided without the need to change the way the language performs similar operations. Further, languages like Ruby with the Rails module extension included performs web related actions in a few lines of code that would take pages of code in Perl or Python – all with using existing semantics and syntax as defined in Ruby.
Java and C# are a bit different in that they provide lower level language features as well as high level features. They also provide some important object oriented features. They both provide the concept of object reflection – the ability for an object to describe itself programmatically. Object reflection becomes quite a powerful tool in combination with the extensibility of the language. It is possible within Java and C# to add a module that conforms to a specified interface definition that will itself describe how it works. It is this notion of reflection that becomes important in expanding the capabilities of a language while using the same primitive command. Both these languages support the concept of polymorphism – the ability to act like the general interface even though the object is a special type of object that implements a different behaviour than other objects of the same interface. With the reflection and polymorphism, code may be written specifically for the interface specification and behave in a specialized manner at run-time because of the features specified by itself as noted by the reflective interface description.
TFCL was written to take advantage of both extensibility and reflection. The difference is that the object definition (the reflective information) is not defined within the language but contained in the object data as persistent data of the object state upon initialization. Thus, the language always calls a TestStep interface using the APPLY statement no matter what type of TestStep is defined externally. It is at run-time that the reflective nature of the object is used to dynamically construct up the extension required for the object to run.
Dynamic and Static Information
Program Languages and Dynamic Descriptive Languages
Test Control Language
Device Programming Language
Static Languages and Persistent Data Representations
Test Vector Format
Locality of Information
Concurrency of Test
The following are place holders of information right now and captured thoughts that have not yet been formatted as white paper text!
As designs get larger and more complex, the time it takes to test and configure the system grows. It is imperative that test and configuration takes advantage of concurrency to reduce the overall time it takes to test and configure a system. Support for concurrency of operations is something that has to be designed into a product from day one.
Effects of Architecture
Test architectures within a system play a major role in the way a system may be tested concurrently. Traditional multi-drop JTAG is fundamentally prohibitive to concurrency because of the sharing of a single test bus resource by all UUTs in the system. Thus, alternative approaches like UUT JTAG self test are necessary to meet time constraints and to allow for asynchronous, parallel testing to take place. Depending on the self test architecture, a UUT may end up with reduced test coverage and/or diagnostic resolution implementing that solution. The advantage with UUT JTAG self test is that the test data resides on the UUT and is managed by the UUT itself. A trouble with the multi-drop architecture is the testing is performed by a resource outside the UUT. Thus, the tester has been required to maintain or obtain the appropriate test data for the targeted UUT. This becomes difficult as new designs are installed in the system. At ITC2005 I presented the case for what I call Plug ‘n Play Boundary-Scan using JTAG accessible configuration PROMs on each UUT where the test data would reside and use the multi-drop JTAG bus to obtain the data back to the off-UUT tester. To perform such operations the traditional test languages of SVF and STAPL were inadequate for the task of extracting the data and placing the data in the memory of the off-UUT tester while coordinating the use of this data for the test. However, the test primitives required to support SVF and STAPL were reusable to support this task. I needed to write a new language and TestStep for TFCL to accomplish this task. This example shows that STAPL is unable to extend into aspects necessary to support the infrastructure of test and configuration in the future as a cost effective and efficient architecture.
Concurrency of Devices
To better support shorter programming times of FPGAs a strategy of concurrent programming is required to meet system boot requirements where JTAG is used as the primary programming medium for these devices. If JTAG may be used for the power up programming of the FPGAs, a cost reduction of the board is possible by eliminating the configuration PROMs used by many designs today to obtain the level of concurrent configuration required by system boot requirements. As shown before, the tooling for concurrency is not optimal and does not support the entire feature set as prescribed by the IEEE Std 1532 standard. Thus, the full capability of concurrent programming is really being restricted to what current test vector languages may support – deterministic programming instead of adaptive programming. Further, the current test vector languages at best represent the functional state of the boundary-scan devices as an aggregate vector of bits loosing the true meaning behind the bit patterns. It would be ideal to represent the various functions of a device individually with specific vector variables like what are represented in each BSDL file (see my BTW2006 presentation cited above). This way, more adaptive programming could be accomplished at run-time because the individual device functionality would be represented individually. Then a vector segment of the aggregate vector would be able to be manipulated in pseudo isolation based on the functionality of the device behavior instead of force fitting the entire vector over time deterministically.
- Lihn, Hung-chi, Reusable, Low-cost, and Flexible Multidrop System JTAG Architecture, International Test Conference Proceedings, 2006.
- Van Treuren, Bradford G., Miranda, Jose M., Embedded Boundary-Scan Testing, Board Test Workshop Proceedings, 2002.