mentorpaper_81009

E M U L A T I O N WH

IT

EP

AP

ER

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

AJEYA PRABHAK AR, BROADCOM CORP. VIJAY CHOBISA, MENTOR GRAPHICS CORP.

LOCALIZED, SYSTEM-LEVEL PROTOCOL CHECKS AND COVERAGE CLOSURE USING VELOCE

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

w w w. m ento r.co m2

INTRODUCTIONMost, 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 system-level 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, Veloce’s 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, Veloce’s 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 COVERAGEToday’s 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.



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 they’ve 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



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 FLOWAt 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. Broadcom’s 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.



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.



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.

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

Figure 3: UCDB graphical view.

Figure 4: Assertion and coverage reports.



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.

Veloce’s 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.

Veloce’s 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.

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

Figure 5: Bandwidth on-demand.



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.



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 -sv switch. 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). Veloce’s 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.

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

Veloce’s 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

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

F o r t h e l a t e s t p r o d u c t i n f o r m a t i o n , c a l l u s o r v i s i t : w w w . m e n t o r . c o m


MGC 08-13 TECH11220-w

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.

mentorpaper_81009

Documents

Transcript of mentorpaper_81009