Today's economical cycles challenge the test program generation process for semiconductors with regard to productivity, time-to-market, increasing quality requirements and manufacturing robustness, while, at the same time, the complexity of the system-on-a-chip mixed-signal integrated circuits to be tested increases significantly. Furthermore, commercial challenges in combination with competitive advantage become an important factor, not only within semiconductor manufacturing, but also within test program development. This paper provides a review of these challenges, and how they might be addressed. We first give a short introduction and background on semiconductor testing and test development with the focus on mixed-signal and systems-on-chip. This is followed by current roadmaps and considerations for test program software development. Based on the highlighted strength and weaknesses of the reviewed approaches, the authors conclude with some recommendations to address these challenges by adopting software engineering methods for the test program development process.

Challenges for Semiconductor Test Engineering: A Review Paper

This year, new products have been introduced onto a Royal Air Force (RAF) test system, which provide an integrated IEEE 1641 development and run-time system. The program involved the integration of Commercial of the Shelf (COTS) products to provide a facility to enable the creation of a TPS using 1641 signal definitions, through to the running of the test program using established instruments and driver software. This paper discusses the process involved in achieving the objectives from the point of view of the TPS developer and integrator, and will cover the complete process, from requirements capture, via TPS integration, to program operation and results verification. The paper will also outline the lessons learned and the resulting feedback to the COTS product developers and 1641 working groups.

http://www.spherea-technology.co.uk/SphereaTechnology/Knowledge/ImplementingIEEE1641-ACompleteSystem.pdf

Implementing IEEE 1641 - using a complete system

The UK MOD has closely monitored and supported the development of IEEE Std 1641?-2004 [3] through its Standards Liaison Group for Automatic Test and Standards Technical Working Group for Automatic Test, which meet regularly with UK industry. Feedback from those open meetings is provided as technical input directly to IEEE Standards Coordinating Committee 20 (SCC20). IEEE 1641 and related test standards are key in the pan MOD Policy for ATS and the MOD continues to sponsor trial use of the Standard through a number of demonstrator projects. These projects encourage industry participation and lead to feedback that is fed into the aforementioned working groups to create proposals which enhance 1641 and related standards. This paper discusses the main features of the UK MOD Policy for ATS. It explains the significance of 1641 to the Policy and the work undertaken by UK MOD in promoting the standard to UK Industry by describing the function of the working groups and Industrial Liaison Groups. A summary is provided of the demonstrator projects undertaken on behalf of the MOD, their outcome and the proposals in store for future work.

State of IEEE 1641 standard, applications and UK MOD policy

This paper presents the outcome of a UK MoD sponsored development effort to provide a suite of source code that will be made available to contractors employed in the provision of test system software to the MoD and coalition partners. The primary purpose of this ‘open source software’ is to provide a working test system software framework that meets the requirements of the MoD's DEFSTAN 66-31 [1] (Open Systems Architecture); in particular, the use of IEEE 1641 [2] and ATML [3].

An open source software framework for the implementation of an open systems architecture, run-time system

The application of IEEE Std. 1641 to Bus testing has been (and continues to be) a major hurdle to its full adoption on deployed ATE systems. The IEEE Std 1641-2010 standard had several new primitives added for support of both Digital and Bus testing. These digital changes [8] focused primarily on the digital aspects usage, and although it added BSCs to support bus communication and protocols, the report did not provide detailed and definitive examples. There is now a growing requirement to create a set of use cases and recommended practices to support the bus testing domain in 1641, for typical UUT buses, e.g. RS232, 1553, TCP/IP protocols including HTTP, CAN Buses, J1939. The paper considers the commonly used bus implementations and describes how to best model buses from their physical layer through to their message or application layer and associated protocols. The paper identifies the relative merits of different methods of bus testing and provides guidance on the level required and shortcuts that can practically be taken when using standard bus domains. This will be examined through a series of examples and consider both using buses to communicate messages/data to a UUT and how `error testing' can be performed to test that the UUT is correctly behaving when a bus message or protocol is corrupt or out of specification. The paper aims to identify if the existing IEEE 1641 and ATML test standards have the depth and required flexibility to meet the full range of bus testing requirements of our modern systems.

Bus testing in a modern era

The IEEE 1641 STD standard, provides a new way to define test requirements independently of the language and test station platform. Initiatives to put the standard into practice to discover its applicability to industry have been taken. The present study is concerned with this initiative. The objective is to analyze the development effort required by a TPS engineer to produce a Test Program from scratch using only the elements provided by the IEEE 1641 Standard. The study covers the description of test requirements based on the IEEE 1641 constructs to its implementation and execution in a real ATE (the SAMe ATE by Indra Sistemas). The development of a test program applying this standard implies the definition of a new methodology compared to the one traditionally used in the organization. The implementation of the test program brings out the issue of which programming environment to use, and the tools to support the process. The execution of the test program suggests the development of a 1641 compliant run-time system (RTS), so that the test program generated directly uses the elements defined by the standard (BSC's and TSF's) to implement the test requirements.

J.M.G. Pascual

Papers

A case study: Developing a complete test program using IEEE 1641