Top Concerns For A System On Chip Design EngineerNovember 24, 2016 9:25 am Leave your thoughts
System on Chip [SoC] design have seen an exponential growth in its complexity levels lately. As a result, verification engineers have risen in importance to become an integral part of the success of a product. These are the engineers given the responsibility for integration verification as well as system verification and validation.
One of the reasons why system on chip design is based on the divide-and-conquer approach is that it is too difficult for any one person to fully understand the total functionality. The same is true for verification because the task should be divided such that each aspect of verification can be performed by different people, possibly with different skill sets.
High-end chips may contain 200 or more discrete IP blocks. Many of these blocks come about as part of the system design process, where functional needs are identified and those that do not offer product differentiation are fulfilled by an existing IP block wherever possible. This leaves the in-house design engineers to concentrate on the most differentiated functions: the high-value parts of the SoC. What about the integration of these blocks? IP blocks can come from many sources, including internal design teams, development partners, EDA vendors and third-party IP providers. All these blocks need to be integrated with new blocks being designed for use within the particular SoC.
Some blocks may have been designed for reuse, which means that they likely will have several modes of operation or ways in which they can be used or configured, with only a few of these options actually used. Some are parameterizable and some may have been modified to fit the particular set of design requirements unique to the current design. Blocks may be at different levels of stability and quality. They may or may not come with test benches designed to demonstrate that they function correctly in a standalone environment. Most test benches are of little help when it comes to stitching blocks together and verifying that they can collectively perform a useful function.
Redundancy between these verification tasks must be minimized. For example, there is no point in having integration engineers repeat verification that has already been performed at the block level. Each block has been verified in a standalone manner and thus, when integration verification is performed, the team should not attempt to do this task again.
Instead, the verification should focus on ascertaining that the blocks have been connected correctly and that collectively they can perform the necessary system-level functions. In addition, there are certain types of functionality that only become apparent and verifiable at the full-SoC level –– the ability to support concurrency, power and clock management, for example, and performance issues such as throughput and latency.
System on chip integration engineers must perform three levels of verification, in addition to the block-level verification generally performed by different groups. Naturally this testing must be done at the “bare metal” hardware level, with no production operating software or drivers. However this article uses the metaphors of “drivers,” “applications” and “performance” borrowed from operating systems.
The first level is the driver level where the integration verification team concentrates on the ability of blocks to effectively communicate with each other. This communication is most commonly between a processor and a peripheral, but could also involve DMA engines, memory subsystems or other infrastructure blocks. This level establishes that the necessary communication paths are functional.
The second level, which builds on the first, is the application level. Here the focus is on verifying complete paths that represent application use cases for the SoC. Verification engineers ascertain whether the system on chip, can perform the necessary functions, whether multiple paths can be exercised concurrently, and whether there performance bottlenecks. The third level is the functionality that only exists at the system level, such as power and clock management. While pieces of the functionality are distributed among the blocks, the main controllers reside at the full-SoC level.
Collectively, these three verification levels make up the integration engineer’s responsibility, and information necessary to perform each task is somewhat different. The verification approaches are also different from those of block-level verification.
Keep Tuned To This Space For More. Happy Reading !!!
Technical Content Writer
Categorised in: VLSI Design Training
This post was written by admin