LOCALIZED, SYSTEM-LEVEL

PROTOCOL CHECKS AND

COVERAGE CLOSURE USING VELOCE

W H I T E P A P E R

A JEYA PRABHAK AR, BROADCOM CORP.

VIJAY CHOBISA, MENTOR GRAPHICS CORP.

w w w.m e n t o r. c o m

Localized, System-Level Protocol Checks and Coverage Closure Using Veloce

INTRODUCTION
Most, if not all, system-on-chips (SoC) are built using an increasingly large proportion of IP from different
suppliers who restrict visibility into their IP, making it difficult to debug. Low-power partitioning presents
additional verification challenges. The complexities of current system design require new, emulation-based
methodologies to attain complete verification much faster than previously possible and avoid costly respins.
Typical verification flows lack the speed and capacity to perform system-level verification, partly due to data
transfer bottlenecks between an emulator and a host workstation. Importantly, they also lack the mechanisms
to leverage the assertions and coverage effort done with simulation and formal tools (at the block and
submodule levels) in emulation (at the chip and system levels). As a consequence, there is a great deal of
redundancy among the discrete verification suites used at the different design levels, and there is a lack of
shared data to allow system integrators to focus on untested functionality. All of this makes it difficult to find
coverage holes and impedes expeditious tape outs.
Overcoming these shortcomings requires a single, scalable verification flow and a common test environment
that can be shared by designers, verification engineers, and system integrators as a design moves from the
block to the system level. It also requires a platform that supports standard languages and formats, including
the UPF. Finally, it requires sufficient transfer speeds to handle the enormous amount of assertion and
coverage data traffic between the emulator and workstation.
Assertion and coverage-based verification are integral to such a solution, and these must scale as well. This
requires the ability to simultaneously run and propagate two classes of assertions from the block to the
system level: localized checks and protocol monitors. Localized checks monitor low-level activities and capture
unexpected behaviors close to the source of a design error, in terms of both time and location. Protocol
monitors monitor traffic between blocks and identify interface issues at the system level.
For the last few years, Broadcom has been working with Mentor Graphics to develop such a unified,
scalable, verification methodology based on the Veloce emulation platform. Veloce fully supports systemlevel assertion and coverage-driven verification using real world stimulus, and it complements both
simulation and formal technologies. It enables automatic localized checks, protocol-level interface checks and
offers a Veloce VIP library of protocol monitors. As verification moves from the block to chip to system levels,
Veloces support of standard languages, protocols, formats, and the unified coverage database (UCDB) allows
users to accumulate coverage data and exclude coverage logic that has already been included by simulation
and formal techniques. This makes it easier for verification teams to find coverage holes and adjust their
verification infrastructure/stimulus to focus on untested functionality and remove redundancy in their
verification suites. Finally, Veloces patented TestBench XPress (TBX) technology provides on-demand
bandwidth to transfer vast amounts of raw coverage data between the emulator and workstation.
In order to test this new scalable test environment, Broadcom needed to make sure it was possible to
propagate assertion checkers and protocol monitors from the block to the system level. Therefore, we ran a
test case, first on a small block and then on an SoC. The Veloce-based solution successfully passed these test
cases. We will share our BFM case study in this paper.

THE NEED FOR ASSERTIONS AND COVERAGE

Todays designs have more functionality, more black-boxed IP, and shorter tape-out schedules; however, they
require even more verification than in the past. This leaves little time for verification, yet respins are more
expensive than ever. Traditional waveform-based debugging is slow and laborious, making it almost
impossible to fully verify a design within desired time schedules. There is a pressing need to increase debug
and verification productivity.

w w w. m e nto r. co m

Localized, System-Level Protocol Checks and Coverage Closure Using Veloce

The large number of IP components from both internal and external sources implies that there is limited
knowledge about the internal functionality of a significant proportion of a design. Typically, IP (from external
or internal sources) is encrypted to provide secure access for the verification team while protecting the
intellectual property. Companies may not have in-house expertise for all protocols used in the blocks they
integrate, because many IP modules come from external sources; furthermore, verification engineers usually
have little or no expertise about in-house IP.
Even when the IP has been previously verified, system integrators must ensure that all the modes of operation
in which each particular block is going to be exercised in the real world is covered, including when running
embedded software. This requires an emphasis on verification at the system level, where teams can check for
interface problems when the stimulus is driven from the software and the real environment. Simulation does
not have the capacity and performance for this level of verification.
The various designers, verification teams, and system integration teams that commonly work on a single
design have to deal with the same IP in the context of their distinctive tasks. This emphasizes the need for
better communication between designers and verification engineers in the event of unexpected behaviors or
bugs. Getting everybody on the same page when it comes to debugging and documenting the amount of
verification performed becomes an important communication and verification management issue.
A unified assertion-based flow enables information to be passed from the block to the subsystem and finally to
the system integration level. This allows teams to begin measuring verification activity and results at the block
level and share the aggregated data all the way up to the system level. Coverage and assertions play a major role
in increasing debug productivity by providing greater functional coverage and immediately informing engineers
that theyve covered a particular function without resorting to slow, traditional debug methodologies.
Assertions provide the means for highly efficient communication between the designer of an IP component
and the person verifying the system-level design. Embedding assertions in the RTL model improves the
controllability and observability of the logic design, making it easier to find deeply buried bugs during pre- and
post-silicon validation. Assertions add debug points and information that can communicate back to the
designer through the checks in the verification suite. When IPs are black boxed, as they typically are,
assertions are an effective way to observe what is going on and identify any problems.
Coverage and assertions allow verification engineers to understand low-level checks while running high-level
test benches. Coverage metrics ensure the thoroughness of verification, and they quickly pinpoint the source
of any unexpected or incorrect behavior and uncovered functionality. When assertions fire, it is easy to
localize where the problem occurred, rather than debug an entire system-level run and then try and figure
out the problem. It makes sense to put in local checks at the block or IP level, since the people writing the
code know what should happen and what should not happen.
Assertions and coverage are critical for low-power verification, as well. Broadcom designs incorporate several
power domains to reduce power consumption, creating additional design and verification complexity and
introducing difficult challenges that are relatively new to verification engineers. Low-power partitioning
creates a huge challenge with respect to powering domains off and on. This means that there are even more
opportunities for overlooking errors and implementing logic incorrectly. All of this functionality needs to be
tested in the verification cycle.
Assertions also provide increased confidence and certainty when using new standards and formats. For
example, in low-power design, the universal power format (UPF) is still being developed and is not proven.
The same applies to the synthesis tools that read the UPF file, create the power infrastructure, and implement
it in the design along with the design netlist. So it is important to make sure power management technologies

w w w. m e nto r. co m

Localized, System-Level Protocol Checks and Coverage Closure Using Veloce

are implemented correctly. Assertions and automatically generated checks provide this extra insurance by
flagging the user if an isolation cell is missing or a power domain is not properly gated.
Typically, there are four sources of assertions and coverage inserted into our designs:
1. Inline assertions supplied by designers
2. Assertions stitched by the verification team using SystemVerilog bind construct
3. Protocol monitors supplied by EDA vendors for standard bus protocols and memories, developed
internally for custom designs, or supplied by third-party IP providers
4. Automated checks added by simulation and emulation compilers

A SINGLE BLOCK TO SYSTEM-LEVEL VERIFICATION FLOW

At Broadcom, a majority of our validation takes place at the system level. In our flow, we start with simulation
then formal equivalency checking at the sub-block and block levels, followed by emulation at the block and
chip levels. Broadcoms verification environment is based on an industry standard SCE-MI, and most of our
tests are developed using C++ and SystemVerilog.
In emulation, we only want to target the cover points and checks that were not previously included, except for
scenarios that we know are difficult to cover in simulation. Because the time allocated for verification is very
short, we want to make sure that we are using that verification time efficiently by focusing on the proper
areas. Furthermore, emulators are expensive, so we do not want to waste verification cycles on redundant
verification. In many areas, Veloce made it relatively easy to adopt what is already being done at the block and
submodule level and use that in system-level emulation, establishing the block to system-level unified flow
we were after.

Figure 1: Block to system level unified flow.

w w w. m e nto r. co m

Localized, System-Level Protocol Checks and Coverage Closure Using Veloce

Because a lot of assertions are written at the block level, we wanted to propagate that effort and verification
knowledge to the system level. This means that everyone (designers, verification engineers, and system
integrators) must write the assertions and coverage in the same format. It also requires an emulator that
automatically figures out what has been covered in simulation by reading the coverage database and excluding
the covered areas. By building and sharing coverage data written in a single format, the entire verification flow is
more productive, because it is efficient and focused, delivering a faster time-to-verification closure.
Broadcom asked Mentor Graphics to make this assertion-based verification methodology possible, and we
worked with them to make it a reality. Veloce has many useful functionalities and capabilities that helped us
to accomplish this.

SINGLE ASSERTION FORMAT

Veloce supports a single format and uses the same constructs to describe assertions and coverage that can be
used at every level of the verification flow. Thus the assertions are now compatible between one environment
and another so that we can leverage what we have invested in assertions and coverage from one level to
another. This establishes a single environment from simulation, to formal, to emulation, adding and
accumulating assertions and coverage along the way.

UCDB SUPPORT
Veloce supports the standard-based UCDB and the standardized unified coverage interchange standard
(UCIS). This allowed us to accumulate coverage data from various tools, review the coverage matrix at each
stage of verification, and exclude redundant coverage.

Figure 2: A single standardized coverage database.

w w w. m e nto r. co m

Localized, System-Level Protocol Checks and Coverage Closure Using Veloce

The coverage data and assertions from simulation, formal, and previous emulation runs were merged into a
single file. This single UCDB file was viewed and analyzed using the Questa UCDB graphical viewer, allowing
us to confidently determine the amount of coverage that had been done in order to conclude if we were
ready for tape out. That decision is much easier if everything is written in one format.

Figure 3: UCDB graphical view.

Veloce generates coverage and assertion reports like those used in simulators.

Figure 4: Assertion and coverage reports.

w w w. m e nto r. co m

Localized, System-Level Protocol Checks and Coverage Closure Using Veloce

AUTOMATIC ASSERTION CHECKING

When needed, Veloce automatically adds assertion-based checks to capture unexpected behavior. Protocol
monitors to observe bus interfaces are readily available from the Veloce VIP library or developed in-house.
Veloces automated checking feature is very valuable for low-power design. As part of its low-power
verification capabilities, Veloce creates automated static and dynamic checks that flag the user if, for example,
an isolation cell is missing or a power domain is not properly gated.

HIGH-SPEED PHYSICAL LINK

For Broadcom, verification performance is critical; therefore, we do not want to compromise on performance.
Veloce dissolves the communication channel bottleneck that occurs when there is more assertion and
coverage data going from the emulator to the host PC than can be transferred between them.
Veloces high-speed PCIe-based physical link transfers data from Veloce to the host PC, offering up to 16
parallel physical channels for a 200 MG design. By offering on-demand bandwidth to transfer raw coverage
data from Veloce to a host PC, the latest Veloce release (Veloce2) allows the addition of more channels when
more bandwidth is needed for transferring data.

Figure 5: Bandwidth on-demand.

DEBUG PRODUCTIVITY
The method with which Veloce synthesizes assertions within the emulator provides an extra level of debug
productivity. It creates a signal for each assertion and then creates a single signal, which represents all the
assertions in a given module. Then it creates one final assertion that represents all the assertions in the design.
This establishes a high level of efficiency, because only one signal needs to be monitored. When an assertion
fires, Veloce provides a very efficient flow for tracing the error down from the system to the module level,
then on down to the individual assertion level.

BFM CASE STUDY

We created a flow to compile the assertions into emulation. As part of this assertion flow for Veloce, we want
to use UPF information and have power-domain verification in our system-level verification suite. We wanted
to do a case study to validate that this flow actually works; that we can read the UPF file and perform the basic
functionality testing. We wanted to first prove that we could actually emulate the assertions using assertions
in only a few blocks. Then we wanted to develop a strategy to increase the benefits and expand the use of
assertions in our verification flow.

w w w. m e nto r. co m

Localized, System-Level Protocol Checks and Coverage Closure Using Veloce

Specifically, our objective was to provide a standard set of protocol/behavior checkers to the IP teams that can
be used to verify the BFM client interfaces in our designs. The assertion set that we implemented as a part of
this particular BFM and exercise have different categories of checks:
Protocol checks, including negative checks
Command checks
Compliance checks
Coverage points
An example of an assertion we wrote looks like this:
//----------------------------// commandbus should NOT be driven unless acknowledge
//----------------------------valid_ack_to_command_delay: assert property(
@(posedge clock)
disable iff(reset)
(ack==0) |=> ##ACK_TO_COMMAND_DELAY(commandbus == 0));
//----------------------------// Raster access word aligned address
//----------------------------valid_raster_access_address: assert property(
@(posedge clock)
disable iff(reset)
($rose(raster_write_access) || $rose(raster_read_access)) |->
(commandbus[0] == b0 ));

Our strategy for expanding the use of assertions included leveraging common libraries across multiple chips.
The common libraries contain standard buses and common functions. These are the easiest assertions to
expand, because they are immediately propagated across many chips and many locations within a chip itself.
We also established a process whereby our designers and verification engineers continue to add assertions in
our designs as well as in our verification and model components. This required creating a set of guidelines
and rules on writing assertions so that communication and understanding among the various groups is
simple, straightforward, and accurate.
Five rules that we found to be very useful:
1. Label each assertion individually and descriptively this label can be used to filter expected failures, if
you need to, and is significantly clearer; e.g., acknowledge _ without _ request: assert <>
2. Associate a message with each assertion along the lines of assert <property> else
$error() ($error is just like $display except that it sets the simulation return code and halts an
interactive simulation)
3. Reduce the severity by using $warning or increase the severity by using $fatal
4. Exclude assertions that are informational in nature and occur frequently from emulation runs
5. Avoid open-ended or unbound assertions as these potentially have a very large hardware impact
These rules may look simple, but they can be extremely powerful if you add them while writing assertions,
because it tells you what is happening, where it is happening, and why it is happening.

w w w. m e nto r. co m

Localized, System-Level Protocol Checks and Coverage Closure Using Veloce

During the design phase, designers could add assertions that capture their expectations and knowledge of the
corner cases in the design. It is important that these types of assertions are added during the design phase,
because once the design is written, there is a large amount of resistance to going back and adding assertions.
During verification, debug assertions were added to help isolate failures, which simplified the debug effort.
Assertions were also used for functional coverage. Finally, when bugs were discovered and fixed in a particular
IP, we added an assertion that verified that particular fix. So when this IP is used on different chips, the
designer will know that a particular bug was fixed.
There were a couple of issues that we faced while verifying that the block-level assertions could be emulated.
We found that a big portion of IP is not SystemVerilog-compliant. For example, library cells and memory ports
carry SystemVerilog keywords, which prevent the use of SystemVerilog assertions in emulation. To get around
this issue, we recommend creating a library group to compile all standard cells and memories using
-svswitch. This switch enables the SystemVerilog compiler and flags all the SystemVerilog reserved
keywords. Additionally, we renamed the port names to avoid SystemVerilog reserved keywords, for example,
bit and do.
The other issue we found when adding assertions into emulation came up when a particular block is trying to
read or write a memory location that is outside the range of the memory. The memories in our design were
implemented as 2N size (for sizes that are not exactly 2N). Veloces check capability resolved this issue by
automatically adding assertions to the memories that fire if locations outside the memory size are accessed.
Broadcom is working with Mentor Graphics to have the SystemVerilog functional coverage supported inside
the emulator along with the RTL design. This will provide even better performance, because it dramatically
reduces the amount of coverage data transferred from the emulator to the host PC, since it is captured within
the emulator itself. We would also like to exclude covergroups already included by other verification methods,
which can be done by reading directly from the UCDB file.
Finally, it would be helpful to have a saturation counter to minimize performance and capacity impacts. This
option would allow users to specify whether they want to know if an assertion is covered once or not at all
(yes/no) or, alternatively, the number of times it was covered. If an assertion needs to be covered only once or
a relatively small number of times, the performance and capacity impacts are minimal compared to covering
the assertion a million times.

SUMMARY
As a result of the case study, we verified that assertions actually work in emulation. Then we took it to the next
level of complexity by compiling a large, system-level block that contained assertions, and we verified that it
could be emulated as well. We proved that we can take assertions, compile them into Veloce, and verify that
they fire accurately. In so doing, we were able to provide proof of concept for our primary goal: the creation of
an internal flow to go from simulation verification with assertions to Veloce emulation with assertions.
Veloces effective implementation of assertion and coverage complements the existing verification at
Broadcom and enhances our verification by focusing on untested functionality at the system level. Mentor
Graphics is working with Broadcom to generate optimized coverage data and implement an effective analysis
flow for higher productivity. Among the advantages of using Veloce today is that we can go into emulation
with the first RTL; we are able to take RTL as it is created and put that into emulation.
By providing a shared test bench between simulation and emulation, Veloce offers an easier path to
emulation. It gives us a unified test bench with similar capabilities between simulation and emulation and
supports an internal infrastructure commonly used between simulation and emulation; therefore, we can

w w w. m e nto r. co m

Localized, System-Level Protocol Checks and Coverage Closure Using Veloce

switch between them. Veloce allows us to verify software running on our chips in emulation. Embedded
software is huge and growing, and it is very difficult to verify embedded software, especially before the chip
comes back, but emulation is enabling us to do that. This is an enormous competitive advantage.
Emulation is becoming more powerful today with the acceleration of advanced verification techniques,
including support for the Universal Verification Methodology (UVM), so we can take advantage of all the
expertise and techniques embodied in that standardized methodology. Finally, because Veloce supports our
standardized SCE-MI environment, we have the flexibility to use any number of tools and IP that is most
suitable for a specific project.

For the latest product information, call us or visit:

w w w.m e n t o r. c o m

2013 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and
may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.
In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks
mentioned in this document are the trademarks of their respective owners.

MGC 08-13

TECH11220-w