Standards are created for various reasons, but when the user community asks for one, it is demonstrating the degree of pain it feels. One such pain point is verification closure and the need for metrics that can reliably predict design quality as well as the degree of confidence in the verification process. Users are faced with formidable challenges including a vast array of coverage types coming from multiple tool classes, from multiple levels of abstraction, and from various stages in the verification process.
The Accellera Unified Coverage Interoperability Standard (UCIS) committee has been tasked with developing answers for these problems. The need for a unified coverage database (UCDB) was defined along with an application programming interface (API) to store, access, and manipulate data contained within the database. This involves a number of technical challenges, including naming conventions, coverage semantics, merging of data, and integration of formal and simulation data that are being addressed by the committee.
Goals For The Standard
The ultimate goal, for a user, is a metric that defines verification completeness. This is defined differently by every company and development team and defies consistency or unification. It is not the objective of the UCIS committee to standardize this. Typically, measures of verification progress or completeness are called coverage goals or targets, and the overall quality is stated as the completion of all coverage goals. The ideal situation is to take multiple types of coverage goals and combine them into a single metric. The definition of those coverage metrics needs to be consistent within the industry such that data collected from one simulation vendor is compatible with similar data from a second vendor.
In order for a user (or tool) to be able to create such completion metrics, they must have access to all of the necessary data in a form that renders the meaning of the data completely unambiguous. This is the goal of the UCIS committee; achieving it will enable the maximum amount of creativity in tools and methodologies to satisfy the user goals.
Technical Challenges
Next we will briefly overview some of the challenges and the approaches that are being taken to solve them. The first challenge we will take up is the naming of objects. For multiple applications to perform the creation, merging and display functions, the syntax and semantics associated with the data have to be unambiguous.
For example, while it may be clear what name to use to refer to a specific line of code, an expression within a line of code, or even the name associated with a covergroup bin, not all coverage objects are as simple. Consider the name that should be associated with a “bin” of signal values used in expression coverage. Unnamed scopes and generated scopes also present naming problems. A significant requirement for the UCDB is to achieve a level of performance at which, for example, simulation is not unduly slowed and results can be analyzed quickly. This requires mechanisms for fast access to the data, which is usually accomplished using a unique object ID or pointer. However, these mechanisms are generally not portable and name-based techniques are too slow. Thus, ID-based techniques are used within a vendor’s implementation, but translation tables are provided for portability.
A second area of technical challenge is that of semantics of metrics. A common complaint from users is that they obtain different coverage results from different vendors. Some metrics come from industry standards, such as the SystemVerilog covergroups, but many metrics evolved from proprietary verification methodologies. Consider assertion coverage: No two vendors have the same interpretation of this metric. After a company has invested time and effort into such a capability and their customers have been using it, changing the way they are measured is problematic.
Continue on next page