Bridging the Gap: Pre to Post Silicon Functional Validation

Heena Mankad (ASIC Engineer, eInfochips Ltd)

Abstract:

Post Silicon Validation is a vital phase of verification that deals with verification after the real silicon is in place. This paper revolves round the functional testing aspect of this phase. It starts with the basic theory about how a simulation output is converted to a different format so that the tester can understand it.

It explains the enhancement needed to the existing system simulation environment along with the tester limitations to support the post silicon testing activity and a better approach for the test scenarios.

I. INTRODUCTION:

We all know that a design undergoes verification at each phase of its development. Many different and efficient methodologies are available for pre silicon verification. But, post silicon validation has always remained a lesser known topic; but now an emerging research topic. During the pre-silicon process, engineers test devices in a virtual environment with sophisticated simulation and emulation tools. In contrast, post-silicon validation tests occur on actual devices running at-speed in commercial, real-world system boards. Post-silicon validation is used to detect and fix bugs in integrated circuits and systems after manufacture.

II. TYPES OF POST SILICON TESTING:

There are three basic types of tests that a device needs.

Per Pin Testing:

The focus is on testing the circuitry local to a particular device pin. Examples include Continuity Test, Leakage Test, Input/output impedance Test.

Parametric Testing:

This usually refers to verification of certain "parametric" values of the device. These are device values specified and guaranteed by the device manufacturer. Examples include icc test, SNR performance test, Gain test.

Functional Testing:

This is the most comprehensive testing and tries to simulate the device functionality in natural operating environment as it would exist in final product. It has most part of device active simultaneously.

III. BASICS:

While simulating the design, we have the virtual environment that generates various stimuli. DUT is exposed to the stimulus through the test bench that binds the environment signals to DUT ports. For post silicon validation, Tester provides this virtual environment that generates and drives the stimulus into the DUT ports. For response checking, the simulation environment provides various mechanisms like scoreboards, checkers and assertions. For post silicon validation, Tester provides inbuilt mechanism to sample DUT output ports and compare it against the expectation and declare a pass or fail.

Input for post silicon validation is a file that is generated through simulation. In system environment, the scenario is simulated and all the toggling at the DUT ports are captured in a particular format. This format used to be VCD (Value Change Dump). VCD doesn’t directly provide the information regarding the direction for inout ports. It needs to be supported by internal enable signal value to detect the direction. Hence, extended VCD (EVCD) is used now which directly provides the direction information for inout ports. This EVCD file captures the information for all DUT port’s initial state, transitions, value at each transition, strength information and the direction information.

The tester cannot understand EVCD. Tester has its own format using which it determines what to drive, when to drive and where to drive. Similarly, for output ports, it determines where to sample, when to sample and what to expect using its own format. Hence, the EVCD needs to be converted to format that Tester understands. These are drive/receive formats. They along with additional information; specify information to drive/sample/expect for each signal for each timeslot. Each timeslot is referred as a Vector.

Imagine you want to draw a pattern. The first thing you would do is divide it into number of smaller but similar size timeslots. And then draw each timeslot one by one. Similarly, expect value on port for each timeslot. Tester uses similar approach. Each single timeslot is a vector and provides all the information needed to drive, sample and expect for a DUT port.

In the above figure, for vector 1, drive low edge will fire with no offset. This will drive the corresponding pin low. For vector 2, drive high edge will fire at the specified offset. Similarly, for each vector, appropriate edge fires to drive the pattern. If there is no change in the signal value for a vector, there is no need to fire an edge. Number of time offsets allowed per port is limited by the tester specifications. Hence, the patterns must be related to EVCD cycling clock to keep number of different offsets minimum. For output ports, an output strobe is fired at appropriate offset from the starting of each vector to sample the output voltage at the port. The sampled value is expected against the original value from the EVCD.

IV. CHANGES TO THE SIMULATION ENVIRONMENT:

The pre silicon verification is mostly done with bottom-top approach. Block/Unit level verification is done first with moving towards the full chip and system level verification. System level verification environment is leveraged for the post silicon validation. Typical System Environment changes needed are mentioned below:

Bypass PLLs:

If possible, on chip PLLs can be altogether bypassed for functional testing. This will drastically reduce the initialization time taken for each PLL, hence, saving the overall tester time. If PLLs cannot be altogether bypassed, it is better to provide all the reference clocks from test bench directly and bypass the internal generation of reference clocks. The intention of test here is to validate the logical functionality. There will be a separate test for the PLLs.

Remove any fast simulation aid:

To aid faster simulation, we employ various techniques like waiting for fewer numbers of cycles than that specified by the specifications. We would need to wait for cycles as specified by specification during various bringup tasks for a real chip validation. To aid faster simulation, we occasionally do internal forcing of a signal. This is not possible in real world. Hence, environment needs to be updated to generate same condition by driving the top DUT ports.

Optimize the bringup routines:

The initialization and bringup routines at system level runs too long. To reduce the number of cycles consumed for this, remove unnecessary register read and optimize the routines for parallel initialization wherever possible.

Change the operating clocks:

SoC has various integrated IPs that work at different clocks. For example, ddr, axi, etc. These clocks are asynchronous and neither related to each other nor the system clock. This imposes a challenge for deciding EVCD cycling clock and vector generation. It is needed to decide optimum frequency for each clock so that they can be made integral multiple of each other and need fewer drive/receive formats and offsets from the vector start point.

No hardcoded delays:

Hardcoded delays are used; unintentionally but always. These delays not only imposes problem for vector generation but can also create setup problems and move the real output in next clock cycle. These delays need to be replaced with delays in terms of clock.

V. TESTS FOR FUNCTIONAL TESTING:

Similar to pre silicon verification, start with a sanity test. Vector generation and testing for this will be an iterative task but will help to sort out all major issues. Identify scenarios that have multiple interfaces and blocks active simultaneously. Each scenario should be individually created and verified in simulation. Have such functional scenarios execute back to back in same test so that the bringup is not needed to be re-executed. This merged test will be a master test that will provide considerable amount of saving in terms of tester time.

This complete task relies on the fact that the design behaviour in simulation and on hardware remains the same. Hence, we compare both the outputs. For all the scenarios, make sure not to have any configuration that gives unpredictable or random values at the output.

Another important aspect here is to have proper debug points within the test flow. These debug points should reflect the design’s current state on some output port. This helps to isolate the problem to a particular area if any failure occurs while testing. The simulation log message with proper display messages along with simulation time is also a good practice and will help to debug a failure.

Specify the output ports that are not needed to be expected for a particular scenario. As an example; majority of output ports should be don’t care during the bringup phase.

It is a big question to decide whether to go for RTL simulation or Gate Level Simulation with back annotated delays for the testing. Well, the answer depends on how close the gate level netlist is to the RTL. But, it is good to start with RTL simulation and move to GLS later if more debugging is required for failures on the tester.

Once the EVCD is delivered and test engineer generates the vectors from it, it is important to prove that the resulting ATE pattern is same as one captured in the EVCD.

VI. CONCLUSION:

With simple but careful understanding and identification of scenarios and environment updates for post silicon validation, generation of vectors from EVCD and real testing using testers will help to save some million dollars consumed by this vital verification phase.

VII. REFERENCES:

VCD Pattern Generation and Conversion Guidelines, Test Spectrum Inc

Test Vector Guidelines, Actel

Index Terms: