Introduction - SVA: The Power of Assertions in SystemVerilog - page 8

Assertions Are Part of Design Documentation

Traditionally, design documentation at any level consists of two parts. One
is a stand-alone specification in a natural language, outside the domain of
SystemVerilog. The other is a set of comments spread throughout the code in
SystemVerilog. Neither of these specifications has any executable impact on
the behavior of the design. That is, the behavior shown by the interpretation of
SystemVerilog code does not necessarily correlate with the documented comments
or outside specifications. Another commonly experienced pitfall is the enduring
burden to keep the documentation up to date as the SystemVerilog design code
matures and evolves over the life of a project.
Assertions, on the contrary, are executable statements that check the behavior of
the design, no matter at what stage the design is being interpreted. This enforces the
stipulation that assertions must change in accordance with the changes in the design,
so there is no additional undertaking. As the design progresses, the assertions get
updated to comply with the changes, thereby maintaining the documentation aspect
of the design as well. Any laxness in the process gets caught by an assertion
failure, which must be corrected to move forward. Writing formal specifications
in SVA is not always an easy task, but it usually pays off because it leads to better
understanding of the design, better design quality, and better documentation.

1.2 Assertions in Design Methodology

Assertions are an important part of the design and verification flow. This section
discusses the use of assertions at various stages of the flow.
Figure 1.5 depicts a block diagram of a typical design and verification flow. The
stages in the flow less relevant to assertions are omitted from this block diagram.
Usually, at the project inception hardware designers or architects write a product
specification in a natural language, for example, in English. Based on the product
specification, a high-level architectural model [ 43 ] is created in languages such as
SystemVerilog or SystemC [ 7 ]. This architectural model may not be anchored with
an accurate model of the design clock cycle; rather, it models functionality at a high
level. The objective is to develop an efficient architecture by performing tradeoff
analysis for time and area estimates, physical and power domain partitioning,
input/output port definitions, etc.
Once an architecture is determined from the high level analysis, the architectural
model is taken as the basis for developing a clock cycle accurate RTL model.
Ultimately, this model evolves into a stable base for driving synthesis and physical
design. In many organizations, the RTL model is considered the golden reference for
the design. This dictates that the model be maintained and updated with any changes
to the design. The RTL model is then synthesized automatically or manually into
a gate or a transistor level with a netlist that specifies the connectivity [ 56 ]. This
synthesized netlist is processed further by place and route tools to physically place