For detailed information on SPI Device design features, please see the [SPI_device design specification]({{< relref “hw/ip/spi_device/doc” >}}).
SPI Device testbench has been constructed based on the [CIP testbench architecture]({{< relref “hw/dv/sv/cip_lib/doc” >}}).
Top level testbench is located at hw/ip/spi_device/dv/tb/tb.sv
. It instantiates the SPI Device DUT module hw/ip/spi_device/rtl/spi_device.sv
. In addition, it instantiates the following interfaces, connects them to the DUT and sets their handle into uvm_config_db
:
pins_if
]({{< relref “hw/dv/sv/common_ifs” >}}))The following utilities provide generic helper tasks and functions to perform activities that are common across the project:
All common types and methods defined at the package level can be found in spi_device_env_pkg
. Some of them in use are:
parameter uint SRAM_OFFSET = 'h800; parameter uint SRAM_SIZE = 2048;
SPI Device instantiates (already handled in CIP base env) [tl_agent]({{< relref “hw/dv/sv/tl_agent/README.md” >}}) which provides the ability to drive and independently monitor random traffic via TL host interface into SPI Device.
[spi agent]({{< relref “hw/dv/sv/spi_agent/README.md” >}}) is used to drive and monitor SPI items. Following special behavior is supported in spi_host_driver
The SPI Device RAL model is created with the [ralgen
]({{< relref “hw/dv/tools/ralgen/README.md” >}}) FuseSoC generator script automatically when the simulation is at the build stage.
It can be created manually by invoking [regtool
]({{< relref “util/reggen/README.md” >}}):
All test sequences reside in hw/ip/spi_device/dv/env/seq_lib
. The spi_device_base_vseq
virtual sequence is extended from cip_base_vseq
and serves as a starting point. All test sequences are extended from spi_device_base_vseq
. It provides commonly used handles, variables, functions and tasks that the test sequences can simple use / call. Some of the most commonly used tasks / functions are as follows:
To ensure high quality constrained random stimulus, it is necessary to develop a functional coverage model. The following covergroups have been developed to prove that the test intent has been adequately met:
hw/dv/sv/cip_lib/cip_base_env_cov.sv
: Cover interrupt value, interrupt enable, intr_test, interrupt pinThe spi_device_scoreboard
is primarily used for end to end checking. It creates the following analysis fifos to retrieve the data monitored by corresponding interface agents:
tb/spi_device_bind.sv
binds the tlul_assert
[assertions]({{< relref “hw/ip/tlul/doc/TlulProtocolChecker.md” >}}) to the IP to ensure TileLink interface protocol compliance.We are using our in-house developed [regression tool]({{< relref “hw/dv/tools/README.md” >}}) for building and running our tests and regressions. Please take a look at the link for detailed information on the usage, capabilities, features and known issues. Here's how to run a basic sanity test:
$ $REPO_TOP/util/dvsim/dvsim.py $REPO_TOP/hw/ip/spi_device/dv/spi_device_sim_cfg.hjson -i spi_device_sanity
{{< testplan “hw/ip/spi_device/data/spi_device_testplan.hjson” >}}