Every engineer knows that system-on-a-chip (SoC)

System Verilog digital SystemVerilog Assertions and Functional Coverage Support Advanced Verification Every engineer knows that system-on-a-chip (SoC) verification is hard. Several widely cited studies have concluded that functional verification consumes 60% to 80% of the resources during the register-transfer-level (RTL) phase of a typical SoC project. It s quite common for development teams to have more verification engineers than designers sometimes double the number. The situation only gets worse as SoC designs grow in size and complexity. For a better chance of first-silicon success, verification engineers have turned to a wide variety of advanced techniques. Nearly all of these approaches are based upon three concepts that lie at the very heart of SoC functional verification: assertions, coverage, and constraints. The ability to specify these three items during the design and verification process is key for the success of SoC projects. Modern verification languages, such as e, provide built-in constructs to express assertions, functional-coverage points, and constraints. The vast experience gained from these languages was leveraged in the development of SystemVerilog, the successor to the widely used Verilog hardware design language. SystemVerilog, which is standardized as IEEE Std. 1800-2005, contains many of the essential verification-related features that are familiar to advanced-verification teams. Specifically, SystemVerilog has the following: intrinsic constructs for the specification of assertions to capture design intent; functional-coverage points to measure verification progress; and constraints to automate stimulus generation. This article focuses on the SystemVerilog constructs for assertions and functional coverage. It describes their verification planning. The article has three primary goals: to introduce the concepts of assertions and functional coverage to engineers who aren t already making use of them; to show specifically how SystemVerilog supports their specification; and to outline the impact that their use has on the verification planning process. Introduction to Assertions The concept of assertions has been around for a long time especially in the software world. Essentially, any engineer who has ever written a line of C to print out an error message about a detected internal inconsistency has written an assertion. Including assertions in code is very good practice. While it may be embarrassing to report errors to the users of a program, it is far better than continuing and possibly delivering incorrect results. By Tom Anderson RTL is, of course, just another form of code (specifying hardware rather than software). Thus, it isn t surprising that assertions also have become popular in the world of SoC design. Even before languages like SystemVerilog and PSL (IEEE Std. 1850-2005) provided built-in assertion constructs, designers and verification engineers would sometimes include code to check for unexpected conditions and generate a message. As shown in Figure 1, assertions document design intent for the inputs and outputs of a block as well as for the block s internal behavior. Assertions that reference only the block I/O are black-box, as they don t depend on internal implementation. End-to-end assertions specify behavior from the inputs to the outputs end to end. They then relate the expected results on the outputs to the values on the inputs. Assertions that reference internal design structures are white-box. They re tied to the RTL implementation. Figure 1: Assertions document design intent. Assertions that specify input or output protocols reflect not just a single block, but rather the interaction between the block and its neighbors. Output assertions check that the results from the block agree with what is expected by the other blocks receiving the output signals. Conversely, input assertions represent the range of inputs for which the block is designed. They screen out illegal inputs from other blocks. Input assertions are especially important for formal analysis, which can be applied to the block before any testbench or tests have been written. As shown in Figure 2, input assertions are treated as constraints. This ensures that formal analysis considers only legal input combinations. A problem detected by using illegal inputs is generally not of interest to the designer. Usually, it isn t a true design bug. 20 June / July 2007 Chip Design www.chipdesignmag.com

in block-level formal analysis and simulation also run unchanged in full-chip testbench simulation. Chip-level assertions provide two valuable results: faster bug isolation and more thorough verification. digital Figure 2: Assertions enable formal analysis. System Verilog For each assertion that isn t converted to a constraint, formal analysis tries to either prove that the assertion can never be violated or generate a counter-example showing how a violation can occur. Some formal tools can generate the counter-example as a test case. This test case can be run in simulation. Or it can directly support the use of simulation debuggers. The bug causing the assertion violation can then be diagnosed in a familiar environment. Although many types of blocks can be completely verified by formal analysis, this isn t required by assertion-based verification. Some types of design intent may be easier to check in a traditional simulation testbench than with assertions. As shown in Figure 3, assertions add value in block-level testbench simulation as well as in formal analysis. Figure 4: Assertions in chip-level simulation are shown here. A bug buried deep inside a block can take literally thousands of cycles to propagate its effects to the chip output and be detected in the testbench. If an assertion catches this bug at its source, diagnosis time is reduced from hours or even days down to minutes. Furthermore, assertions sometimes detect bugs that would ve been missed by the testbench perhaps because the simulation test stopped before bug effects reached the outputs. Reducing their debug time and effort during the verification process is a major benefit for designers. It more than offsets the time that they spend to specify assertions. The designers also benefit from assertions placed on the inputs to their blocks. These assertions serve as screens to catch input values or sequences for which the blocks weren t designed. In chip-level simulations, violations of such assertions indicate disagreements over shared interfaces of adjoining blocks. As a result, designers don t waste time debugging problems when their colleagues don t follow the specified input protocols. Figure 3: This graphic shows assertions in block-level simulation. Most block-level testbenches are developed by designers, who generally don t use high-level verification techniques like objectoriented programming and constrained-random stimulus generation. The assertions therefore provide additional checking beyond the relatively simple testbenches created by designers. Assertions in simulation report any violations as they occur, making it quick and easy to diagnose design bugs. Although testbenches at the SoC level tend to be more sophisticated than for individual blocks, it s still important to run assertions. As shown in Figure 4, the same assertions used Finally, assertions have tremendous value beyond simulation. Some acceleration and emulation platforms provide the facility to compile assertions into the hardware. They provide checking during tests, such as booting an operating system. In rare cases, designers may even turn some assertions into hardware checks built into the final SoC. SystemVerilog Assertions The value of assertions in RTL had been well documented prior to the SystemVerilog definition effort within Accellera. The standards team wisely chose to make assertions a key part of the language. The SystemVerilog-assertion (SVA) subset provides a rich set of constructs to specify properties and sequences as building blocks for complex assertions. The assert construct is used to specify assertions. The assume construct is used to specify assumptions, which are typically properties on the design inputs. Chip Design www.chipdesignmag.com June / July 2007 21

System Verilog digital The syntax of simple assertions looks much like traditional Verilog. The FIFO overflow assertion mentioned in the last section might be written as follows: assert_no_underflow: assert property (@(posedge clk)!(fifo_read && fifo_empty && rst_n)); This assertion, named assert_no_overflow by the designer, reports a violation when the FIFO write signal and FIFO full signal are both active. This check is performed only when the reset signal is inactive and only on the clock s rising edge. Transient signal changes are therefore not considered. This is a good example of an assertion with high value in chip-level simulation. The FIFO bug can be detected when it occurs instead of when the corrupted data reaches the testbench checkers perhaps hundreds of cycles later. SystemVerilog assertions can be quite complex especially when sequences of signal values over multiple cycles are involved. A request-acknowledge handshake is a simple example of a sequence. A typical assertion might be whenever req is active, then ack must be active between 1 and 4 cycles later. This might be expressed by the following: assert_req_ack: assert property (@(posedge clk) disable iff(!rst_n) (req => ##[1:4] ack )); The assertion uses the => implication operator to indicate that an active request signal implies a later activation of the acknowledge signal. It also uses a disabling condition to suppress the assertion when the reset is active. Most assertions shouldn t be checked during reset. In addition, some types of assertions might not be applicable during SoC configuration and initialization. One of SVA s unique features is the action block. It allows a task to be specified for execution in the event of assertion pass or failure. For example, in this arbiter assertion: assert_unique_grant: assert property (@(posedge clk)!(grant_master_1 && grant_master_2 && rst_n)) else error_report_task; SVA provides many additional features for assertion specification including the ability to define local variables that are only valid within an assertion specification. It also provides liveness assertions in which something should eventually happen with no strict time bound. Some of these features aren t supported in all formal-analysis tools. SystemVerilog allows assertions to be placed directly in the RTL. It therefore takes advantage of the context of the surrounding code. Generally, designers like to specify their assertions in-line as they write their code. Verification engineers may not have permission to change the RTL, as they re more likely to place any additional assertions in the testbench. The SystemVerilog bind construct enables assertions to be placed in an entirely separate file, which is useful for encapsulating assertions to be reused on multiple projects. Introduction to Functional Coverage Regardless of the verification tools and techniques used on an SoC project, the development team needs a way to gauge progress. In the days of hand-written simulation tests, this determination was made with a simple test plan. The verification team would extract each major feature from the design specification, list the tests needed for each feature, write and debug the tests, and track progress against the list. Now that constrained-random simulation is the preferred method to generate stimulus for SoC projects, there s no longer a clear correspondence between features and tests. A single constrained-random run can exercise many different areas of the design. Plus, it can be hard for the verification team to determine what precisely is being verified by each test run. The best way to determine this is through the use of functional-coverage metrics. Here, important corner-case behavior is specified by the design and verification engineers and tracked over the course of the project to be sure that it is exercised. Verification languages provide three general types of functionalcoverage specification. The simplest category is functionalcoverage points consisting of signals, expressions, or sequences that must be exercised for thorough verification. In some cases, the signals or expressions may take on a wide range of values. It s therefore useful to define coverage groups with bins or buckets for different value ranges. Finally, cross coverage combines coverage groups to track all pair-wise combinations between the two groups. SystemVerilog Functional Coverage As with assertions, the SystemVerilog standards team knew the value of functional coverage from experiences with verification languages. They decided that similar features were needed. SystemVerilog provides three basic ways to specify functional-coverage points: the cover property, covergroup, and cross constructs. Specifying a coverage property is very similar to specifying an assertion. In fact, cover property is technically part of the SVA subset. Assertion languages also are very good for specifying coverage points. SVA therefore uses the same building blocks 22 June / July 2007 Chip Design www.chipdesignmag.com

of sequences and properties for coverage as well as assertions. For example, the verification team might want to ensure that the two extremes (1 and 4 cycles) of the previously shown requestacknowledge handshake assertion are hit: minimum_grant: cover property (@(posedge clk) (req ##1 ack )); maximum_grant: cover property (@(posedge clk) (req ##4 ack )); The cover-property approach works well for defining individual coverage points. But there are times when coverage groups might be more appropriate. SystemVerilog provides the covergroup construct, which isn t part of SVA, to do this. The verification team for a network interface might want to track the payload size of incoming packets, for example, and ensure that the corner cases of empty, minimum, and maximum payloads are covered: The SystemVerilog functional-coverage constructs are designed to be used either in the testbench or within the design RTL. Yet not all simulators and formal tools provide support for all forms of coverage specification. Cover property is probably used mostly in the RTL while covergroup and cross are currently used in testbench code. As tool support expands, however, this is likely to change. SystemVerilog functional-coverage metrics can be gathered during any simulation run. As shown in Figure 5, functional coverage complements assertions by ensuring that important behavior is exercised at the same time that the assertions are being checked. Verification engineers stress that hitting all of the coverage goals while all assertions and other checkers pass is the key to completing the functional-verification process. digital System Verilog covergroup payloads_seen (@(packet_received); coverpoint payload_size { bins empty = { 0 }; bins minimum = { 1 }; bins maximum= { 255 }; bins others = default; } endgroup : payloads_seen SystemVerilog also provides the cross construct to offer cross coverage between two coverage points. The following specifies an enumerated type for three packet types defined for the interface. It adds a coverpoint to track the packet types and crosses the packet types with the payload sizes: enum { read, write, control } packet_type; covergroup packets_seen (@(packet_received); coverpoint payload_size { bins empty = { 0 }; bins minimum = { 1 }; bins maximum= { 255 }; bins others = default; } coverpoint packet_type; cross payload_size, packet_type; endgroup : packets_seen In general, the SystemVerilog cover-property construct is used whenever an expression or sequence is the best way to define the coverage point. The coverpoint construct is ideal when binning is required. For its part, covergroup collects together multiple coverage points that should be sampled at the same time. Figure 5: Functional coverage is depicted in the testbench. If the chosen formal-analysis tool can handle at least some types of SystemVerilog functional coverage, it can add significant value to the verification process. If formal analysis shows that a coverage point can never be reached, this result should be examined carefully. It s possible that a design bug is preventing the exercise of intended behavior. If formal analysis generates an input sequence that reaches a coverage point that isn t yet exercised in simulation, this can be a useful guidance for writing a directed test or modifying the constrained-random stimulus. As previously noted, one of the key motivations for specifying functional-coverage points is to measure what s being verified by constrained-random-stimulus test runs. Because there s no longer a clear correspondence between features and tests, the traditional test plan doesn t suffice. Instead, a modern verification plan establishes a correspondence between features and coverage points possibly one for one. Some verification plans specify assertions as well as coverage points. Maximum benefit from a verification plan and coverage metrics is achieved when they re linked together by a verification planning tool. The verification engineers can define the features, coverage points, assertions, module mappings, and other information Chip Design www.chipdesignmag.com June / July 2007 23

System Verilog digital directly in the tool rather than on a spreadsheet or paper document. The automated verification plan can then become an integral part of the tool flow and methodology. As coverage (and assertion) results are gathered and merged, the information can be reported against the verification plan. The verification team and management that must make the tape-out decision can then view the coverage metrics against the original feature list. Only when all of the features have been fully covered should taping out be considered. Bug discovery rate and other metrics also factor into the decision, however. For any chance at first-silicon success, the size and complexity of today s SoCs demand advanced verification methods, an effective verification planning process, and a solid verification methodology. Constrained-random stimulus generation, assertions in simulation and formal analysis, thorough functional coverage, and a coverage-driven verification process are all proven techniques to help achieve this goal. SystemVerilog has all of the constructs and features necessary to support these advanced verification approaches. On top of its many RTL features, it has powerful assertion-specification capabilities and functional-coverage support. These aspects leverage many years of experience with hardware verification languages. Incorporating these capabilities into the verification planning process from the very beginning enables a highly effective, coverage-driven verification process from plan to closure. The combination of SystemVerilog and solid plan-to-closure methodology reduces the overall time and effort for functional verification while improving design quality all using quantifiable metrics. The likelihood for an on-schedule first-silicon production shipment is therefore increased as is the commercial success of SoCs and the products that they make possible. Thomas L. Anderson is a Product Marketing Director at Cadence, where his responsibilities encompass formal analysis, assertion-based verification, and SystemVerilog. He has presented more than 100 conference talks and published more than 150 papers and technical articles, and holds an MS in Electrical Engineering and Computer Science from MIT and a BS in Computer Systems Engineering from the University of Massachusetts at Amherst. 24 June / July 2007 Chip Design www.chipdesignmag.com