Browse Prior Art Database

Method of deterministically testing IPs supporting Multi-phase Asynchronous handshake protocol

IP.com Disclosure Number: IPCOM000234842D
Publication Date: 2014-Feb-10
Document File: 4 page(s) / 1M

Publishing Venue

The IP.com Prior Art Database

Abstract

Method of testing asynchronous interface is disclosed. The patterns generated for Tester must be cycle accurate else it might show false yield loss on production program. This document describes a generic solution to deterministically test ‘Multi-phase’ ‘asynchronous’ handshake protocol. The interface used here is eSDHC.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 40% of the total text.

 

Method of deterministically testing IPs supporting Multi-phase Asynchronous handshake protocol

Abstract— Method of testing asynchronous interface is disclosed. The patterns generated for Tester must be cycle accurate else it might show false yield loss on production program. This document describes a generic solution to deterministically test ‘Multi-phase’ ‘asynchronous’ handshake protocol. The interface used here is eSDHC.

I.     BACKGROUND

T

his disclosure generally relates to the field of Automatic Test Equipment (ATE) and pattern stability on Tester across Process, Voltage, Temperature (PVT) and, more particularly, to the generation of cycle accurate patterns to test multi-phase, asynchronous interfaces.

Figure 1 is a basic block diagram of eSDHC.  It has different sub-blocks such as register bank, clock and reset control block, SD interface and control unit, and system interface and control unit. As shown in diagram it can be seen that there are two async-fifos present in the SD interface and control unit block. These FIFOs operate in two different domains, one in ‘IPG_CLK’ clock and the other in ‘SD_CLK’ clock domain. These two clocks are totally asynchronous to each other. These are the two blocks where indeterminism during read/write transactions can occur on the tester across PVT.

Figure 1: Block Diagram of eSDHC

To understand how indeterminism could occur one needs to understand a basic eSDHC transaction and then the effect of indeterminism on the above transaction.  For reference, a write transaction is explained.

A.     eSDHC Write transaction:

    Figure 2represents the sequence of SD Write data transaction in Functional Mode.

Figure 2: eSDHC Write Transaction

1.  First eSDHC module sends the command on SD_CMD signal which contains the command index and the address of the data transfer

2.  Then, card respond back on SD_CMD with valid response.

3.  After receiving the response, eSDHC sends out the data block of size 512 bytes along with its CRC on SD_DAT bus.

4.  On receiving the data block, SD card sends it’s acknowledgement in CRC status (on SD_DAT[0] pin).

5.  If it’s a multi-block transfer then eSDHC sends the next block of data and process continues till all the blocks are sent to SD card.

It can be seen that the write transaction is divided into multiple phases like CMD phase and subsequent DATA phases for each block transfer.

B.     Indeterminism due to Async-FIFO

Following Figure 3 shows the shifting of FIFO output across PVT.

Figure 3: Indeterminism due to Async FIFO

1.  IPG_CLK domain is denoted in blue and SD_CLK domain in red.

2.  Here pushing (or writing) of data happens on IPG_CLK while popping (or reading) happens on SD_CLK.

3.  Since both of these clocks are asynchronous it results in in-determinism of one SD_CLK (across PVT) at the FIFO output.

4.  Figure 3signifies the above point for two different input transactions across PVT.

C.     Effect of indeterminism on SD write transaction

Figure 4 depicts the ef...