he presence of ARM and other third-party IP in system-on-chip (SoC) designs has become ubiquitous, simplifying design while complicating

verification. Both IP suppliers and SoC designers are hampered by unavoidable restrictions and impracticalities involved in sharing both proprietary code and large verification environments. Hence, there is a compelling need for a more effective way for IP end-users to share their test environments with IP vendors, without compromising the intellectual property of either party. Mentor Graphics IP Replay answers this need for IP vendors and SoC developers who are users of Mentors Veloce emulator. IP Replay is a unique feature that enables SoC designers to isolate a problem in thirdparty IP, reproduce that problem in a standalone environment, and send that environment to the IP vendor. The IP provider can then run the exact same database on their Veloce emulator, quickly reproducing the problem and debugging it in their IP. Once the IP is modified, IP Replay enables the IP provider to validate that the fix truly resolved the issue within the target environment before the corrected IP is sent back to the end user.

By Richard Pugh, Business Development Manager and Vijay Chobisa, Product Marketing Manager, Mentor

Collaborative Verification of Third-Party IP in Early Adopter SoCs

Strategies & Methodologies

third-party IP is black boxed and SoC designers cannot share information about other third-party IP in their design. IP end users also may not want to reveal new technologies of their own. The complexity and size of test environments makes it difficult if not impossible for IP users to create and send IP vendors their verification environment, which vendors need to reproduce the problem in a practical, feasible manner. Even if an IP vendor can obtain the end users verification environment, reproducing an entire test environment is a monumental task for todays highly complex designs. The time required is usually prohibitive. Finally, an IP provider may not have the systems and infrastructure to verify complete SoCsas they tend to be 10 to 50 times larger than the IP blocks their tool flows are set up to handle. These last three reasons are particularly problematic today with the prevalence of IP embedded in designs that have deep verification spaces. Errors in these designs often occur in the context of complex sequences of operations that may take billions of cycles of operation to trigger an error. One tactic for debugging such errors has been to develop a standalone stimulus environment; when the IP integrator finds a localized problem within a very large environment, they must write a test case that mimics the problem and provide it to the IP vendor for debugging the IP. Unfortunately, when errors occur only after many billions of cycles of operation, writing a stimulus stream to reproduce the error can be so complex and time-consuming that it becomes impractical. Similarly, the amount of time required for an IP vendor to emulate an end-user provided test environment of this magnitude presents a disincentive to locate a found bug and fix it. For example, if it took the end user three weeks to run their design on Veloce before it reached the problem, it is a waste of time for the IP vendor to have to rerun the entire emulation for another three weeks so they can find the bug.

Obstacles to Verifying SoCs Containing Third-Party IP

Early versions of third-party IP are desired by SoC designers for the advanced features and competitive advantage they deliver; yet, quite often all of the bugs have not been worked out of the embedded IP. When one of these bugs causes an error in an SoC, the SoC vendors cannot simply debug it themselves because they do not have the required knowledge of or visibility into the internals of the IP. Likewise, the IP vendor is thwarted by the necessity of tracking down the bug without the benefit of working within the context of the system that caused the problem to emerge. In addition, they may not have an understanding of the end users SoC environment even if it were available to them. This situation persists for several valid reasons. Proprietary code and design environments must be kept secret both to protect new technologies and adhere to legal requirements. Thus,

48

Strategies & Methodologies

With the amount of IP that companies like ARM now provide and the increasing difficultly of exchanging information that is closely protected, some other form of verification to overcome these obstacles and inefficiencies is clearly needed.

IP Replay: SoC, Subsystem, and IP Debug

IP Replay is a patent-pending Veloce technology that resolves all of these obstacles, enabling an early adopter flow that benefits both IP vendors and their customers. IP Replay is unique to Mentors Veloce emulator and cannot be reproduced in a simulation environment or any other platform.

The IP Replay platform enables IP integrators to automatically extract and create a standalone test environment that reproduces a found issue, localized around the third-party IP, and then send that environment to the IP provider for analysis and debug. This isolated environment includes the required test sequence generation to manifest the issue and the logic to test the responses of the IP. By extracting a smaller model from a larger one, with all the necessary stimuli and without external dependencies, IP Replay isolates design instances and replays these runs separately. By employing a smaller emulation model, IP Replay makes reproducing and debugging a problem fast and practical, even for SoCs with billions of cycles. For example, if an end user runs a test for three days before finding a bug, the IP vendor does not have to rerun the test for additional three days. Instead Veloce IP Replay takes a snapshot of that part of the test run that is very close to the problem. The IP vendor has to run only an extremely short section of the test to reproduce it, reducing a three day run to a few hours, or less.

IP Replay Use Model

The IP Replay use model has four steps: 1. Identify the IP while compiling the design 2. Capture the IP stimulus 3. Extract the IP and create a database for IP bug reproduction 4. Replay and reproduce the IP bug and debug The first three steps are performed by the third-party IP end user. The fourth is done by the IP vendor. The IP Replay flow commences when a customer running a test scenario encounters some issue that may be related to the third-party IP embedded in their SoC. First, while compiling the design, the end user identifies the IP that they want the Veloce compiler to extract information about. The end user identifies the problematic IP within the SoC block diagram and notes the compilation time when the error occurred. Second, the end user runs Veloce emulation with the IP Stimulus Capture feature turned on to extract the stimulus to the IP. This information is captured in the Stimulus Capture database.

Figure 1: IP Replay delivers support models and debugging mechanisms for IP vendors engaging with early adaptors

The IP Replay capability fully supports general debug of designs with large or deep verification spaces; such as processors, mobile devices, and security and networking subsystems. It provides a debug solution for errors that occur after billions of cycles of operation and for errors that manifest in the context of complex sequences involving the full SoC. When cutting-edge IP is in an early stage of development, it often contains bugs that typically prohibit flagship IP customers from taking advantage of the latest-greatest IP in their design. IP Relay removes this obstacle to early adoption. SoC designers can start firmware/software development and system integration early on, before the third-party IP provider is absolutely confident that their latest IP is bug free. When end users find a bug in a particular third-party IP, IP Replay enables them to work with that vendor without revealing information about other vendors IP in their SoC, hardware targets in their environment, or other dependencies in their set up that they do not want to share. IP Replay is extremely beneficial when the end users entire verification environment cannot be given to IP vendors, when the IP block is a small portion of the entire design, and when recreating a standalone test environment is difficult due to complex test sequences or real world traffic.

Figure 2: The four step IP Replay use model.

continued on page 63

49

Technology In-Depth

I recall that when I first proposed using an ARM Powered smartphone to calculate the solution for the CubeStormer II, Mike was a little sceptical about whether it would be fast enough, David Gilday, Principal Engineer CPU at ARM told IQ Magazine. However, when I created the multi-threaded Android app to make effective use of the dual-core ARM Cortex-A9 processor in the Samsung Galaxy S II smartphone, he was soon convinced otherwise! One of the many challenges in achieving such a high speed solve was to optimize the overlapping movements of Mikes incredible LEGO mechanical design. This involved the co-ordination of multitasking

embedded software running on the four ARM7 processors in the MINDSTORMS NXT intelligent bricks, added Gilday. It has been challenging, amazing fun and extremely rewarding. I am thrilled and proud that our CubeStormer II has achieved a Guinness World Record. I hope it inspires other people to be innovative and creative. After all, Mike and I are just two friends who built a robot out of a few LEGO bricks and a smartphone, concluded Gilday.

END

Collaborative Verification
continued from page 49

Summary
IP Replay makes it more practical and profitable for IP vendors to engage with IP end users early on by delivering a support model and debugging mechanism for verifying third-party IP within SoCs or IP-subsystems. Users of third-party IP can use IP Replay to automatically extract a standalone test environment that can be shared with IP vendors so that IP vendors can reproduce bugs without needing the entire SoC verification environment. IP Replay facilitates the sharing of third-party IP and end user test environments, increases debugging efficiency, and saves weeks of verification time. It speeds up debugging by isolating design instances from the rest of the SoC design and generating bug reports with real SoC test sequences. This enables SoC designers to start driver, firmware, and application software development early, and it allows them to suggest, to the IP provider, internal optimizations to the IP itself as an alternative to less efficacious and more onerous software-based workarounds.

In the third step, IP Relay extracts the problematic IP to create the Extracted database for IP bug reproduction. The extracted database contains netlists (no source code) and related files for the specified IP. Once the end user has extracted the problem IP, the end user confirms bug reproduction. Then the IP provider simply TARs the whole environment and sends it with the Stimulus Capture and Extracted databases to the IP vendor. In the fourth step, the IP vendor does not have to do any compilation because the received environment is already compiled. They simply un-TAR the environment and re-emulate it on Veloce. IP Replay automatically starts the test at the failure point. All the debugging capabilities of emulation, such as waveform viewing and assertions, are available. Once the IP vendor finds the problem and fixes it, they replace the IP with the original RTL and run the compile again to validate that the new RTL has been fixed. Finally, they return the corrected IP to the end user.

END

63