Abstract
This chapter introduces the reader to the SystemVerilog Assertions language and its role under SystemVerilog IEEE-1800 umbrella and the roadblocks to design verification productivity and solutions thereof and explains SVA evolution and sets the stage for the rest of the book.
Keywords
Introduction: This chapter introduces the reader to the SystemVerilog Assertions language and its role under SystemVerilog IEEE-1800 umbrella and the roadblocks to design verification productivity and solutions thereof and explains SVA evolution and sets the stage for the rest of the book.
As is well known in the industry, the design complexity at 7 nm node and below is exploding. Small form factor requirements and conflicting demands of high performance and low power and small area result in ever so complex design architecture. Multi-core, multi-threading and Power, Performance and Area (PPA) demands exacerbate the design complexity and functional verification thereof.
The burden lies on functional and temporal domain verification to make sure that the design adheres to the specification. Not only is RTL (and Virtual Platform) functional verification important but so is silicon validation. Days when engineering teams would take months to validate the silicon in the lab are over. What can you do during pre-silicon verification to guarantee post-silicon validation a first pass success?
Note that the verification complexity applies both to ASIC designs and to FPGA designs. Specifically, FPGA designs are essentially SoC designs with multiple well-placed and routed cores in the design. The days of burn and learn strategy employed by FPGA design and verification engineers are over. In burn, the FPGA design and debug in the lab requires that the FPGA design is ready (to some extent) before you burn the FPGA. If the FPGA design was not well verified, then the debug time in lab increases exponentially. This is the reason a robust verification methodology is essential for FPGA designs as well.
The biggest challenge that the companies face is short time-to-market to deliver first pass working silicon of increasing complexity. Functional design verification is the long poll to design tape-out. Here are two key problem statements.
-
1.
Design Verification Productivity: 40–50% of project resources go to functional design verification. The chart in Fig. 1.1 shows design cost for different parts of a design cycle. As is evident, the design verification cost component is about 40+% of the total design cost. In other words, this problem states that we must increase the productivity of functional design verification and shorten the design simulate debug cover loop. This is a productivity issue, which needs to be addressed.
Continuing with the productivity issue, the chart in Fig. 1.2 shows that the compounded complexity growth rate per year is 58% while the compounded productivity growth rate is only 21%. There is a huge gap between what needs to get done and what is getting done. This is another example of why the productivity of design cycle components such as functional design verification must be improved.
-
2.
Design Coverage: The second problem statement states that more than 50% of designs require re-spin due to functional bugs. One of the factors that contribute to this is the fact that we did not objectively determine before tape-out that we had really covered the entire design space with our test-bench. The motto “If it’s not verified, it will not work” seems to have taken hold in design cycle. Not knowing if you have indeed covered the entire design space is the real culprit towards escaped bugs and functional silicon failures.
So, what’s the solution to each problem statement?
-
1.
Increase Design Verification Productivity.
-
(a)
Reduce Time to Develop.
-
Raise abstraction level of tests. Use TLM (Transaction Level Modeling) methodologies such as UVM and SystemVerilog/C++/DPI. The higher the abstraction level, easier it is to model and maintain verification logic. Modification and debug of transaction level logic is much easier, further reducing time to develop test-bench, reference models (scoreboard), peripheral models, and other such verification logic.
-
Use constrained random verification (CRV) methodologies to reach exhaustive coverage with fewer tests. Fewer tests mean less time to develop and debug.
-
Develop Verification Components (UVM agents, for example that are reusable). Make them parameterized for adoptability in future projects.
-
Use System Verilog Assertions to reduce time to develop complex temporal domain and combinatorial checks. As we will see, assertions are intuitive and much simpler to model, especially for complex sequential (temporal domain) checks. SystemVerilog code for a given assertion will be much lengthier, hard to model, and hard to debug. SVA indeed reduces time to develop and debug.
-
-
(b)
Reduce Time to Simulate.
-
Again, higher level of abstraction simulates much faster than pure RTL test bench which is modeled at signal level. Use transaction level test bench.
-
Use System Verilog Assertions to directly point to the root cause of a bug. This reduces the simulate debug verify loop time. Debugging the design is time consuming as is, but not knowing where the bug is, and trial and error simulations further exacerbate the already lengthy simulation time.
-
-
(c)
Reduce Time to Debug.
-
Use System Verilog Assertion Based Verification (ABV) methodology to quickly reach to the source of the bug. As we will see, assertions are placed at various places in design to catch bugs where they occur. Traditional way of debug is at IO level. You see the effect of a bug at primary output. You then trace back from primary output until you find the cause of the bug resulting in lengthy debug time. In contrast, an SVA assertion points directly at the source of the failure (for example, a FIFO assertion will point directly to the FIFO condition that failed and right away help with debug of the failure) drastically reducing the debug effort.
-
Use Transaction level methodologies to reduce debugging effort (and not get bogged down into signal level granularity).
-
Constraint Random Verification allows for fewer tests. They also narrow down the cone of logic to debug. CRV indeed reduces time to debug.
-
-
(a)
-
2.
Reduce Time to Cover and build confidence in taping out a fully verified design.
-
(a)
Use “cover” feature of SystemVerilog Assertions to cover complex temporal domain specification of your design. As we will see further in the book, “cover” helps with making sure that you have exercised low-level temporal domain conditions with your test-bench. If an assertion does not fire, that does not necessarily mean that there is no bug. One of the reasons for an assertion to not fire is that you probably never really stimulated the required condition (antecedent) in the first place. If you do not stimulate a condition, how would you know if there is indeed a bug in the design logic under simulation? “cover” helps you determine if you have indeed exercised the required temporal domain condition. More on this can be seen in later chapters.
-
(b)
Use SystemVerilog Functional Coverage language to measure the “intent” of the design. How well have your test bench verified the “intent” of the design. For example, have you verified all transition of Write/Read/Snoop on the bus? Have you verified that a CPU1-snoop occurs to the same line at the same time that a CPU2-write invalid occurs to the same line? Code Coverage will not help with this. We will cover Functional Coverage in plenty detail in the book.
-
(c)
Use Code Coverage to cover structural coverage (yes, code coverage is still important as the first line of defense even though it simply provides structural coverage). As we will see in detail in the section on SV Functional Coverage, structural coverage does not verify the intent of the design, it simply sees that the code that you have written has been exercised (e.g., if you have verified all “case” items of a “case” statement, or toggled all possible assigns, expressions, states, etc.). Nonetheless, code coverage is still important as a starting point to measure coverage of the design.
-
(a)
As you notice from above analysis, SystemVerilog Assertions and Functional Coverage play a key role in about every aspect of Functional Verification. Note that in this book, I use Functional Verification to include both the “function” domain functional coverage and the “temporal” domain functional coverage.
1.1 How Will This Book Help You?
This book will go systematically through each of SystemVerilog Assertions (SVA) and Functional Coverage (FC) language features and methodology components with practical applications at each step. These applications are modeled such that you should be able to use them in your design with minimal modifications. The book is organized using power point style slides and talking points to make it very easy to grasp the key fundamentals. Advanced applications are given for those users who are familiar with the basics. For most part, the book concentrates on the in-depth discussion of the features of the languages and shows examples that make the feature easily understandable and applicable. Simulation logs are frequently used to make it easier to understand the underlying concepts of a feature or method.
The book is written by a design engineer for (mainly) design and verification engineers with the intent to make the languages easy to grasp avoiding decipher of lengthy verbose descriptions. The author has been in System and Chip design field for over 20 years and knows the importance of learning new languages and methodologies in shortest possible time to be productive.
The book concentrates on SVA features of the IEEE 1800–2005 standard. Author believes that the features of this standard are plenty to designing practical assertions for the reader’s project(s). However, the author has indeed covered the entire IEEE 1800–2009/2012 feature set in a standalone chapter (Chap. 20) to give an in-depth look at the new standard. Note that some of the 2009/2012 features were not supported by popular simulators as of this writing and the examples provided were not simulated. Please do send your suggestions/corrections to the author (ashok_mehta@yahoo.com).
1.2 SystemVerilog Assertions and Functional Coverage Under IEEE 1800 SystemVerilog Umbrella
SystemVerilog assertions (SVA) and Functional Coverage (FC) are part of IEEE 1800 SystemVerilog standard. In other words, SVA and FC are two of the four distinct language subsets that fall under the SystemVerilog umbrella.
-
1.
SystemVerilog Object Oriented language for functional verification (using UVM style libraries).
-
2.
SystemVerilog language for Design.
-
3.
SystemVerilog Assertions (SVA) language.
-
4.
SystemVerilog Functional Coverage (FC) language to see that the verification environment/test-bench have fully verified your design.
As shown in Fig. 1.3, SVA and FC are two of the important language subsets of SystemVerilog. Note that SystemVerilog assertions is orthogonal to OOP, UVM and Functional Coverage languages. In other words, SVA has its own syntax and semantics. In yet more words, knowledge of OOP/UVM does not mean you know SVA. It’s a distinct language that needs to be learnt on its own. You can deploy assertions without the knowledge of OOP or UVM. The same applies to Functional Coverage language. It is orthogonal to SVA and OOP/UVM. The Functional Coverage language stands alone and needs to be learnt on its own. Albeit, once you learn Functional Coverage language, you can then use it in Class based OOP subset of SystemVerilog.
In any design, there are three main components of verification: (1) Stimulus Generators to stimulate the design, (2) Response Checkers to see that the device adheres to the device specifications, and (3) Coverage components to see that we have indeed structurally and functionally covered everything in the DUT according to the device specifications.
-
1.
Stimulus Generation: This entails creating different ways in which a DUT needs to be exercised. For example, a peripheral (e.g., USB) maybe modeled as a Bus Functional Mode (or a UVM (Universal Verification Methodology) agent) to drive traffic through SystemVerilog transactions to the DUT. Different techniques are deployed to achieve exhaustive coverage of the design. For example, constrained random, transaction based, UVM based, memory based, etc. These topics are beyond the scope of this book.
-
2.
Response checking: Now that you have stimulated the DUT, you need to make sure that the device has responded to that stimulus according to the device specs. Here is where SVA comes into picture along with UVM monitors, scoreboards, and other such techniques. SVA will check to see that the design not only meets high-level specifications but also low-level combinatorial and temporal design rules.
-
3.
Functional Coverage: How do we know that we have exercised everything that the device specification dictates? Code Coverage is one measure. But code coverage is only structural. For example, it will point out if a conditional has been exercised. But code coverage has no idea if the conditional itself is correct, which is where Functional Coverage comes into picture (more on this later when we discuss Functional Coverage—See chapter (Chap. 25 Functional Coverage). Functional coverage gives an objective measure of the design coverage (e.g., have we verified all different cache access transitions (for example, write followed by read from the same address) to L2 from CPU? Code Coverage will not give such measure). We will discuss entire coverage methodology in detail in Chap. 25.
1.3 SystemVerilog Assertions Evolution
To set the stage, here is a brief history of Verilog to SystemVerilog evolution (Figs. 1.4 and 1.5). Starting with Verilog 95, we reached Verilog 2001 with Multi-dimensional arrays and auto variables, among other useful features. Meanwhile, functional verification was eating up ever more resources of a given project. Everyone had disparate functional verification environments and methodologies around Verilog. This was no longer feasible.
Industry recognized the need for a standard language that allowed the design and verification of a device and a methodology around which reusable components can be built avoiding multi-language cumbersome environments. Enter Superlog, which was a language with high-level constructs required for functional verification. Superlog was donated (along with other language subset donations) to create SystemVerilog 3.0 from which evolved SystemVerilog 3.1, which added new features for design but over 80% of the new language subset was dedicated to functional verification. We can only thank the Superlog inventor (the same inventor as that for Verilog—namely, Phil Moorby) and the Accelera technical subcommittees for having a long-term vision to design such a robust all-encompassing language. No multi-language solutions were required any more. No more reinventing of the wheel with each project was required anymore.
As shown in Fig. 1.5, SystemVerilog Assertion language is derived from many different languages. Features from these languages either influenced the language or were directly used as part of the language syntax/semantic.
Sugar from IBM led to PSL. Both contributed to SVA. The other languages that contributed are Vera, “e,” CBV from Motorola, and ForSpec from Intel.
In short, when we use SystemVerilog Assertions language, we have the benefit of using the latest evolution of an assertions language that benefited from many other robust assertions languages.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2020 Springer Nature Switzerland AG
About this chapter
Cite this chapter
Mehta, A.B. (2020). Introduction. In: System Verilog Assertions and Functional Coverage. Springer, Cham. https://doi.org/10.1007/978-3-030-24737-9_1
Download citation
DOI: https://doi.org/10.1007/978-3-030-24737-9_1
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-030-24736-2
Online ISBN: 978-3-030-24737-9
eBook Packages: EngineeringEngineering (R0)