SoC: Codesign and Test -> Embedded test complicates SoC realm

Whether in telecommunications, automotive or wireless applications, the key reason for embedding predesigned functions is to reduce the time it takes to get complex systems on the market while speeding their proliferation. Being able to rapidly design, manufacture, test and debug complex SoC designs is crucial for the continued success of the electronics industry.

Traditional test and diagnosis methods, if applied to today's complex SoC devices, require considerable engineering effort at all product realization stages-from design to bring-up to manufacturing. Hence, they increase the time it takes to get a system to market. The reason is that the traditional methods simply rely on te st vector generation and application methods that are not scalable with the increasing complexity of today's SoC designs.

Observing tradition
One such traditional method is automatic test pattern generation. ATPG is characterized as a flat design methodology because it is performed during the final design stages on the entire SoC design level. Even though the SoC design is typically built block by block, automatic-test-generation methods and tools do not take advantage of that block-based hierarchical design methodology. That is unlike most other design processes-such as synthesis, simulation, verification and even most back-end design-which are not SoC-level (flat) activities but hierarchical efforts, performed on a block-by-block basis.

As chips grow in complexity, a flat approach becomes the bottleneck in the development process. And ATPG is not the only flat test process: Other traditional test and diagnosis methods used during silicon debug, manufacturing test or fault diagnos is are similarly flat activities that do not scale with the technology.

To minimize SoC-level flat activities, an SoC designer today could adopt embedded test by installing a specialized embedded system for test and diagnosis in the SoC itself. That embedded system would comprise predesigned test and diagnosis objects, which are typically embedded and perform their operation on a block-by-block basis (not at the flat SoC level). This creates a scalable solution that sharply increases efficiency by minimizing engineering effort at different design and manufacturing stages, contributing to a quickly finished product. The use of this embedded test methodology ensures that test and diagnosis contribute to the overall growth of the SoC industry, rather than slow it down.

Today's system designs often mix diverse types of circuits, such as random logic, RAMs, processors and analog blocks, in a single SoC. As chips become more integrated, more advanced circuit types are being added to this list, such as embedded FPGAs, RF-microwave and flash memory blocks, and may even move beyond the electronics domain to contain microelectromechanical and optical blocks.

An efficient and cost-effective solution to testing and diagnosing these diverse types of blocks is achieved by coupling a predesigned embedded test-and-diagnosis object with its corresponding block. For example, the embedded object containing a random logic test solution is a dedicated intellectual property block, which gets embedded into or coupled with the random logic block or blocks.

Another such object is required for a given analog block and a third for RAMs. The individual embedded test objects are typically soft (RT-level) hardware cores specialized in providing full at-speed self-test and diagnosis to each block they are coupled with. Coupling these design objects with their corresponding blocks r esults in much desired block-level autonomy in test and diagnosis-that is, the test vectors are generated and evaluated at the block level and not the SoC level. This ensures that the solution is a block-based scalable one and avoids the flat SoC-wide ATPG effort.

An SoC-wide embedded system for test and diagnosis consists of the set of predesigned embedded test objects (for logic, RAMs, analog blocks), which are typically networked through dedicated transmission channels, known as test access mechanisms, and are distributed over the entire SoC. This network of embedded test objects is typically accessed through the chip-wide five-pin IEEE-standard 1149.1 TAP (Test Access Port).

An entire network is designed to meet the test and diagnosis specifications of a given SoC. It is really the SoC's reconfigurability that maps the specific test requirements (such as test time, power dissipation, test resource sharing) to a corresponding network and in the individual embedded test objects. While the e arlier generation of these hardware objects, commonly known as BIST (built-in self test) blocks, had fixed configurations (limited to go/no-go testing), the current generation of these embedded test objects are far more sophisticated in terms of reconfiguration to meet the requirements of the blocks.

For instance, a hardware object to test a random logic block needs to be reconfigured for requirements that include test speed, fault coverage, diagnostic options, test length, etc. With earlier generations, the BIST blocks did not have such programmability. However, as embedded systems for test and diagnosis grow more sophisticated, the level of flexibility required will keep increasing. One may observe the general trend from the early hardwired embedded functions for test (BIST), to today's reconfigured embedded test hardware objects, up to tomorrow's largely programmable embedded test functions, which will probably be based on embedded software objects.

In addition to mixing logic, RAMs and an alog circuits on-chip, today's SoC designs are increasingly using intellectual-property cores. This means the reuse of predesigned functional blocks from third-party core providers or internal organizations. These cores come with different degrees of readiness for reuse in system-level design and are designed for use in many different SoCs.

Predesigned conditions
Because it is predesigned, a core may not only originate in a different organization or company, but it may also be developed at a different time from the current SoC. As a result, the core must be able to anticipate the desired SoC-level test requirements for a wide range of target SoC designs.

Of course, this anticipation is not a trivial task. However, if the predesigned core comes with, or is predesigned for, an embedded test object, then it becomes autonomous in terms of test and minimizes its dependency on the SoC-level test resources. This reduces further the engineering effort involved at the SoC level and optimiz es the test resource at core level.

To ensure this test friendliness and interoperability of cores coming from diverse sources, a standard for embedded core test is under development: IEEE P1500. Although it does not standardize a core's internal test method or an SoC-level test across configuration, it does concentrate on standardizing a core test language capable of expressing all test-related information to be transferred from core provider to core user.

IEEE P1500 also works toward standardizing a configurable and scalable core test wrapper, which allows easy test integration-for example, the test plug-and-play of the core to its host and the next-level core or the SoC. The standard core test wrapper interfaces with an on-chip test access mechanism to deliver the test data during different test modes (internal, external, diagnosis, etc.).

Utilizing embedded test objects, the infrastructure built on-chip and the embedded test database provide scalability and further efficiency in t he engineering efforts from silicon debug up to field diagnosis. Moreover, besides simplifying the engineering efforts and reducing the development costs, the use of this embedded system for test and diagnosis, among many other benefits, improves product quality, helps optimize the yield and reduces the manufacturing test costs.