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.
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.
