3.3 SOC Verification


All the verification methods we covered in Chapter 2 for ASICs apply to SOCs as well. However, SOC verification becomes more complex because of the many different kinds of IPs on the chip. A verification plan must cover the verification of the individual cores as well as that of the overall SOC. A good understanding of the overall application of the SOC is essential. The more extensive and intense the knowledge of the external interfaces and their interactions with the SOC, the more complete the SOC verification will be. Various SOC applications require unique external interface constraints, and the verification team should consider those constraints early on.

The SOC functionality can be represented with data-flow and control-flow models.

Data-flow analysis determines the bandwidth capacity of an SOC interconnect and the requirements of its various components by considering the amount of data that needs to be processed under real-time conditions. This is because in many situations sources of data and the final processed data could have different rates.

Control-flow analysis for an SOC takes into account the nature and rate of external interface processing. The control of the data and events from outside may be in various time domains, or it may be totally asynchronous in nature. The rate of change on these interfaces may also need to be determined to allow for sufficient processing power within the SOC to be able to respond within given timing and data-flow constraints. Some responses may need software processing and/or other external interface dependencies.

A detailed data-flow and control-flow analysis for a given SOC will result in the necessary verification strategy.

Verification Planning Guidelines

The following should be considered in verification planning:

  • External Interface Emulation When verifying complex SOCs, in addition to logic simulation techniques full chip emulation should be considered. The primary external interfaces of each IP, as well as the SOC data interfaces, should be examined to evaluate the need for any SOC simulation. This should be performed simultaneously for all cores in order to evaluate the modeling work required early on.

  • Hardware/Software ( HW / SW ) Integration HW/SW integration must be planned for SOCs with processor type cores. Developing bus-functional models should be part of the plan.

  • Verification Resource Planning Resource planning is a vital step for a successful SOC verification. The size of a verification task can predict the simulation hardware resources and the needed personnel. Similarly, the number and complexity of IPs in an SOC will determine the amount of estimated regression time, hardware computing resources, and simulation license requirements.

    Since in a complex SOC there are many IPs and each one may have several versions, hence source code control software such as CVS and RCS must be used in the verification environment. Source code control software keeps track of any changes made to various design files. It also protects the directories and files from accidental deletion. When multiple engineers work on the same file, source code control keeps a record of who did what and when.

    For large and complex test files of an SOC with several levels of hierarchy, Makefiles are essential. The make utility keeps track of which files need to be updated and recompiled. Thereafter, a simple make command performs the updating and recompiling job. This can provide substantial reliability in verification.

    A plan has to be developed to identify which of the cores have to be interfaced and accessed through the CPU. Therefore, a list of tests must be defined to represent the actual firmware that will be used in the final SOC system software.

  • Regression Planning Regression testing is the process of verifying designs to guarantee that earlier debugging has not affected the overall functionality. It's quite possible that a change in a design made to fix a problem, detected by a (debugging) test case, may in fact break the functionality that was previously verified . Therefore, regression testing should not be confused with debugging. Another benefit of regression testing is a reassurance that the design is backward compatible with the original design that was tested . Typical regression tests run anywhere from 15 hours to a few days. HDL languages such as Verilog and VHDL are widely used in regression testing. These languages offer a faster approach that can speed up the regression testing period. The user command line option in Verilog for this approach is fastmod

    It should be noted that regression testing can run indefinitely if the condition it is waiting for never happens. Therefore, a mechanism to prevent such endless runs is to automatically terminate the testing after a specific amount of time. This can be done in VHDL using the time bomb procedure.

    Regression testing can be automated by using batch files and scripts to provide more reliability for complex SOCs. In automated regression, various tests can be distributed over multiple workstations and the differences between the report files can be stressed.

In addition to the above verification planning guidelines, the verification team should also consider both dynamic timing simulation and static timing verification.

Dynamic timing simulation should be used for timing analysis of asynchronous designs as well as synchronous designs. Using dynamic simulation the verification team can verify the functionality as well as the timing requirements of a design. The team must develop comprehensive input vectors to check the timing characteristics of critical paths in a design.

Static timing analysis should be used to verify the delays within the design. Using STA, the design team must verify every path and detect serious problems such as glitches on the clock, violated setup and hold times, slow paths, and excessive clock skew.

Figure 3.2 summarizes the verification planning elements.

Figure 3.2. SOC Verification Planning


SOC Verification Execution

What we have covered so far in this section dealt with preparation and planning for verification. Here, we outline some tips for SOC verification execution.

  • The verification team should pay special attention to the power-up and power-down sequencing of the different cores in the chip, both during simulation and during device bring-up.

  • The register inside each core should be carefully verified.

  • Individual cores should be tested. Regression, debugging, and test coverage should be performed on all individual cores.

  • 100 percent code coverage is desirable. Low code-coverage numbers should alert the verification team that additional testing is required.

  • Software reuse can speed up the verification process in device bring-up.

Figure 3.3 illustrates the SOC verification execution flow.

Figure 3.3. SOC Verification Execution Flow


IP Verification

Reusing previously verified IPs can tremendously expedite SOC verification. Since IPs can be delivered in different formats from various IP vendors , the verification planning phase should start early on. An IP acceptance checklist should be developed and followed, whenever third-party IPs are used in an SOC design. A typical checklist consists of the following:

  1. IP design files

    1. Documentation for the directory structure

    2. Verilog/VHDL RTL source files

    3. Source files for sub-blocks

  2. Documentation on revisions

    1. Functions no longer supported

    2. Information on revision control

  3. Verification/simulation

    1. Testbench or test cases for regression test

    2. Readme files for running the tests

    3. Information on testbench generation tools, such as Vera and Specman, if used for the IPs

    4. Source codes for any C, C++

    5. Scripts such as Perl

  4. Synthesis/technology- related and test coverage

    1. Synthesis scripts for core resynthesis

    2. Functional specifications for the cores/IPs

    3. Specifications on timing, power, and area

    4. Operating conditions and clock speeds

    5. Set-up requirements for all I/O signals

    6. Detailed information and specifications on the sub-blocks

    7. Any information on DFT coverage for the cores

Figure 3.4 shows a simplified overview of IP verification flow. First an IP is verified by the IP vendor, then the user reverifies the IP in his own environment. This is usually a tedious and time-consuming task, because design files and testbenches have to be translated and reverified. Also, in order for the acquired IP to communicate with other IPs on the SOC, the core has to be specially wrapped according to specific interface protocols (see appendix B on Open Core Protocol for one such example). Wrapping an IP core is another tedious task that deals with adding bridges and extra logic to the existing IP. Finally, after the core is successfully wrapped, it is now ready to be integrated with the rest of the SOC.

Figure 3.4. IP Verification Flow



Automation is another important part of the overall verification strategy. Automation can help speed up the verification process tremendously. Automation tools usually consist of the following:

  • Scripting languages

  • Version control systems

  • Makefiles

Verification engineers automating repetitive commands into simple scripts use scripting languages such as Perl and Python everyday. UNIX shell scripts are also popular among verification engineers. Examples of UNIX shell commands are Bourne, Korn, and C shells .

As was mentioned, version-control systems should also be used. Examples of such systems include CVS, RCS, and makefiles.

Automation should be applied to every step of the design, verification, and even manufacturing flows. Since EDA tools are constantly evolving, it is important to make sure that communication from one tool to another takes place smoothly, hence not disturbing your flow. Automation techniques are also used to enhance the communication between tools.


From ASICs to SOCs. A Practical Approach
From ASICs to SOCs: A Practical Approach
ISBN: 0130338575
EAN: 2147483647
Year: 2003
Pages: 61

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net