Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > EDA/IP
?
?
EDA/IP??

Overcoming challenges for SoC verification team

Posted: 30 Aug 2012 ?? ?Print Version ?Bookmark and Share

Keywords:verification engineers? block-level? IP?

The TrekBox and an accompanying events file ensure that test cases running on the embedded processors are synchronized with the testbench components. This ensures that data is read into the chip at the right time and that outgoing data is checked for correctness at the right time. The use of UVM is not mandatory; TrekBox can connect to simple bus functional models (BFMs) or to testbench components using any of the popular standards, including the Open Verification Methodology (OVM) and the Verification Methodology Manual (VMM).

Impact on SoC development flow
The impact of adopting this new approach on the verification process is significant. For a start, it eliminates the need for hand-written C tests or diagnostics running on embedded processors. Recognizing the inadequacy of chip-level testbenches, most SoC integration teams handcraft a small set of software tests to sanity-check the full-chip operation, a slow and tedious process. It is hard for programmers to develop the type of multithreaded stress-tests that TrekSoC generates automatically. Hand-written tests are difficult to modify and unlikely to fully exercise the entire verification space

Since chip-level testbenches with processor models capable of running programs tend to run slow in simulation, some SoC teams remove processor models and drive sequences of transactions onto the processor bus with a bus functional model. This is similar to how block-level verification is performed using constrained-random techniques; the processor bus essentially becomes just another input/output port for the chip. However, tests that coordinate the processor bus activity with the regular inputs and outputs are hard to construct, especially when trying to emulate multithreaded and multiprocessor test cases.

Fortunately, TrekSoC can also operate in a fully transactional mode, automatically generating the processor bus transactions rather than C test cases. As with the other input and outputs, these transactions can leverage an existing BFM or UVM testbench component for the processor bus. The transactional mode can be used to verify any design, including individual blocks or those with no embedded processors at all. Block-level scenario models can be reused and referenced by SoC-level scenario models in the process of SoC integration verification.

This approach does not entirely replace the need to execute the actual production software on the design, whether in simulation, acceleration, emulation, or on an FPGA-based prototype. This provides hardware/software co-verification and may also serve as a platform for software development.

However, production software is usually not ready before SoC tapeout, so the integration team may exercise incomplete functionality. Further, production code tends to be well behaved, not exercising much corner-case behavior. Running self-verifying C test cases will better stress the design and find most, if not all, bugs that are otherwise found only in co-verification or even after chip fabrication.

TrekSoC is touted to have benefits beyond the immediate advantages of verifying the current chip. This approach can work at all stages of the design and development flow. The verification task is no longer relegated to an end of RTL development activity, as it has been in the past, since it can be applied to models at any level of abstraction. If the SoC team has created a virtual prototype for software development, then the self-verifying C test cases can be run long before the RTL design is ready.

Bringing the integration verification earlier in the development process allows tasks such as performance verification to have a larger impact. It becomes possible to optimize the system for the desired performance and to ensure that the correct controls exist within each block for proper power management. Finally, performing verification on abstract models enables a more efficient process with execution speeds often orders of magnitude higher than for RTL verification.

Conclusions
In a world where methodologies are entrenched, it can be difficult to implement change. In a world where the job is endless, there can be equal difficulties in finding an approach that will bring relief. While there are no entrenched methodologies for SoC verification since the existing methods are falling short, a proven solution is at hand.

About the author
Adnan Hamid is co-founder and CEO of Breker Verification Systems. Prior to starting Breker in 2003, he worked at AMD as department manager of the System Logic Division. Previously, he served as a member of the consulting staff at AMD and Cadence Design Systems. Hamid graduated from Princeton University with Bachelor of Science degrees in Electrical Engineering and Computer Science and holds an MBA from the McCombs School of Business at The University of Texas.

To download the PDF version of this article, click here.


?First Page?Previous Page 1???2???3???4



Article Comments - Overcoming challenges for SoC verifi...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top