Logic Design Blogs

Hello Encounter Test Users,

In this blog, I would like to introduce a few knowledge artifacts that will provide an easy way for you to learn about and stay productive with this product, technology, and methodology. In addition, this will also help to efficiently debug problems that you may encounter in the flows discussed below.

Rapid Adoption Kits (RAKs), as you all know, provide a simple way to demonstrate how you can use Cadence tools in your design flows to improve productivity and maximize the benefits of your tools.

Below are a few important RAKs and app notes that were published recently on the support portal https://support.cadence.com/, which might be of interest to you!

1. RAK - Encounter Test: Library Validation

This RAK includes a look at the standard library cell model generation and its validation for usage with Encounter Test. It starts with the conversion of several library formats (SPICE, verilog, and .lib) to create a structurally accurate test model for Encounter Test using Encounter Conformal technology. Each of the formats has varying levels of abstraction from the physical structure discussed in Lab1 of this RAK. These models are then checked for any conflicts. Once these conflicts are resolved, the models are then distributed as binary models, thereby guaranteeing proper import into Encounter Test for that technology. The models are then run through ATPG and simulated using NC-Sim for coverage and pattern matching.

With this RAK, you will be able to:

• Learn about the structurally accurate modeling of ASIC library cells
• Learn about the benefits and implications of abstraction of library models
• Understand the conversion of SPICE/simulation/Liberty model of library cells to Encounter Test compliant structural Verilog model
• Understand the benefits of usage of pre-compiled models with Encounter Test

2. RAK - Encounter Test: Diagnostics

This kit includes Encounter Test Diagnostics Rapid Adoption Kit with demo design. It demonstrates how Encounter Test ATPG customers can step through the diagnostics flow using Encounter diagnostics. Also contains flows implementing volume and physical diagnostics.

With this RAK you will be able to:

• Quickly and accurately identify the root cause of ester failures caused by logic and scan chain defects
• Take advantage of improved precision, as physically possible bridges and subnet opens are extracted and diagnosed
• Quickly identify yield limiters across a large number of failing chips via the volume diagnostics solution
• Perform deep-dive analysis on suspect locations using Encounter Test schematic and Virtuoso layout viewer

3. App note - Creating Chip Pad Pattern Failure Data from Tester Cycle Failure Log

The purpose of the application note is to provide a methodology to convert cycle-based failure data into the Encounter diagnostics chip pad pattern (CPP) format. This application note highlights the conversion steps required when using either natively generated Encounter Test ATPG patterns or STIL ATPG patterns read in for diagnostic purposes.

The CPP format is an ASCII representation of failures. A CPP format file contains a one-line entry for each failure. Each failure specification consists of the following:

• The die on which the miscompare occurred
  • For failure analysis this is not necessary. Include this information if you are doing volume failure analysis over multiple die to identify process trends or suspect cell types or structures.

• The test pattern and scan chain bit position where the miscompare occurs
  • The test pattern is also referred to as our “odometer”. In CPP format the bit position keyword is “offset”. 
  • Test translation software almost never carry the Encounter Test pattern numbers forward. If the pattern number is not reported in the failure log, then failure diagnostic requires two pieces of information.
  • Involves information about whether the test translation software added (prepended) tester cycles to the Encounter Test patterns set and the name of the package pin that was measured. 
  • Involves the logic value that was measured at the failing package pin

Example CPP data:

Chip Die1 pad scanout7 pattern 2 offset 557 value 1
Chip Die1 pad scanout3 pattern 2 offset 702 value 0
Chip Die1 pad dout[1] pattern 3 offset -1 value 0

The keywords Chip, pad, pattern, offset, and value are required names. The name Die1 is user-specified. The pad name is either the scan-out pin or a primary output pin. The offsets for failures captured during the scan unload start at 0 and represent the number of cycles to get to the failing bit position in the chain. The offset is -1 for miscompares that occur during a measuring of the primary output pins (non-scan unload).

The conversion of cycle-based failure data into a format that is compatible with Encounter Test and diagnostics is a necessary step to enable diagnostic processing. It is important that the failure data be precisely converted to ensure accurate and reliable diagnostics results. A hands-on example is available with the Encounter Test: Diagnostics RAK at https://support.cadence.com/

Happy Learning!
Mukesh Jaiswal