AutoSVA: Democratizing Formal Verification of

RTL Module Interactions

Marcelo Orenes-Vera, Aninda Manocha, David Wentzlaff and Margaret Martonosi
Department of Computer Science and Electrical Engineering, Princeton University
Princeton, New Jersey, USA
2021 58th ACM/IEEE Design Automation Conference (DAC) | 978-1-6654-3274-0/21/$31.00 ©2021 IEEE | DOI: 10.1109/DAC18074.2021.9586118

Email: {movera, amanocha, wentzlaf, mrm}@princeton.edu

Abstract—Modern SoC design relies on the ability to separately Ariane Core OpenPiton Tile
verify IP blocks relative to their own specifications. Formal lsu_load LSU L1-I$
Issue L2$
verification (FV) using SystemVerilog Assertions (SVA) is an NoC L1.5$
stage slice
effective method to exhaustively verify blocks at unit-level. Unfor- lsu_store L1-D$
MMU
tunately, FV has a steep learning curve and requires engineering
effort that discourages hardware designers from using it during Fig. 1. Heterogeneous SoCs such as OpenPiton+Ariane, involve dependencies between
RTL module development. We propose AutoSVA, a framework modules. Verifying these interactions is critical to guarantee forward progress in the
system. For example, a load request to the LSU (blue) must receive a response for a
to automatically generate FV testbenches that verify liveness memory request to eventually complete.
and safety of control logic involved in module interactions. We
demonstrate AutoSVA’s effectiveness and efficiency on deadlock- via different mechanisms, a common design pattern across
critical modules of widely-used open-source hardware projects. many of them is request and response. We advocate for
Index Terms—automatic, modular, formal, verification, SVA automatic support of FV for this pattern. (2) Capturing the
request/response abstraction in a model allows for automated
I. I NTRODUCTION reasoning about RTL interfaces and their expected interac-
Heterogeneous SoC design is a lengthy, expensive process tions. This work proposes a language centered around a
that necessitates verification at early stages of development to transaction model. This model’s applicability is not limited to
avoid late bug fixes that thwart performance or area goals [15]. modules with explicit requests/responses; it can express other
SoC modules may be developed in various contexts and exhibit interface mechanisms, e.g. pipeline stages that receive requests
complicated interactions [3]. With the numerous dependencies from a previous stage and send them to the next stage.
that occur between them, module interface verification is Approach: Given our observations, this work proposes
necessary to prevent opportunities for livelock and deadlock. AutoSVA, a framework to automatically generate Formal
Fig. 1 presents the Ariane core [1] and the cache hierarchy of verification Testbenches (FT) for a given DUT. The designer
the OpenPiton manycore [2], used as an example throughout of the DUT only needs to identify relevant transactions and
the paper. Among the module interactions, the Load-Store Unit annotate them in the module interface using a simple lan-
(LSU) is critical for the forward progress of the system. guage. The framework then generates properties that verify
SystemVerilog Assertions (SVA) [11] is often used for RTL the transactions are well-formed and make forward-progress:
verification because it is a powerful language for defining a de- they satisfy liveness (every request is eventually followed
sign’s properties and specifying temporal dependencies. SVA by a response) and safety (expectations for attributes of the
properties can be checked through both test-driven simulation response). Through its automated reasoning, AutoSVA creates
and Formal Verification (FV) in order to reveal bugs. However, the necessary scaffolding code to express these properties and
only FV tools can exhaustively test a given Design-Under- tool-specific commands to drive the FV process, alleviating
Test (DUT) and consequently are most suitable for verifying the hardware designer from significant engineering effort and
forward progress [6], [18]. Unfortunately, these tools present a democratizing the use of FV for verifying forward progress.
steep learning curve and require significant engineering effort FTs generated by AutoSVA can then be supplied to a
to set up a useful FV testbench, i.e. writing appropriate proper- FV tool, e.g. JasperGold [6] or the open-source SymbiYosys
ties and specification constraints. This upfront knowledge and tool [18]. AutoSVA thereby provides a frontend for automatic
effort discourages hardware designers from using FV [16]. FV of an important subset of the correctness problem—
Some tools generate SVA from a higher abstraction layer [10], ensuring RTL modules’ interface expectations.
[12], but creating a high-level model and mapping it to RTL Our main contributions are:
signals is still cumbersome. These tools also do not cover • A language that creates a unified transaction abstraction
important properties like forward progress. to denote RTL interface interactions and dependencies.
With the goal of making FV agile and widely used among This enables automatic reasoning about RTL properties.
hardware designers, we make two key observations: (1) Al- • An automated procedure to generate FTs that express
though interactions between RTL modules may take place liveness properties about transaction temporal dependen-
cies and safety properties about control-logic attributes.

978-1-6654-3274-0/21/$31.00 ©2021 IEEE 535

Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on May 01,2022 at 14:31:41 UTC from IEEE Xplore. Restrictions apply.
reg [TRANS_WIDTH-1:0] lsu_load_transid_sampled; /*AUTOSVA
wire lsu_req_hsk = lsu_req_val && lsu_req_rdy; lsu_load: lsu_req -in> lsu_res
wire lsu_load_set = lsu_req_hsk && lsu_req_transid == symb_lsu_transid; lsu_req_val = lsu_valid_i && fu_data_i.fu == LOAD
wire lsu_load_response = lsu_res_val && lsu_res_transid ==symb_lsu_transid lsu_req_rdy = lsu_ready_o
always_ff @(posedge clk_i or negedge rst_ni) begin [TRANS_ID_BITS-1:0] lsu_req_transid = fu_data_i.trans_id
if(!rst_ni) //counting transaction [CTRL_BITS-1:0] lsu_req_stable = {fu_data_i.trans_id,fu_data_i.fu}
lsu_load_sampled <= '0; lsu_res_val = load_valid_o
end else if (lsu_load_set || lsu_load_response) [TRANS_ID_BITS-1:0] lsu_res_transid = load_trans_id_o
lsu_load_sampled <= lsu_load_sampled + lsu_load_set - lsu_load_response */
end
co__lsu_request_happens: cover property (lsu_load_sampled > 0);
Fig. 3. The LSU designer only needs to annotate the RTL interface using AutoSVA’s
// Assume that a transaction is stable until acknowledged
language to generate a FT (containing among other things the properties and modeling
am__lsu_load_stability: assume property (lsu_req_val && !lsu_req_rdy |=> code shown in Fig. 2). The first line describes a relation between a request (italic blue)
$stable({lsu_req_stable}) ); and a response (italic green) interface; the remaining lines map RTL interface signals to
// Assert that if a valid transaction then eventually is ack'ed or dropped transaction attributes (bold).
as__lsu_load_hsk_or_drop: assert property (lsu_req_val |->
s_eventually(!lsu_req_val || lsu_req_rdy));
//Assert that every request has response, and every response had a request
(CEX) that highlights the violation of a property, or proof that
as__lsu_load_eventual_response: assert property (lsu_load_set |-> properties hold, i.e. the solver converges and finds no CEXs.
s_eventually(lsu_load_response)));
The underlying dynamics of FV and SVA make it difficult to
as__lsu_load_had_a_request: assert property (lsu_load_response |->
lsu_load_set || lsu_load_sampled > 0); intuitively understand the consequences of various properties
expressed, such as the behavior of symbolic variables, e.g.
Fig. 2. To verify the load interface of the LSU, a hardware designer would need to write
many SVA properties and auxiliary code. AutoSVA automatically generates all modeling, symb lsu transid in Fig. 2, which allow the tracking of
removing the burden from the designer. indices with a single assertion. Furthermore, subtle mistakes
in assumptions, e.g. using the |−> implication symbol in the
• Demonstration of AutoSVA’s effectiveness on 7 control- lsu stability assumption, can over-constrain the state space
critical RTL modules of the widely-used open-source and end up proving vacuity. Manually inserting assertions
projects Ariane and OpenPiton [1], [2]. As one example, can be cumbersome and error-prone for a hardware designer,
within 1 hour, AutoSVA generated a FT for Ariane’s and particularly frustrating when CEXs appear due to illegal
MMU, discovered a bug, and verified the bug-fix. inputs of not yet modeled interfaces [9]. Thus, AutoSVA
II. M OTIVATING E XAMPLE automatically models and expresses the expected behavior for
module transactions.
SVA is SystemVerilog’s formal specification language [11],
Hardware designers can employ SVA properties for Test-
and offers a mature approach for verifying RTL. It can express
Driven-Development (TDD), where CEXs help to refine the
Linear Temporal Logic (LTL) formulas over interface signals
design [17]. Moreover, this can be applied at early stages
to build properties about module interactions. LTL specifies
of RTL module development by using unit-level FV [5].
temporal relations, which fall into two major classes: safety
However, FV’s steep learning curve and necessary engineer-
and liveness properties. Safety properties specify that “nothing
ing effort preclude designers from using it in practice [16].
bad will happen”, e.g. a response must have had a request;
AutoSVA democratizes FV for hardware designers and
while liveness specify that “something good will happen”, e.g.
makes TDD practical by automating a key component of
a request is eventually acknowledged.
the FV problem: liveness and safety of module interfaces.
Fig. 2 presents a subset of the modeling and properties
Instead of aiming to support functional FV, which is very
that are necessary to verify forward progress for the load-
implementation-dependent, AutoSVA focuses on verifying that
store unit (LSU) in Ariane (depicted in Fig. 6). For example,
modules interact through well-formed transactions. This verifi-
lsu load eventual response is a liveness property to check
cation entails checking certain attributes over the control logic
that any load request eventually receives a response with
involved in transactions and mapping them to properties that
the same transaction ID. Verifying expectations about module
ensure that every module makes progress (does not hang).
interfaces goes beyond writing properties; it requires code
Fig. 3 presents an example of the simple usage of Au-
to sample transactions and symbolic variables to track them.
toSVA’s language. These annotations unleash automated rea-
AutoSVA automatically generates all of this necessary code.
soning to generate the modeling and properties (shown in
Properties in SVA can use one of three directives: assert,
Fig. 2) surrounding liveness and safety for the Ariane core’s
assume and cover. Assumptions have different meanings based
LSU . Section III explains the syntax of the AutoSVA language
on how input stimuli are generated. In RTL simulation, inputs
and semantics of each annotation. Section IV shows how these
are driven either by manual or random tests, and thus assume
annotations can be applied to different interface styles.
has the same meaning as assert, i.e they check that the property
holds. Conversely, FV tools treat inputs as Boolean vari- III. T HE AUTO SVA F RAMEWORK
ables, and assumptions constrain the state space exploration AutoSVA focuses on verifying liveness, and its well-formed
by preventing some behaviors, while assertions check that transactions allow it to utilize a common abstraction from RTL
properties hold on the explored paths. FV tools then use a interfaces that avoids the complexity of specific module imple-
variety of solver engines [7] based on formal methods, such mentations. By capturing a common design-pattern, AutoSVA
as model checking, which uses SAT (satisfiability) [4] or BDD can automatically generate useful Formal Testbenches (FT).
(binary decision diagrams) [13], to exhaustively search for We denote a FT as useful when it (1) has sufficient mod-
property violations. FV search may result in a counterexample ule interface modeling to avoid spurious CEXs and capture

536

Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on May 01,2022 at 14:31:41 UTC from IEEE Xplore. Restrictions apply.
 TABLE I
TH E AUTO SVA LANGUAGE . C ONSTANTS ARE WRITTEN IN LOWERCASE AND
RTL File(s) AutoSVA Binding
Binding File
File(s) SYNTAX IN UPPERCASE . STR AND ASSIGN ARE V ERILOG ’ S SYNTAX FOR STRINGS
script Bind RTL with SVA AND ASSIGNMENTS .
Annotations
TRANSACTION ::= TNAME: RELATION ATTRIB
Property
Property File
File(s)
Tool-specific RELATION ::= P −in> Q | P −out> Q
SystemVerilog
SystemVerilog ATTRIB ::= ATTRIB, ATTRIB | SIG = ASSIGN | input SIG | output SIG
configuration Assertions(SVA)
(SVA)
Implementation Assertions SIG ::= [STR:0] FIELD | STR FIELD
and commands
FIELD ::= P SUFFIX | Q SUFFIX
SUFFIX ::= val | ack | transid | transid unique | active | stable | data
TNAME, P, Q ::= STR
Formal
Tool Formal Proofs/CEX's TABLE II
P ROPERTIES GENERATED FOR EACH TRANSACTION ATTRIBUTE .
Fig. 4. AutoSVA is an agile framework for FV of RTL using SVA. The files that define Attribute Properties generated
the FT are denoted in blue. Dotted lines indicate designer input.
val∗ If P is valid, then eventually Q will be valid and
for each Q valid, there is a P valid
relevant CEXs which lead to uncovering bugs, and (2) does ack∗ If P is valid, eventually P is ack’ed or
P is dropped (if its stable signal is not defined)
not miss legal scenarios due to over-constraining assumptions.
Moreover, AutoSVA reduces the state-explosion scalability stable If P is valid and not ack’ed, then it is stable next cycle

problem because it deliberately focuses on control logic and active This signal is asserted while transaction is ongoing
FV tools can be instructed to automatically ignore datapaths. transid∗ Each Q will have the same transaction ID as P
Fig. 4 presents an overview of AutoSVA’s verification pro- transid unique There can only be 1 ongoing transaction per ID
cess. AutoSVA takes as input the interface declaration section data∗ Each Q will have the same data as P
of the RTL module acting as the DUT. The interfaces should be
annotated using AutoSVA’s language for interface abstraction be preceded with an AUTOSVA macro, or be contained within
(defined at Section III-A). Once the abstraction is defined for a multi-line comment region that starts with it.
a DUT, AutoSVA generates the FT that includes a property Table I presents the formalization of the AutoSVA language.
file describing the properties to verify, all necessary modeling P and Q represent two interfaces which have a temporal
about RTL blocks external to the DUT, and a binding file to implication relation, which is either incoming “−in>” or
connect the properties to signals in the DUT. outgoing “−out>” from the DUT’s perspective, and share
Based on the FV tool to target, AutoSVA generates con- a transaction named TNAME. Multiple transactions can be
figuration and command files. AutoSVA currently supports defined with unique names. ATTRIB definitions map interface
JasperGold [6] and SymbiYosys [18]. Once the properties, signals to transaction attributes. Each definition must be placed
binding and tool-specific files are generated, AutoSVA invokes on a separate line in the RTL, i.e. distinct line number, and
the FV tool to start the verification process. This returns either must be prefixed with the interface name.
property proofs or CEXs that highlight possible bugs in the Implicit definitions are native interface signal declarations
RTL. A hardware designer can then quickly set up a FT and (preceded by input/output signals) that are already defined in
locate bugs by using AutoSVA as a frontend for FV tools. the RTL design. If they follow the FIELD naming conven-
A. AutoSVA Language to Express Transactions tion, AutoSVA can automatically identify these fields without
annotations, which is especially useful for early-stage RTL
AutoSVA’s transaction abstraction involves two events con- verification. AutoSVA’s parser ignores signal declarations that
nected with an implication relation. From the DUT’s per- do not match P or Q prefixes and the language’s legal suffixes.
spective there are two types of transactions: (1) incoming Explicit definitions define new signals to extract transaction
transactions describe when a DUT receives a request and is attributes that are not explicitly defined with interface signals.
responsible for eventually triggering a well-formed response or These are useful for renaming signals that do not match Au-
another request, and (2) outgoing transactions describe when a toSVA’s language, extracting fields within structs, and defining
DUT triggers a request that eventually must receive a response. attributes based on multiple interface signals. Fig. 7 presents
The two events in a transaction are associated with RTL examples of these definitions for a few modules.
interfaces, which are the connection points of RTL modules.
For example, incoming transactions can map a cache lookup B. Property Generation Based on Transaction Attributes
interface to define a liveness condition that the cache lookup AutoSVA generates properties based on how transactions
should eventually have a response, and to define a safety are defined, as more attributes indicate more characteristics
condition that this response must satisfy certain properties, to verify. Table II presents the properties that result from
e.g. maintain the same transaction ID the request had. the presence of each attribute. AutoSVA does not require all
AutoSVA maps transaction events to interfaces through possible transaction attributes to be defined in order to generate
annotations expressed in its language. These language annota- meaningful properties. For example, an implication relation
tions are written as Verilog comments on the interface decla- between P and Q with just the val attribute defined indicates
ration section of an RTL file to identify module interfaces that the two interfaces communicate and thus a liveness property
participate in transactions. To distinguish these annotations is generated for the transaction. The absence of an ack signal
from regular code comments, AutoSVA requires annotations to indicates the request/response is always accepted.

537

Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on May 01,2022 at 14:31:41 UTC from IEEE Xplore. Restrictions apply.
 Some of the properties expressed in Table II cannot be
expressed in SVA directly, and thus AutoSVA generates all
necessary auxiliary Verilog code. For example, verifying that
every response followed a previous request requires counting
the number of ongoing transactions (done with registers in
Fig 2). The transid attribute allows tracking transactions to
reason about other attributes, such as data, which is used
to verify data integrity. This is important for interface fields
which are immutable between P and Q, e.g. data in a queue
or address in a memory request.
Attributes marked with * at Table II generate properties that
are asserted when the transaction is incoming and assumed
when outgoing. E.g., for the val attribute, the word ”eventu- Fig. 5. Steps of the AutoSVA framework. It receives an annotated RTL file and the FV
ally” indicates liveness when the DUT is expected to respond tool to target, and it outputs a FT that is ready to be run.
and fairness when it is waiting for a response. For attributes
stable and transid unique, the opposite holds; properties are
assumed on incoming and asserted on outgoing transactions. language, and interface input/output signals. Based on the
The attribute active is always asserted when defined. annotations, the parser identifies which pairs of interfaces par-
Submodule Properties: When the DUT has a submodule ticipate in transactions and creates a mapping from interface
whose inputs are driven by actual logic, it is worthwhile to pairs (P and Q) to a list of their attribute definitions.
ensure that assumptions about these inputs hold. AutoSVA
(2) Transaction Builder: AutoSVA builds transaction objects
assumptions can be converted into assertions by changing
based on interface fields and implication relations identified by
the value of the ASSERT INPUTS parameter. Submodule
the parser. During this process, AutoSVA can detect syntax
properties can be linked to the parent’s through AutoSVA’s
errors in annotations, e.g. when transid or data fields are
parameters: ”-AM” includes the properties when the submod-
defined in only one of the interfaces of a transaction, or with
ule was the DUT (assumptions over outgoing requests) and
mismatched data widths.
”-AS” converts all assumptions into assertions.
End-to-End Properties: SVA allows writing properties that (3) Signal Generator: Before generating properties based
use internal RTL logic (not visible at the interface). While on transactions, AutoSVA generates auxiliary signals, such
this is often necessary for full functional verification, it as symbolics, which are unassigned variables used to build
causes properties to depend on RTL implementation details. assertions. Symbolic variables are unconstrained, and allow
To overcome this, AutoSVA writes end-to-end properties FV tools to explore all their possible values in a single
which solely describe interface signals, but cover the whole assertion. For example, a single assertion can be used to reason
path from input to output interface. End-to-end properties about all lines of a cache if a symbolic signal is used to index
are implementation-agnostic, and thus can be automatically the cacheline. AutoSVA also generates handshake signals (as
generated pre-RTL, making AutoSVA a great framework for conjunctions of val and ack) to indicate that a request or
Test-Driven-Development (TDD). response takes place.
Property Reuse: In addition to FV, AutoSVA property
(4) Property Generator: AutoSVA creates properties based
files can be utilized in a simulation testbench to ensure that
on the transaction attributes and type (incoming or outgoing).
assumptions hold during system-level testing. Although many
These properties can verify liveness, uniqueness, data integrity,
RTL simulation tools do not support liveness properties, all
stability, or X-propagation (detailed in Section III-B). SVA
control-safety properties and X-propagation assertions can be
properties are explicitly written in the property file. AutoSVA
checked during simulation. AutoSVA generates X-propagation
does not use SVA macros or checkers to provide better
assertions, which check that when the val signal of an interface
readability in case the user wants to explore the properties or
is asserted, none of the other attributes have value X (concur-
a verification engineer wants to extend the FT for functional
rently 0 and 1). Because formal tools do not consider X’s and
correctness. The properties are tool-agnostic, and written to be
instead assign arbitrary values of 0 or 1, these assertions are
most efficient for FV tools to run, e.g. using symbolic indexes
only checked during simulation (under a XPROP macro).
for transid tracking. The authors have created this tool based
C. AutoSVA Implementation and Process Steps on lessons learnt from prior art [8], [9], [16] and years of
industry and academic experience with FV of RTL.
AutoSVA is implemented in Python using only standard
libraries to provide portability and ease of use. AutoSVA (5) FV Tool Setup: Once the SVA properties are generated,
generates FTs in under a second. Fig. 5 details its five steps. AutoSVA links them to the FV tool that the hardware designer
(1) Parser: AutoSVA parses the signal declaration section selects. Furthermore, AutoSVA supports linking the FTs of
of the annotated RTL file to identify global parameters, e.g. submodules of the DUT, that had already been generated, by
cache associativity or queue size, annotations in the AutoSVA using script parameters during AutoSVA’s invocation.

538

Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on May 01,2022 at 14:31:41 UTC from IEEE Xplore. Restrictions apply.
 Ariane's Load-Store-Unit (LSU) TABLE III
Black- . MMU L1-I$ RTL MODULES TESTED WITH AUTO SVA. A RIANE MODULES ARE INDICATED WITH
lsu_load LU A, AND O PEN P ITON WITH O
boxed .
DTLB ITLB
Issue lsu_store . PTW
.
SU RTL Module Result
stage dtlb_ptw
. .
ptw_dcache L1-D$
. A1. Page Table Walker (PTW) 100% liveness/safety properties proof
A2. Trans. Look. Buffer (TLB) 100% liveness/safety properties proof
Fig. 6. AutoSVA verifies several modules in a hierarchy in Ariane. By testing at the A3. Memory Mgmt. Unit (MMU) Bug found and fixed −> 100% proof
MMU module level (blue box), AutoSVA revealed Bug1.
A4. Load Store Unit (LSU) Hit known bug (issue #538)
A5. L1-I$ (write-back) Hit known bug (issue #474)
ptw_dcache: ptw_req −out> dcache_res
O1. NoC Buffer Bug found and fixed −> 100% proof
ptw_req_val = req_port_o.data_req
ptw_req_ack = req_port_i.data_gnt O2. L1.5$ (private) NoC Buffer proof, other CEXs
dcache_res_val = req_port_i.data_rvalid
dtlb_ptw: dtlb −in> ptw_update
dtlb_active = ptw_active_o
a few examples of how AutoSVA can be applied to a wide
dtlb_val = enable_translation & dtlb_access_i & dtlb_hit_i
dtlb_ack = !ptw_active_o
range of interfaces based on common possible scenarios.
[riscv::VLEN-1:0] dtlb_stable = dtlb_vaddr_i Single Ongoing Transaction: When there is only one on-
[riscv::VLEN-1:0] dtlb_data = dtlb_vaddr_i going transaction in a module, it can be modeled simply by
ptw_update_val = ptw_update_o.valid | ptw_error_o not defining the transid attribute, which is the case for the
[riscv::VLEN-1:0] ptw_update_data = update_vaddr_o
ptw dcache and dtlb ptw transactions in Fig. 7. This principle
mem-engine_noc: noc1buffer_req −in> noc1buffer_enc
[MSHR_ID:0] noc1buffer_req_transid = noc1buffer_req_mshrid works for both incoming and outgoing transactions.
[MSHR ID:0] noc1buffer_enc_transid = noc1buffer_enc_mshrid Multiple Outstanding Transactions: When transactions can
be in-flight simultaneously, it can be modeled by annotat-
Fig. 7. AutoSVA annotations to define PTW’s outgoing transaction to the data cache ing the tracking field with transid, e.g. mshrid for mem-
(ptw dcache) and incoming transaction from the DTLB-miss interface (dtlb ptw), and
OpenPiton buffer’s incoming transaction from Mem Engine towards NoC1 encoder (val
engine noc. Tracking requests allows AutoSVA reasoning
and ack attributes match interface names). about integrity of transid and data fields. If requests are not
tracked, AutoSVA still checks that there are no more responses
IV. E VALUATING THE AUTO SVA F RAMEWORK than requests and that every transaction eventually finishes.
No Ack signal: When an interface does not have an ack
We utilize multiple metrics to evaluate AutoSVA: (1) its signal but the module cannot always accept new requests,
ability to find bugs, both known (open issues) and new bugs; AutoSVA allows defining ack by reasoning about other signals.
(2) the speed of bug discovery, based on tool runtime and In the case of dtlb ptw, the ack field is defined based on the
trace length; (3) amount of engineering effort, measured in active signal, that indicates when the PTW is busy. Defining
time spent writing the transaction annotations; and (4) bug-fix stable alongside ack means that AutoSVA will model the
confidence, whether the bug-fix leads to a proof or new CEX. payload to remain stable until the request is ack’ed.
We study these metrics in mature, taped-out, open-source Results: Table III presents the 7 Ariane and OpenPiton
hardware projects: 64-bit RISC-V Ariane Core [1] and the modules that were tested using FTs. AutoSVA generated a total
OpenPiton manycore framework [2]. We have selected 7 RTL of 236 unique properties based on 110 LoC of annotations.
modules that are critical for forward-progress and thus require First, FTs of Ariane’s PTW and TLB resulted in 100% of
exhaustive testing. Table III lists these modules as well as the properties being proven at unit-level after 30 minutes of
the outcome of formally verifying them using testbenches human effort to define the correct transactions. Next, the MMU
generated by AutoSVA. These outcomes consist of proofs and FT was set up after 10 minutes of adding a new transaction and
bugs, demonstrating that AutoSVA is useful and effective at reusing the properties of its submodules’ FTs. These results
generating properties and models to verify forward progress. demonstrate that AutoSVA is quick to use and effective at
We also demonstrate AutoSVA for early-stage verification by verifying forward progress in control-critical modules.
applying it to a new unit, Mem Engine, which connects to Fig. 6 shows the hierarchy of the Ariane modules we have
OpenPiton’s NoC by reusing its encode/decoder buffers. tested. The MMU FT (blue) checks that every request from
AutoSVA supports several FV tools, so we elect to perform the LSU eventually receives a response, and that no response
evaluations using JasperGold 2015.12. Additionally, to check occurs without a prior request. Before it uncovered a real bug,
that AutoSVA properties are compatible with system-level AutoSVA found an interesting CEX: an ITLB miss was never
simulation, we bind the property files to the in-place testbench filled because the PTW was always busy with DTLB misses,
using VCS-MX 2018.09. i.e. DTLB has static priority over ITLB. This fairness problem
Applying the AutoSVA language to RTL modules: A cannot happen in practice since one instruction cannot do
key component of AutoSVA is its transaction abstraction that many DTLB lookups. Since the trace was quick (<1s) and
is broad enough to apply to most RTL interface styles and short (<4 cycles), it was straightforward to identify the cause
specific enough to generate useful properties. Fig. 7 presents of the CEX and add an assumption to remove it.

539

Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on May 01,2022 at 14:31:41 UTC from IEEE Xplore. Restrictions apply.
 Bug1. Ghost Response on MMU: The next CEX uncovered VI. C ONCLUSION
a bug that was triggered when the MMU receives a misaligned This work presents AutoSVA, a tool to automatically gener-
request from the LSU. The MMU responds immediately with ate testbenches for unit-level FV. Based on annotations made
a bad alignment response, but the DTLB still misses and the in the signal declaration section of an RTL module, AutoSVA
PTW is activated (bad behavior). In the case of a page fault, the generates liveness and safety properties about control logic to
MMU generates a second ”ghost” response to the LSU, raising verify forward-progress. Thus, hardware designers can verify
an exception. This bug was found by the FV tool in less than their designs at unit-level without requiring FV expertise and
a second, producing a 5-cycle trace that allowed us to quickly with the minimal effort of writing RTL module interface
identify the problem and produce a bug-fix (masking the PTW annotations. This pays off quickly, as performing FV early can
request with the misaligned signal) with high confidence, as save significant debugging time during system-level simulation
the formal tool found a proof in few seconds for the previously and increase designer confidence that the system will not hang.
failing assertion. In 5 minutes, the MMU FT proof-rate was We have shown that AutoSVA is effective with an evaluation
100%. The Ariane maintainers confirmed the bug and the fix. on widely used open-source HW projects. This discovered
Hitting Known Bugs: The LSU FT hit (in 1 second) a bug bugs and provided proofs of 7 control-critical RTL modules.
that was recently discovered on a long FPGA run: an ongoing AutoSVA generated a total of 236 unique properties based
load hits an exception caused by a later load. The Ariane on 110 LoC of annotations. These are included in the open-
maintainers welcomed a FT where they could validate that source repository of this work.1 We envision AutoSVA to
the bug-fix solves the problem and does not break anything become a standard language to define RTL modules’ interface
else. Similarly, the L1-I$ FT was able to hit a reported bug. expectations.
ACKNOWLEDGMENTS
Bug2. Deadlock in NoC Buffer: AutoSVA found a deadlock
bug in an underdeveloped part of Mem Engine that connects to We thank Aarti Gupta for her useful advice. This material
the OpenPiton NoC. Since the interfaces mostly matched the is based on research sponsored by the Air Force Research
AutoSVA language, the FT was generated with just 3 lines of Laboratory (AFRL) and Defense Advanced Research Projects
code (shown in mem-engine noc at Fig. 7). The first CEX to Agency (DARPA) under agreement No. FA8650-18-2-7862. 2
the liveness assertion revealed a bug that arises from the reuse R EFERENCES
of the NoC buffer from the L1.5$ for Mem Engine The buffer [1] “RISC-V Ariane core (CVA6),” https://github.com/openhwgroup/cva6.
assumes that the input does not drive more requests than the [2] J. Balkind, K. Lim, F. Gao, J. Tu, D. Wentzlaff, M. Schaffner, F. Zaruba, and
L. Benini, “OpenPiton+Ariane: The first open-source, SMP Linux-booting RISC-
number of buffer entries, which is violated in Mem Engine. V system scaling from one to many cores,” in Computer Architecture Research
After fixing the bug (adding a ”not-full” condition to the ack with RISC-V, CARRV, vol. 19, 2019.
[3] J. Balkind, K. Lim, M. Schaffner, F. Gao, G. Chirkov, A. Li, A. Lavrov, T. M.
signal), the formal tool resulted in a proof. Nguyen, Y. Fu, F. Zaruba et al., “BYOC: a ’bring your own core’ framework for
heterogeneous-ISA,” in ASPLOS’25, 2020, pp. 699–714.
Lastly, the FT of OpenPiton’s L1.5$ showed that the condi- [4] A. Biere, A. Cimatti, E. Clarke, and Y. Zhu, “Symbolic model checking without
tion added to the NoC buffer did not break the properties for BDDs,” in International conference on tools and algorithms for the construction
and analysis of systems. Springer, 1999, pp. 193–207.
its buffer instance. Other properties, e.g. that every cache miss [5] J. Buckingham, “Formal for designers,” in Agile Test Driven Dev. for ASIC, 2016.
is eventually filled, showed CEXs due to under-constraints [6] I. Cadence Design Systems, “Jaspergold apps user’s guide,” 2015.
[7] ——, “Jaspergold engine selection guide,” 2016.
in the message types. AutoSVA provides the FT foundation [8] E. Cerny, S. Dudani, J. Havlicek, D. Korchemny et al., SVA: the power of assertions
that the L1.5$ designer can refine with assumptions to remove in SystemVerilog. Springer, 2015.
[9] C. Cumming, “SystemVerilog Assertions - best known practices for simple SVA
spurious CEXs. The testbench can also be extended with more usage,” SNUG Silicon Valley, 2016.
assertions to achieve complete functional verification. [10] B.-Y. Huang, H. Zhang, P. Subramanyan, Y. Vizel, A. Gupta, and S. Malik,
“Instruction-level abstraction (ILA): A uniform specification for system-on-chip
verification,” ACM Transactions on Design Automation of Electronic Systems
V. R ELATED W ORK (TODAES), vol. 24, no. 1, pp. 1–24, 2018.
[11] IEEE Standard for SystemVerilog–Unified Hardware Design, Specification, and
Early works focused on developing methods for formal Verification Language, IEEE 1800-2012 Std., 2013.
[12] Y. A. Manerkar, D. Lustig, M. Martonosi, and M. Pellauer, “RTLCheck: Verifying
verification of RTL correctness [4], [13], [14]. These include the memory consistency of RTL designs,” in 2017 50th Annual IEEE/ACM MICRO,
model checking, which relies on SAT solvers or BDDs, and 2017, pp. 463–476.
[13] K. L. McMillan, “Symbolic model checking,” in Symbolic Model Checking.
Assertion-Based Verification (ABV), which builds on top of Springer, 1993, pp. 25–60.
model checking to verify control logic, design interfaces, and [14] Ping Yeung and K. Larsen, “Practical assertion-based formal verification for SoC,”
in 2005 Intl. Symposium on System-on-Chip, 2005, pp. 58–61.
data integrity. The emergence of SVA [11] popularized ABV [15] A. Reid, R. Chen, A. Deligiannis, D. Gilday, D. Hoyes, W. Keen, A. Pathirane,
for verification engineers [16]. More recent work focuses O. Shepherd, P. Vrabel, and A. Zaidi, “End-to-end verification of processors with
ISA-formal,” in CAV, S. Chaudhuri and A. Farzan, Eds. Springer, 2016, pp. 42–58.
on generating SVA from a higher level language [10], [12]: [16] E. Seligman, T. Schubert, and M. A. K. Kumar, Formal verification: an essential
RTLCheck verifies RTL pipeline implementations against their toolkit for modern VLSI design. Morgan Kaufmann, 2015.
[17] S. Sutherland, “Who put assertions in my RTL code? And why? How RTL design
memory consistency model (MCM) axiomatic specifications; engineers can benefit from the use of sva,” SNUG Silicon Valley, pp. 1–26, 2015.
ILA generates a Verilog model of the design from the ILAng [18] C. Wolf, “SymbiYosys,” https://github.com/YosysHQ/SymbiYosys.
functional specification, and compares it against the RTL 1
https://github.com/PrincetonUniversity/AutoSVA
2
implementation [10]. Although these methods automatically The U.S. Government is authorized to reproduce and distribute reprints for Gov-
ernmental purposes notwithstanding any copyright notation thereon. The views and
generate SVA, defining high-level models and matching them conclusions contained herein are those of the authors and should not be interpreted as
to RTL signals still require significant effort and knowledge, necessarily representing the official policies or endorsements, either expressed or implied,
of AFRL and DARPA, or the U.S. Government.
which may discourage hardware designers from using them.

540

Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on May 01,2022 at 14:31:41 UTC from IEEE Xplore. Restrictions apply.