UVM : Recap before Release

With UVM1.0 all set to release, here is a quick recap on the journey so far.

Verification started off with the regular HDLs. As design complexity increased, HVLs were introduced to accomplish this task. The need to maximize returns lead to development of (BCL) base class libraries (using HVLs). This facilitated realization of verification environment across multiple projects in an organization efficiently. To avoid maintainability issues, this task was left with the EDA vendors who morphed these BCLs into methodologies defining everything that needs to be there in a verification environment. Time to market pressure pushed reusability for common modules & protocols in design as well as verification. Soon Verification IPs (VIP) with different HVLs and methodologies came forward. The common HVL & methodologies include Specman-e with eRM, Vera with RVM and System Verilog with OVM/VMM. Different HVLs & methodologies opened up issues related to interoperability i.e. –

-    Developing a verification environment with VIPs in different languages and methodologies.

-    Not all HVLs and methodologies would work with given set of simulation tools.

During all this, System Verilog took a lead to become most commonly used HVL with OVM & VMM as the prime methodologies. In 2008, Accellera, an industry standard organization took the charge to address the above issues and formed a VIP-TSC (Verification IP – Technical subcommittee). By June 2009, the team came up with ‘Recommended Guidelines for Interoperability between VMM and OVM’. Next they started off with a proposal defining UVM i.e. Universal verification methodology with the goal to solve the interoperability problem while providing the best of available methodologies.

UVM 1.0 EA

In May 2010, VIP TSC released UVM1.0 EA (Early Adopter) with following salient features –

-     This release was based on (but not 100% backward compatible with) OVM 2.1.1

-     Modified and enhanced objection mechanism

-     Modified and enhanced callback mechanism

-     Added a new report catcher and messaging mechanism  

-     Few deprecated features of OVM removed completely

Along with a standard, this release included – a user guide, a reference manual and an open source reference implementation.

For OVM users to migrate to UVM 1.0 EA, it was pretty straight forward. With help of a script the change of names (ovm_ to uvm_, OVM_ to UVM_, tlm_ to uvm_tlm_, and TLM_ to UVM_TLM_) was quick. If the OVM test bench was using objection and callback mechanism then that required modification to be UVM compatible.

For VMM users, a VMM-UVM interoperability library was made available to enable ease of migration.

UVM1.0 – what to expect?

With UVM1.0 release all set to hit the mainstream in a couple of week’s time, here is what one can expect from that release –

-     Register package. Based primarily on VMM RAL and modified to fit into UVM.

-     Improved Phasing mechanism. Mainly divided into 3 phases [Initialization, Execution and Termination], with each phase further sub-divided into multiple sub phases. This new scheme will provide enhanced test bench control to the user.

-     Resource manager. An updated form of configuration mechanism from previous release to handle different components & objects of test bench with more ease and effectiveness.

-     Command line options made available in form of a data structure to be used in developing and controlling complex test benches.

-     In built support for TLM (Transaction level modeling) based on OSCI (Open SystemC initiative) TLM-2.0 standard.

-     Backward compatibility with UVM1.0 EA.

-     Clean from bugs reported for UVM1.0 EA.

What next?

Beyond successful UVM1.0 release we can expect the VIP TSC team to start looking into -

-     Feature improvement from UVM1.0 based on the feedback

-     Additional System Verilog based methodology features

-     Support for different HVLs or a scheme to integrate various VIPs developed using different HVLs with UVM environment

-     New features to support Low power verification

-     Support for hardware accelerators and virtual prototyping

Hats off to the VIP TSC team for putting efforts in defining a one stop solution for the verification worries.

What is Linaro?

Happy New Year!

With the onset of this New Year I decided to share insight (once in a while) into topics that indirectly affect the verification engineers. While browsing the product list at Consumer Electronics Show 2011, I see that a large no. of devices getting showcased run on Linux variants. A quick analysis into the product development of these devices reveals some shortcoming.

Problems

-      With application driven designs picking up, the system companies want chip vendors to provide a platform (middleware+hardware) ready for application development. With each vendor having proprietary platform, applications may not utilize the hardware features optimally as the app developers have little or no knowledge of the hardware features.

-      With software claiming majority of SOC development cost, controlling this rising cost is a must so as to avoid limited no. of new (costly) SOC designs at future nodes. Companies need to cut down on any redundancies to lower cost.

-      System companies find it difficult to evaluate SOCs from multiple vendors as both the hardware and software are variables in this process.

-      Unless the system companies have squared down on the vendor the application development cannot start. 

   

Solution

‘Linaro’, a not for profit, open source organization formed by contributions from ARM, Freescale, IBM, TI, Samsung and ST-Ericsson.  It is focused on delivering optimized tools and software for Linux on ARM Cortex-A processors. Linaro has five Working Groups: Graphics, Multimedia, Power Management, Kernel consolidation with tools focusing on middleware (e.g. multimedia and graphics) and low level software (e.g. kernel and boot). It would be working with Linux-based distributions, such as Android, LiMo, MeeGo, Ubuntu and webOS, to create regular releases of optimized tools and foundation software that can be used widely by the industry. User interfaces & applications needs to be built on top of Linaro code.

The generic middleware available from Linaro results into no. of benefits -

-    Improved Time to Market with significant reduction in product development cycles.

-    Optimal use of hardware features to improve power & performance.

-    Minimizing redundancies reduces cost of SOC development.

-    Increase choice of hardware with software no being a variable anymore.

-    Provides a platform to compare hardware from different vendors.

Pitfalls

As of now Linaro only supports Linux on ARM processors. It would be interesting to watch how other vendors (mainly Intel) react to this. Do they join Linaro or extend a parallel offering.  Also, recently some SOC vendors have revealed their own processors claiming it to bring in the differentiating factor for their products. With multiple processors pitching in, Linaro (though promising) may see a long road to success.