Scribd
Upload
95 views8 pages

Flexible Checker: A One-Stop Shop For All Your Checkers and A Methodology For Elastic Scoreboarding

Flexible Checker is a methodology for creating an adaptive checker/scoreboard for verifying designs with changing configurations. It uses proxy transaction containers and monitors that can handle different transaction types. The elastic scoreboard contains expected queues for each target that are populated from source transactions and checked against actual target transactions. Flexible Checker enables end-to-end transaction tracing across multiple nodes and collects statistics on bandwidth, latency, and more.

Uploaded by

bhargav
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
95 views8 pages

Flexible Checker: A One-Stop Shop For All Your Checkers and A Methodology For Elastic Scoreboarding

Flexible Checker is a methodology for creating an adaptive checker/scoreboard for verifying designs with changing configurations. It uses proxy transaction containers and monitors that can handle different transaction types. The elastic scoreboard contains expected queues for each target that are populated from source transactions and checked against actual target transactions. Flexible Checker enables end-to-end transaction tracing across multiple nodes and collects statistics on bandwidth, latency, and more.

Uploaded by

bhargav
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Flexible Checker: A one-stop shop for all your

checkers and
a methodology for elastic scoreboarding
Saad Zahid, Chandra Veedhi, Sumit Dhamanwala
Arteris Inc
9601 Amberglen Blvd. Building G, Suite 117,
Austin TX, 78729

Abstract—This paper aims to define a methodology for a composite checker/scoreboard called Flexible Checker
that provides test-bench writers a solution that can adapt to ever-changing design configurations. Flexible
Checker also provides a solution that is portable across blocks, sub-blocks, and chip-level environments. It can
also support flexible “transaction trace checking,” which checks transactions at multiple internal nodes before
reaching their end points. Flexible Checker is equipped to record and dump vital statistics, including bandwidth,
latency, traffic distribution, transaction count (type, size, etc.), from end to end in the report phase of a UVM.

I. INTRODUCTION
The scoreboard for the UVM test bench of a SoC is a crucial piece that checks the data integrity across the DUT (design under
test). The way a scoreboard is coded traditionally varied from engineer to engineer, configuration to configuration, and block
to block. In this paper, we will show how to templatize a scoreboard to make it more configurable, scalable, and lightweight at
the same time. To achieve this, we introduce what we call a proxy transaction container class, a proxy monitor, and proxy
transaction queues.
II. ARTERIS VERIFICATION CHALLENGE
For companies like Arteris, which provides IP interconnects with the capability to be constituted of an infinite number of
configurations, it is essential to make the corresponding test benches fully flexible and elastic yet robust and effective to deliver
high quality. Our biggest challenges to consider during the development process are as follows:
1. Each and every interface field and position is configurable.
2. Each block/unit/component is also fully elastic in terms of
a. The number of input/outputs,
b. how its features can be enabled/disabled from a code-generation prospective, and
c. the buffer sizes, pipeline stages, states, registers, etc.
3. Similarly, all the above must be complemented by an equivalent test bench to verify each available feature accordingly.
These above-mentioned challenges cannot be solved just by using the SystemVerilog (SV) parameter alone, so we have to
develop a custom tool to preprocess our embedded (inline) and parameterized code to generates the final SV code.
III. KEY COMPONENTS
To make Flexible Checker highly scalable, agile, and portable, we needed to make a few fundamental verification strategy
decisions and develop the key components as follows:
1. All in-house UVCs (or VIPs) must have a portable monitor so that we can instantiate it directly in Flexible Checker.
2. For external (third-party) VIPs, we wrote a proxy monitor to collect third-party transactions and embed them into our
proxy transaction container class and pass them to an elastic scoreboard.
3. All test-bench components must use a single transaction type (proxy transaction container) regardless of the actual
transaction type (for example, AXI, APB, AHB, or any number of in-house protocols).
4. We assembled a wrapper class (extended from UVM_COMPONENT) called Flexible Checker, which includes all the
required monitors and the elastic scoreboard.

IV. PROXY TRANSACTION CONTAINER CLASSES


The proxy transaction item class (3rdparty_txn_item) is both a container class for porting a third-party VIP as well as a base
class for an in-house VIP. It is the transaction class from which other protocol-specific transaction items are derived. It also
has a handle defined as the uvm_sequence_item type, which is used as a container for third-party VIP transaction items. It
defines transaction query operations such as “get destination,” “get source,” and “get ID” as virtual functions, which are
supposed to be overloaded in the extended classes. The code is shown below.
V. PROXY MONITOR CLASSES
Flexible Checker is not just a scoreboard but a combination of a scoreboard and the corresponding monitor feeding it. The
monitors could be either monitors for protocols generated in house or from a third party. These monitors send transaction of
the container transaction item type via the analysis ports. The idea behind instantiating monitors alongside the scoreboard is to
bypass the process of instantiating an agent in passive mode and to add it to the env instead. This makes it simple to instantiate
the monitor and set the corresponding configuration database in one place. Also, this gives the flexibility to change the number
and type of instantiations. Reference code is shown below to support our in-house and third-party VIPs.
VI. ELASTIC / FLEXIBLE SCOREBOARD
The crux of the scoreboard is its ability to add expected queues for each of the end nodes or targets. The idea is that whenever
a transaction is reported at a source, it has inherent knowledge of which destination it must go to, or this information is provided
to the scoreboard beforehand via a config item, then it pushes the transaction into the corresponding expected queue. Also, the
transactions received by the scoreboard are casted to a base class type called the proxy transaction class, which enables the
scoreboard to operate on a single transaction type. Once a transaction is reported by the target, it compares the transaction with
the one in its corresponding expected queue. At the end of the simulation, the queues are checked to be empty, or the test fails
and reports the stray transactions.
VII. FLEXIBLE CHECKER
Flexible Checker gives the capability to check a transaction flowing through different nodes in a SoC. When a transaction is
reported at a source, the checker populates the expected queues of all the internal nodes the transactions is expected to go to.
Once a transaction is reported at these internal nodes, they are checked across the elements in their corresponding expected
queues (which were populated by the source). While flowing through nodes, the transaction translates to different
types/protocols, which requires coders to write a translation function that can then be reused across the scoreboard when such
a translation is expected.

VIII. TRANSACTION TRACING


All transaction tracing is done using Flexible Checker, which includes
1. end-to-end checking to make transactions reach the correct port, in the correct order, and with the correct content,
2. selectively monitor any/all interfaces of an interconnect to trace the transaction route (or path) for correctness and flag
an error otherwise,
3. selectively trace any/all transactions (using a preconfigured transaction ID) across an interconnect,
4. track timeout transactions (transactions that took more time than maximum allocated time in cycles),
5. track dropped transactions,
6. track split and merged transactions, and
7. track multicast and broadcast transactions.

IX. STATISTIC MONITORING & DUMPING


Flexible Checker can also generate statistics, including latency, bandwidth, traffic distribution, and histogram data, with the
transactions reported at the source and the destination and the relationship between them established by the scoreboard. The
corresponding timing and delay information is stored on a master/ slave basis in the scoreboard and is then used to create textual
or graphical data.

X. CONCLUSION
Flexible Checker was used in a highly configurable test bench and was able to do the checker functions just by passing the
configuration parameters. It made building a block-level test bench redundant by using the transaction trace-checking feature,
which helped the designer greatly in debugging failures as they were able to see the transaction flow and translation at each
node of the design before reaching the target. Additionally, a statistics generator was used to print a table listing the transaction
count, latency, and bandwidth numbers. This gave firsthand statistic numbers to the architects and gave a comparison point
with the actual performance model numbers.

You might also like