PRODUCTS

Zazz™ has been architected and developed from the ground up with one goal in mind. Increase the productivity of engineers adopting and utilizing Assertion Based Verification (ABV). The initial release focuses on automating the often tedious and error prone tasks of utilizing assertion libraries available from Accellera and the major EDA companies. The automation enables the engineer to add the most widely used library based checkers to a design in less than a minute, without interrupting the normal design flow.

Zazz™ for Assertion Libraries

Overview

Assertions serve as executable specifications describing a property of the logic that is checked in every simulation run. Surveys indicate that utilizing ABV can significantly reduce the verification cycle by cutting debug time in half.

Assertion checkers added during the design cycle can have significant impact on detecting problems early in the functional verification process since:

The designer is the most familiar with the design and the design intent.
The assertions point to the source of errors making debugging easier.
The design with assertions attached is ready for formal verification at the earliest stage in the verification cycle.
Designer provided assertion checkers result in increased communication between the designers and verification engineers.

The downside is that the time required by designers to create and add assertions is difficult to justify relative to the typical chip design schedule.

In an effort to make assertions easier to use Accellera, the industry standards organization, created the Open Verification Library (OVL). OVL is a free library of highly parameterized commonly used assertion checkers. The library currently consists of 50 assertion checkers created and verified by a committee of verification professionals from across the industry. The OVL checkers are highly configurable through the use of parameters and ports. They range in complexity from simple single assertions with no coverage defined to highly complex with multiple assertion, cover points and cover groups. The simple checkers only use 7 parameters while others have as many as 18. Even the simple checkers can be configured in over 7500 different ways.

OVL covers most of the needs of the designer and a large part of verification engineer assertion requirements. Most of the vendors of verification tools have created and made available their own assertion libraries. Although library availability represents a major step, acceptance by designers continues to be limited. A major problem is that instantiating, configuring and documenting library based assertion checkers is often tedious, error prone and time consuming. The flow related to using these libraries is described as follows:

Bring up the library reference manual and find the appropriate assertion checker and values for the parameters from multiple locations.
Create the input for instantiating the checker that must be formatted exactly relative to sequence, spelling and valid parameters values and port connections.
Create the bind or instantiation statement.
Manually document the checker for inclusion in the verification plan.

Without any level of automation, the preceding steps can take a significant amount of time and patience. If there is a mistake the assertion must be debugged and updated. In most cases, mistakes are not found until some level of verification is done.

It is no wonder that designers have been less than enthusiastic about providing assertions with their designs.

The Zazz Solution

Zazz is a productivity tool that automates the tedious error prone tasks associated with using assertion libraries. The automation results in the ability to add assertion checkers that cover 95% of designer requirements to a design in less than a minute, without interrupting the normal design flow. The dramatic productivity gains make it easy to justify incorporating the benefits of designer provided assertions. Integral to and extending the capabilities of Zazz is an advanced incremental parser/elaborator and design viewer accessed from the user’s editor of choice.

Zazz is a Linux based productivity tool that fits into all design flows. It supports any mix of Verilog 1995, Verilog 2001 and SystemVerilog design files. Support is provided for Accellera's Open Verification Library (OVL), Cadence's Incisive Verification Library (IAL), Mentor's Questa Verification Library (QVL) and Synopsys' SystemVerilog Assertions Checker Library with Coverage Level Reporting (SVA _CG). Zazz is intuitive and easy to use making it possible for Zocalo to sell at a low price using an Internet sales and support model.

Zazz Front End The front end to Zazz is an advanced incremental parser/elaborator and design viewer. An existing design can be read into Zazz and parsed, elaborated, and graphically displayed. The design may then be modified with the user’s editor of choice without leaving Zazz. When a design is modified and saved, it is incrementally parsed and elaborated. The incremental feature, along with the built in modification monitoring provides fast update to the graphical display along with feedback on any errors.

Zazz’s Design Viewer is not the typical design browser. It is an advanced design viewing, navigation, and modification monitoring application. When a design element is selected in the Design View, the Source panel displays the associated source code (or its instantiation). This feature gives the user direct access to the RTL regardless of its location in the file system. Direct access can be a major time saver, especially for users not intimately familiar with the entire design file structure. Any of three views of the RTL code may be selected:

The Source Code View is the default view and has an “Edit File” icon for opening an Editor panel/window where the source file may be edited using the designer's favorite editor. Zazz monitors the files being edited, and when one is saved it re-parses and elaborates the design. This feature gives the user immediate feedback on any syntax or elaboration errors.
The Processed Code View is the RTL after processing all of the text substitution macros. Macros can make significant modifications to the RTL that will be elaborated. When viewing the raw source code, determining where the macros were defined and how their definitions were changed by other macros can be very time consuming. The Processed Code View saves that time by directly showing the actual code to be elaborated.
The Elaborated Code View shows the RTL after all parameters have been resolved to their constant value. Signal widths are shown directly as a range of numbers. This negates the need to locate the assigned value of parameters in order to determine the actual width of signals. This view is especially helpful when connecting the ports of assertion checkers since the exact widths of the signals being configured is known. Knowing the exact signal widths helps prevent port size mismatch warnings later in the verification process.

In addition to the standard design hierarchy browsing, Zazz provides a powerful regular expression (regex) search of various name spaces: Module, Instance, Binding, Interface, Task, and Function. For example, when the Module name space is selected with no regex expression, Zazz displays how many modules exist in the design and allows the user to step thru them. With the Module name space selected and a search expression of “ram$” is entered, Zazz displays how many module names end in “ram”. The user may step thru the list, selecting each one in turn, with the Source panel displaying the RTL code.

The ability to find syntax or elaboration errors in real time plus the navigation features of searching the design file structure to locate the files of interest to view and/or modify can save untold hours over the life of the project. The Log panel contains links to the errors and warnings encountered. Clicking on a link changes the Log panel to a view of the source file with the error highlighted. If the Edit File icon is clicked then an Editor panel is opened with the cursor close to where the error/warning occurred. Icons in the source view in the Log panel allow the user to step to the next or previous error/warning. The Zazz front end represents a major productivity advantage for the designer even when assertion libraries are not being used.

Adding Assertion Library Checkers Zazz provides many features that allow the user to quickly describe the properties of the design using single or multiple assertion libraries. Support for a given library means that the checker code, configuration requirements and documentation are integral to and accessible via the Zazz environment. Each library supported is maintained at the latest revision level. If required, early revision levels are supported based on the need to support instrumented legacy code. As an example OVL 1.0 is supported based on legacy requirements.

Zazz has two modes of elaboration:

Full Elaboration Mode is used when all hierarchical references must be resolved prior to proceeding. This mode is the same as provided by simulators and formal verification tools.
Tolerant Elaboration Mode ignores unresolved hierarchical references.

The default is the tolerant elaboration mode. In the tolerant elaboration mode, the user can add checkers to the RTL code during development while thinking about the requirements and constraints of the design rather than stopping to fix unresolved references. These may be addressed at a more convenient time by switching to the full elaboration mode.

The four basic steps in describing and documenting a property are: checker selection, checker configuration, checker export, and verification plan export:

Checker Selection The Verification Libraries panel displays a list of all available assertion checkers. The list may be filtered by a combination of Library, Vendor Category (such as single-cycle or event-bounded), and even by regular expressions. For those not intimately familiar with the purpose of each checker, Zazz provides a brief description in the form of a mouse-over bubble text. For those needing a more detailed description, a direct link to the correct page of the vendor’s documentation is provided in the Info panel when a checker is selected from the list.
Checker Configuration Once the appropriate checker is selected and attached (bound) to the design element selected in the Design View, the checker’s parameters and ports may be configured by expanding the hierarchy under the bound checker:

Configure Parameters All checker parameters have pre-defined set of default values that Zazz displays. If the default value is correct, then no action is necessary. Many parameters have a small set of valid values. Zazz enumerates these values for easy selection via a drop-down list. Other parameters may be described by a constant expression. Zazz provides a parameter expression builder where expressions may be described with operators and a regex filtered list of parameters available in the attachment scope. All parameter expressions are dynamically parsed and elaborated so that it is not possible to proceed until a valid parameter expression is described.
Configure Ports None of the checker’s ports have pre-defined connections, although most checkers have a common set of ports, such as the clock, reset, and enable ports. Zazz provides an auto-connect feature for the common ports. It uses a least-recently-used algorithm. If another checker has been configured, then ports of the same name on new checkers will be automatically connected to the same port expression if all signals in the expression exist in the attachment scope. Zazz also provides a port expression builder where expressions may be described with operators and a regex filtered list of parameters and signals available in the attachment scope. All port expressions are dynamically parsed and elaborated so that it is not possible to proceed until a valid port expression is described.
Advanced Configuration Zazz also provides an advanced configuration window, where the user may change the instance name of the checker, add comments or descriptive text to the bind statement and Verification Plan, and utilize cross hierarchy (out of attachment scope) parameters and signals in the expressions. In the case of out of attachment scope parameters and/or signals, Zazz will automatically add the full hierarchical name. Zazz also displays the signal width of both the checker ports and the available signals.

The combination of these features results in the ability to completely describe a design property with just a few mouse clicks and key strokes. The user is able to create an accurate property description in less than a minute without ever having to type a complete signal name. The results of the preceding can then be exported as follows:

Checker Export Zazz creates bind statements guarded by a vendor– or user–defined macro. The bind statements are in the named parameter and named port format. Only parameters that have been assigned values different from the vendor’s default value will be included. Parameters are exported with the reassigned value with a comment defining its enumerated meaning. Zazz provides a bind statement management system that automates the use of multiple bind statement files. All bind statements for a module are exported in a single file named <module_name>.bind.sv located in the same directory as the module description. Every time the module description is imported, the bind file is automatically imported. This allows checkers to be added to modules one at a time, yet when the module is included in a multi-file project, the binds will be picked up automatically. It allows checker’s to be described without requiring RTL file write access. When multiple bind files are exported, a filelist containing the location of the bind files is also exported for use with other verification tools.
Verification Plan Export Zazz automatically documents all aspects of each checker’s use and configuration in the form of an “as–built” Verification Plan in html format. The user can control the verbosity of the plan. The plan can include any combination of: brief basic description, checker specific port and parameter configuration values, parameters and ports common to all checkers, included assertions, and included coverage. The verbosity control allows the user to format the plan according to their needs. This file may also be custom formatted for export directly into a structured verification plan program.

A summary of Zazz features accessed through an intuitive graphic user interface is as follows:

Quickly select an appropriate checker from one of multiple libraries.
Bind the checker to a design element selected in the Design View.
Click-to-select valid values for most checker parameters.
Click-to-select design signals to create checker port expressions.
Export the resulting bind statements for use by other verification tools.
Automatically create the design specific documentation for inclusion in a verification plan.

SEE A DEMO OF ZAZZ NOW