Real-World Applications

cancel
Showing results for 
Search instead for 
Did you mean: 

Error Rate Measurement Using a Measurement Abstraction Layer (MAL) in NI LabVIEW

Company: FH Joanneum
Author(s): Gerald Ferner
NI Product(s) Used: NI LabVIEW
Industry: Semiconductor

The Challenge

 

Post-silicon validation of integrated circuits is highly automated with increasing complexity. Although measurement methods are often similar for various product families, different implementations and measurement setups are used. This diversity poses a challenge for the measurement’s reusability and modularity of automated measuring processes.

 

The Solution

 

An object-oriented concept in LabVIEW, called Measurement Abstraction Layer (MAL), decouples the actual measurement from the measurement setup, leading to a device independent measurement implementation. This modular approach leads to significant time savings when integrating existing, as well as creating new measurements.

 

Introduction

 

Quality assurance and reliability are key considerations in post silicon validation to determine and eliminate issues of integrated circuits after manufacture [2]. There are three areas playing a key role in automated measurements:

  • instrument communication
  • measurements
  • result generation and data processing

 All of the above, expect for the last part are addressed of this paper. Before discussing the challenges, it is worth understanding the meaning of the terms measurement, automation and abstraction. Pedhazur et al. (1991) defines a measurement as the assignment of several characteristics of an object or event, which can be compared with other objects or events. However, this general definition does not consider the ability to automate this process including the measurement reliability and validity. Furthermore, this definition does not consider any measurement context.

 

In the context of post silicon validation, electrical measurements like currents, voltages or power levels are taken. Next, it is important to deliver as much parametric data as possible to prove proper product behavior for specified operating conditions. It is not possible to cover all parameters in manual measurements. Therefore, automation plays a key role. In automation, the reliability of the software and the instruments paired with validity is very important. This turns the rather simple task of taking measurements into a complex and challenging exercise of multiple disciplines.

Automation or automatic control is the technology to perform a process or procedure without human assistance. Therefore, robust setups and a scalable software architecture are needed. Furthermore, the increased complexity of semiconductor products leads to an increased measurement complexity [1]. The results delivered during post silicon validation are only as good as the automation concept used for these measurements. [2]

 

Although the measurement methodology is quite similar for different product families and different instrumentation, various different software tools and architectures are used, in order to achieve the same goal. This variety of implementations presents a challenge regarding reusability and modularity of automated measurements. In order to keep the measurements adoptable, scalable, maintainable and reusable, abstraction layers for instrumentation (HAL) as well as for measurement (MAL) are required [3].

 

Another challenge is the usage of different communication protocols and interfaces required for device under test communication (e.g.: SPI, I2C, JTAG). In order to interact with the device under test, standard protocols as well as customized internal communication standards need to be supported. Therefore, custom communication devices (hardware) with internally developed (low tested) software (DLL, .NET) exist. There is no standard architecture nor software layer, that defines how device under test communication should be handled across different vendors. In addition, there are several custom communication devices, controlled by DLLs and third-party APIs. Unfortunately these devices are not always very reliable and useful for automation.

 

All these considerations lead to the simplified abstraction concept described in figure 1. The aim of this paper is to demonstrate a proof of concept about methodologies for creating a unification of measurements X, Y and Z in the automation layer, for obtaining high reusability for another device under test. Furthermore, the communication between the automation and the device under test should be simplified and standardized through a communication abstraction layer, to reach independency of the platform being used. The hardware abstraction layer part will not be part of this discussion, as it has already been introduced several years ago for controlling instruments [4].

 

Figure 1. Abstraction ConceptFigure 1. Abstraction Concept

 

Application Description

 

To illustrate the need of a measurement abstraction layer (MAL), the error rate measurement is used. Although the measurement flow is very similar for several types of receivers, there are instrument dependent implementations that coexist. Figure 2 shows the simplified flow, as well as the basic steps of an error rate measurement. First, stimulus data needs to be generated, which is transferred to an instrument capable of replaying this format. During the replay step, this data is transmitted to the device under test. After transmission, the data is acquired from the device under test by reading internal memory pages. Next, the generated and acquired data need to be compared, whereas the number of mismatches is converted into an error rate and returned for the next stage.

Figure 2. Simplified Flow of an Error Rate MeasurementFigure 2. Simplified Flow of an Error Rate Measurement

 

 

The focus of this proof of concept is extensibility and reusability. Therefore, an object-oriented concept based on the factory pattern is used. Figure 3 illustrates the three different layers included in this concept: framework, measurement and implementation. Following the illustration left to right exposes the layers from generic to specific.

 

The first layer is the framework. The framework contains three abstract classes with basic methods and properties: Measurement, Step and Data. The Measurement class contains references to certain Steps consisting of three methods (Pre, Do and Post), which are sequentially executed. This reduces the complexity of a Step implementation and provides pre- and post-processing of data used inside the Step. All of these three methods could be skipped if necessary. In order to transfer and store data, the Step class contains a Data class. 

 

Figure 3. Measurement Abstraction ConceptFigure 3. Measurement Abstraction Concept

 

 

The second layer is composed of explicit classes for an error rate measurement, derived from the framework classes. The error rate measurement class, derived from the Measurement class represents an interface and contains references to the previous described measurement steps, which are derived from the Step class. To launch the sequential execution of the Steps referenced, an explicit method is required, as well as private data to store the error rate.

 

The third layer, the implementation, is the most specific part of the concept. The classes defined here are concrete implementations of a measurement for a certain product. In other words, only the Steps that are different from the generic flow are overwritten and modified and the execution flow stays the same. Hence, this concept allows to implement an infinite number of new measurements, or parts of it, without reinventing the wheel all the time.

 

The implementation of this MAL concept in LabVIEW consists of four parts: Configuration, Start, (repeated) Execution and Stop. The necessary information about the measurement is extracted from a configuration file, to create a specific measurement object with all required steps. The execution order is already defined within the measurement configuration. To implement a Model-View-Controller architecture [5], the measurement and user interfaces are defined as actors using the Actor Framework [6]. Therefore, an abstract controller with a priorly configured user interface and measurement references is used.

 

During the execution phase, the real measurement is (repeatedly) executed. The measurement Steps are enqueued into a buffer and afterwards sequentially dequeued and executed. Therefore, the implementation of this step is invoked inside a state machine by using the standard concepts of object oriented programming: polymorphism and overriding. The mentioned state machine uses the information (data) from the measurement class or data from a previous step. With this information, the state machine is executing the Pre, Do and Post methods of the current measurement step in the buffer. Afterwards the New Data are returned as Previous Data to the measurement class and distributed to the subscribed user interface (see figure 4). After completion or cancellation of the measurement, all open processes (actors) are terminated and open references are released.Figure 4. Simplified Execution of a StepFigure 4. Simplified Execution of a Step

 

 

 

Conclusion

 

This proof of concept demonstrates possible ways to deal with the increasing complexity of measurements in post silicon validation. A possible implementation of a measurement abstraction layer was discussed, which allows the decoupling of the measurement flow from the real implementation. An object-oriented concept in LabVIEW was used to support the reusability of existing functions within an abstract framework. Each step is configurable and skippable to keep the execution flow as flexible and adoptable as possible. Furthermore, parts of the actor framework were used to implement a model-view-controller pattern to increase the modularity and decouple the user interface from the measurement process itself. The modular approach leads to significant time savings when integrating existing, as well as creating new measurements, but its usage requires good LabVIEW skills.

 

 

References

 

[1]   Rominger W. (2016), A modular method for post silicon validation, Virtuelle Instrument in der Praxis 2016, Jamal R. & Heinze R. (Hrsg.)

[2]   S. Mitra, S. Seshia, and N. Nicolici, “Post-silicon validation opportunities,challenges, and recent advances,” in Design Automation Conference, June 2010, pp. 12–17.

[3]   G. Gothing, “Hardware and Measurement Abstraction Layers”, http://www.ni.com/white-paper/53226/en/, July 2016

[4]   “Hardware Abstraction Layers Using LabVIEW Object-Oriented Programming”, https://decibel.ni.com/content/docs/DOC-11819, June 2010

[5]   “Model-View-Controller Design Pattern (DSC Module)”, http://zone.ni.com/reference/en-XX/help/371618H-01/lvdscconcepts/mvc_design/, June 2012

[6]   “Software Engineering Using the Actor Framework and Object-Oriented Programming to Solve Big Problems”, http://www.ni.com/newsletter/51856/en/, November 2013

 

 

Author Contact Details

 

Author

Name: Gerald Ferner

E-mail: gerald.ferner@edu.fh-joanneum.at

 

Co-Author

Name: Wolfgang Rominger

E-mail: wolfgang.rominger@nxp.com

Comments
Joris_D.
Member
Member
on

Thank you Gerald for taking the time to document this application.

 

 

Kind Regards,

Joris Donders
National Instruments
EMEIA GTM Lead for Semiconductor
www.ni.com/semiconductor
Contributors