Analyzing the power implications of MBIST usage

One important design-for-test (DFT) structure in systems-on-chip (SoC) circuits is the memory built-in self-test (MBIST) block. Unlike tests stimulated by externally applied test vectors, MBIST blocks algorithmically run through a test sequence based on a starting seed. No external signals are required.

A given SoC may have multiple such MBIST blocks and test-time efficiency might suggest running them all in parallel. Too many MBIST blocks running together, however, may exceed the chip’s power budget. Power analysis performed before the devices go into full production can help test engineers understand how many blocks can be tested in parallel while staying within the power envelope.

Running this analysis can theoretically be done using simulation at the register transfer level (RTL), but simulating at the more accurate gate level results in the activity files becoming too large. In addition, the time it takes to run the simulations at the gate or RTL level can take weeks, which is far too long for an aggressive time-to-market target.

Using simulation, only a subset of the test activity can be analyzed. As there is no way to ensure that such a subset would contain any or all power spikes, it is impossible to select a suitable subset. As a result, such analysis significantly lowers expectations in the results.

Emulation, by contrast, can run the same analysis several orders of magnitude faster than simulation, bringing the analysis time into a range consistent with new product release schedules that match or eclipse that of competitors. The Veloce™ DFT and Veloce Power apps can be used to capture the activity and understand the power implications of that activity.

The goals for using emulation to analyze MBIST power include:

• Accurate power estimation for MBIST patterns at the gate level

• Fast runtime (hours rather than days or weeks)

• The ability to detect power spikes across the entire MBIST test

• Determining how many MBIST controllers can be safely run in parallel

• Comparing power in MBIST mode with functional mode

A methodology collaboration with Arm

Siemens EDA and Arm® recently collaborated on
a methodology to analyze the power implications
of MBIST on an Arm test chip. The intent was to
observe the effects of MBIST on maximum power, low power, and instantaneous power dI/dt internal to the chip.

This exercise leveraged both the Veloce DFT and Veloce Power apps. The Veloce DFT app generates an output of all the internal activity; in this case,
at the gate level. The app is driven by the industry-standard Standard Test Interface Language
(STIL) and generates industry-standard output files.

The emulator exercises the MBIST block in the same way that it would function during production at
final test on automated test equipment (ATE). All MBIST blocks can be exercised together, delivering the resulting activity files for analysis by the Veloce Power app.

The Veloce Power app takes those files and generates waveforms, power profiles and heat maps that show when the power spikes above tolerable limits and which blocks are most responsible for that high power. This allows test and design engineers to
adjust the test plan in order to ensure that the test power is acceptable.

The Arm test chip

The SoC being investigated features Arm’s first server-grade CPU, the Neoverse N1. This processor has a new microarchitecture that includes instruction-cache coherency, a 1 MB private level-2 cache, and a direct connection to the CMN-600 mesh
network. It leverages the full Arm version 8.2 architecture with statistical profiling extensions
and a 48-bit physical address space.

The chip’s DFT infrastructure includes three Arm MBIST interfaces:

• One for the level-2 cache and load store arrays
• Another for the instruction-fetch and MMU arrays
• A third for the embedded logic analyzer RAM

The MBIST blocks were inserted using the
Siemens EDA Tessent™ MBIST shared-bus feature.

Although Arm is an IP company, it still needs to
build test chips to prove out the IP in real silicon and provide partners with a platform for early software development. The test chip we analyzed comprises
a full complement of DFT circuitry, including:

• MBIST
• IJTAG test control
• Scan compression
• On-chip clock controllers (OCCs) for at-speed
  scan
• Hierarchical test isolation
• Scan/memory dump for functional debug
• Boundary scan