Speakers assess SoC test methods

Citing a hypothetical example, Bergeron said it would take 10 verification engineers more than a year to write 1,000 test cases, spending an average of three days on each. "That's intolerable," said Bergero n, who runs the Verification Guild Web site. "The only way to change that is to have test cases written faster."

The process can be accelerated in two ways, he said: by verification reuse, and better verification methodology. The challenges of verification reuse are many, he said: multiple languages are used; a plethora of approaches are available, none standard; there is no coding style. All this bodes ill for verification reuse, Bergeron said.

On the other hand, verification itself is becoming more of a science than an art, and "people are starting to apply it in the same manner across the board," he said.

"SoCs require encapsulation-level controls. And test case writing productivity needs to be increased via efficient higher-level languages. In fact, in most companies HDLs have been abandoned in favor of C and its derivatives," Bergeron said.

Advocating an approach of using random test cases for an SoC, Bergero n said the tradeoff is that it takes longer for the first test case to execute, but that all test cases are completed much faster. "In the direct approach you get there eventually, but the time it takes is intolerable," he said.

Testing for 100 percent should not be a priority, Bergeron said, but a verification engineer needs to understand why the untested 2 or 3 percent is not critical to test.

Standard approach

In his online presentation, Zorian emphasized the importance of a standard methodology to ensure that IP blocks are testable, which would help make SoCs 100 percent testable. "Because designers work with IP from different vendors they need to know that the IP is testable," said Zorian. "As such, in addition to the IP they need the test information that was used to test individual cores."

But each IP vendor ships its cores with individual core test wrappers that are different from other IP on a chip. "The IEEE 1500 effort standardizes on the core test wrapp ers so that there is a standard interface between the core provider and core user," Zorian said. By implementing infrastructure IP (I-IP) for testing, diagnosis, repair, characterization and fault tolerance, designers will play into a hierarchical design flow that will ensure testable SoCs, he said.

The 1500 standard allows the testing of chips that contain cores from multiple sources. The standard provides a methodology to identify and configure testability features in chips that contain embedded cores.

"Approaching the SoC design with a hierarchical methodology that includes standard testing features with a wide range of I-IP will result in better yield, diagnosis and field reliability," Zorian concluded.