Showing posts with label Methodology. Show all posts
Showing posts with label Methodology. Show all posts

A Step-By-Step Methodical Approach for Efficient Mixed-Language IP Integration


This article provides a comprehensive methodology that highlights the best practices for mixed-language design integration and automatically comes up with an option for designers to select the optimal method for integration.
There are broadly five ways of making mixed-language connections. Pros and cons of each of these approaches and their comparison is described in terms of the usage scenarios, performance implications of using one versus the other, delta cycle value update concerns, and more. A step-by-step guideline based on decision-making trees that designers can follow to help them decide which approach best suits their particular mixed-language integration scenario is also discussed.

Application Specific IP


One of the major barriers for Semiconductor IP commercialization is to provide evidence for an IP's quality. A common approach by IP vendors is to prove the quality of their IP in a test chip. Usually the Die contains the IP block separated from the System-on-a-Chip (SoC). It is, though, uncertain how the block will function in ASSP and ASIC products, potentially damaging its perceived commercial value. In Rosetta's methodology, the IP Core is a block within a subsystem, integrated to enable the subsystem functionality and targeted for a specific market and application. By analyzing the specific requirements of the market and application, and by providing an IP package targeted at those requirements, we solve and mitigate the IP quality

Toyota Prius 2005: An Early Warning About Verification


In this article Richard Goering talks about a software bug in Toyota Prius 2005 and after 5 years even after a through study by three of Toyota engineers on this issue did not help the company learn any lessons. He also talks about model-based verification which the original presentation talks about and how a formalized methodology for verification can help alleviate issues that may arise later in the field. Clearly a must read article!

The world of HVLs and VIPs


Over the last decade functional verification of ASIC systems has witnessed a paradigm shift in verification methodologies. Until late 90's a verification project requirements were met by traditional test-benches written using a HDL(hardware description language, used for coding the design) or a software language like C. These test environments supported directed testing by generating a pre-calculated stream of input data only focusing on the desired coverage points in the design.As the design size and complexity grew exponentially, with a million gate design becoming the norm, clearly the directed verification approach is quite cumbersome. It is an almost impossible task to manually code the test vectors to test your million gate design under all operating conditions. The ever increasing aggressive project schedules also pushed in favor of a powerful yet easy to develop test environment. Hardware verification langauages (HVL) came as a boon to solve all these problems. HVLs typically include features of high level programming languages like C++ or Java and in addition they support built-in constructs which help you develop the environment with fewer lines of code. It is much easier to generate random stimuli or constrained random stimuli, as needed and the built in HDL interface support let’s you hook up the environment and the DUT seamlessly.

Of the handful of HVL choices available in the market SystemVerilog and e language (Specman) are the most popular and widely adopted by semiconductor companies. The reason for these two languages being the preferred choice is not just the language features itself but the accompanying methodology prescribed by the EDA vendors (ex: OVM/VMM for SV and eRM for e language). These methodologies provide guidelines to build modular, re-usable and extensible verification modules which support plug and play development. With most of the silicon designs today adopting the SoC (System-on-Chip) methodology where several design IPs are integrated on a single chip, there is a new requirement for corresponding verification IPs (VIP). By taking advantage of the VIPs available in market, the verification team can build a test environment for a complex SoC with minimal resource and time utilization. A standard verification methodology serves as a common platform for the various third party VIP developers and its customers. So it’s actually the verification methodology rather than the language which influences the decision on VIP selection. Some methodologies have made it possible to integrate verification modules written in different languages so that you don’t have to discard any legacy code if available (you may have to make it methodology compliant though). VIPs and verification methodologies are still relatively newer concepts to the verification world and is being tried out in experimental phases by semiconductor companies. Not all of the industry leaders have adopted these methodologies completely probably because of the overhead in training their current workforce and replacing the legacy code. Here’s hoping that the EDA vendors enhance their methodologies to make it more developer friendly.