Power-Aware Test Vector Porting For Production ATE

Ensuring that test patterns do not place the SoC in danger of thermal runaway and damage.

popularity

Power management in contemporary system-on-chip (SoC) designs is almost unimaginably complex. Processors and other chip cores turn on and off as needed. Advanced features such as dynamic voltage and frequency scaling (DVFS) can adjust to changing conditions and incrementally adjust power and performance on the fly. Power management starts from the lowest hardware level of transistor structures and extends to the highest levels of software. For example, the operating system might limit processor parallelism to reduce power or turn off a floating-point unit not needed by the currently running application.

Power management is clearly important in real-world use of battery-operated devices, and even in larger systems to keep data center costs under control and to meet the requirements of green laws. It is also important because many SoCs cannot operate with all cores running at full speed simultaneously. Thermal runaway and device damage is entirely possible if too much power is being consumed. Careful monitoring of power consumption and management of chip operation is required to avoid catastrophe.

The same problem exists for the SoC in a chip tester on the manufacturing floor, but there it’s even worse. The test patterns run on the automatic test equipment (ATE) are produced by automatic test generation (ATPG) tools, which historically have had no knowledge of power requirements or limitations. Attempting to test all cores at the same time can literally melt the chip on the tester. It is vital that the test patterns, especially those run at speed, not place the SoC in danger in a way that power management software would never allow in mission mode.

The test engineers running the ATPG tools must have the capability to control how much activity occurs simultaneously on the tester. For example, only half of the processor cores might be tested at one time, with the other half tested in another set of patterns run serially. However, to make these decisions, the engineers need to know when they are in trouble. They need a way for accurate prediction of power consumption during the ATPG tests. They need to know the peak power consumed so, if it is too high, they can adjust their test strategy to serialize some of the patterns. This requires five key capabilities:

  • Highly accurate prediction of ATPG test power consumption at the core level
  • Automatic porting of ATPG test patterns to the full SoC
  • Accurate and automatic calculation of full-chip peak power
  • Support for advanced chip fabric technologies
  • Signoff-quality static and dynamic IR drop / instantaneous voltage drop (IVD) analysis

Running ATPG at the core level is efficient and effective, yielding high coverage of the faults that model possible silicon faults. In addition to generating the core test patterns in the Standard Test Interface Language (STIL) format, the ATPG tool must generate a power report that can be used to calculate the peak power for the full SoC. In the past, test engineers usually ran ATPG on the full SoC design because it was a tedious and error-prone effort to port the core-level STIL files to the chip level to run on ATE in production. This was highly inefficient, and the process had to be repeated for the whole chip anytime any core changed.

A much more modern and automated approach is required. At the heart of the flow, some sort of test tool must be able to port all the core STIL files to a full-chip STIL file, and to combine the core power reports to calculate full-chip peak power. At this point, the test engineers know whether the test patterns exceed their power budget and can adjust their test strategy as needed to prevent problems on the ATE. As noted earlier, their most likely solution is to serialize some of the patterns so that only a subset of the SoC is active on the tester at any given time.

Once the full-chip STIL file is available, it can be run in a traditional logic simulator to generate a switching activity file in the Fast Signal Database (FSDB) format. This enables the signoff team to analyze dynamic IR drop with a high degree of accuracy. The result is an automated and robust design and test flow. Power-aware ATPG and power-aware test pattern porting shrink SoC project schedules by finding power budget issues early and enabling more accurate signoff analysis.

The Synopsys power-aware test solution follows this flow. Synopsys PrimePower sets up Synopsys TestMAX ATPG to generate the power report and STIL file for each core in the SoC. Synopsys TestMAX Manager ports these files to a chip-level STIL file and calculates peak power. Once an acceptable set of patterns is available, they are simulated in Synopsys VCS, and Synopsys PrimePower performs IR drop analysis. All the components of this flow interact seamlessly to maximize both accuracy and efficiency,

This power porting flow augments the capabilities of streaming fabric seamlessly, enabling independence of core testing while tracking SoC power. Streaming fabric interconnects the cores and other functional blocks to the top-level chip I/O pins in a flexible and configurable manner. It has many benefits, including addressing pin alignment, easing timing closure, improving bandwidth utilization, and reducing test time by up to 5x. Shorter tests mean more parallel activity within the SoC, with multiple cores toggling simultaneously with independent shift and captures. The ATPG power estimation methodology ensures that the full ATE test remains within the power budget.

The fact that SoC power budgets don’t allow all cores to run at full speed at the same time is a challenge when preparing for ATE. Test engineers need a flow that automates the creation of power-aware ATPG tests at the core level as well as seamless porting to the SoC level. The Synopsys solution addresses these challenges. Engineers can be sure that they are heading to the test floor with patterns that won’t destroy those precious first chips back from the foundry or compromise yield during volume production. Using this flow is mandatory for every advanced SoC project.



Leave a Reply


(Note: This name will be displayed publicly)