|
| 1 | +# AC_RANGE_CHECK DV document |
| 2 | + |
| 3 | +${"##"} Goals |
| 4 | +* **DV** |
| 5 | + * Verify all AC_RANGE_CHECK IP features by running dynamic simulations with a SV/UVM based testbench |
| 6 | + * Develop and run all tests based on the [testplan](#testplan) below towards closing code and functional coverage on the IP and all of its sub-modules |
| 7 | +* **FPV** |
| 8 | + * Verify TileLink device protocol compliance with an SVA based testbench |
| 9 | + |
| 10 | +${"##"} Current status |
| 11 | +* [Design & verification stage](../../../../README.md) |
| 12 | + * [HW development stages](../../../../../doc/project_governance/development_stages.md) |
| 13 | +* [Simulation results](https://reports.opentitan.org/hw/top_${topname}/ip_autogen/ac_range_check/dv/latest/report.html) |
| 14 | + |
| 15 | +${"##"} Design features |
| 16 | +For detailed information on `ac_range_check` design features, please see the [`ac_range_check` HWIP technical specification](../README.md). |
| 17 | + |
| 18 | +${"##"} Testbench architecture |
| 19 | +The `ac_range_check` UVM DV testbench has been constructed based on the [CIP testbench architecture](../../../../dv/sv/cip_lib/README.md). |
| 20 | + |
| 21 | +${"###"} Block diagram |
| 22 | + |
| 23 | + |
| 24 | +${"###"} Top level testbench |
| 25 | +Top level testbench is located at `hw/top_${topname}/ip_autogen/ac_range_check/dv/tb/tb.sv`. |
| 26 | +It instantiates the `ac_range_check` DUT module `hw/ip/ac_range_check/rtl/ac_range_check.sv`. |
| 27 | +In addition, the testbench instantiates the following interfaces, connects them to the DUT and sets their handle into `uvm_config_db`: |
| 28 | +* [Clock and reset interface](../../../../dv/sv/common_ifs/README.md) |
| 29 | +* [Reset shadowed interface](../../../../dv/sv/common_ifs/README.md) // TODO add something in this doc about this interface. |
| 30 | +* [TileLink host interface for the CSRs](../../../../dv/sv/tl_agent/README.md) |
| 31 | +* [TileLink host interface for the Unfiltered CTN accesses](../../../../dv/sv/tl_agent/README.md) |
| 32 | +* [TileLink device interface for the Filtered CTN accesses](../../../../dv/sv/tl_agent/README.md) |
| 33 | +* Interrupts ([`pins_if`](../../../../dv/sv/common_ifs/README.md)) |
| 34 | +* Alerts ([`alert_esc_if`](../../../../dv/sv/alert_esc_agent/README.md)) |
| 35 | + |
| 36 | + |
| 37 | +${"###"} Common DV utility components |
| 38 | +The following utilities provide generic helper tasks and functions to perform activities that are common across the project: |
| 39 | +* [dv_utils_pkg](../../../../dv/sv/dv_utils/README.md) |
| 40 | +* [csr_utils_pkg](../../../../dv/sv/csr_utils/README.md) |
| 41 | + |
| 42 | +${"###"} Compile-time configurations |
| 43 | +[list compile time configurations, if any and what are they used for] |
| 44 | + |
| 45 | +${"###"} Global types & methods |
| 46 | +All common types and methods defined at the package level can be found in `ac_range_check_env_pkg`. |
| 47 | +Some of them in use are: |
| 48 | +```systemverilog |
| 49 | +[list a few parameters, types & methods; no need to mention all] |
| 50 | +``` |
| 51 | + |
| 52 | +${"###"} TL_agent |
| 53 | +* `ac_range_check` UVM environment instantiates a (already handled in CIP base env) [tl_agent](../../../../dv/sv/tl_agent/README.md) which provides the ability to drive and independently monitor random traffic via TL host interface into `ac_range_check` device, to access to the CSRs (Control/Status Registers). |
| 54 | +* Host interface to the Unfiltered CTN accesses. |
| 55 | +* Device interface to the Filtered CTN accesses. |
| 56 | + |
| 57 | +The `tl_agent` monitor supplies partial TileLink request packets as well as completed TileLink response packets over the TLM analysis port for further processing within the `ac_range_check` scoreboard. |
| 58 | + |
| 59 | +${"###"} Alert_agent |
| 60 | +`ac_range_check` testbench instantiates (already handled in CIP base env) [alert_agents](../../../../dv/sv/alert_esc_agent/README.md): |
| 61 | +[list alert names]. |
| 62 | +The alert_agents provide the ability to drive and independently monitor alert handshakes via alert interfaces in AC_RANGE_CHECK device. |
| 63 | + |
| 64 | +${"###"} UVM RAL Model |
| 65 | +The `ac_range_check` RAL model is created with the [`ralgen`](../../../../dv/tools/ralgen/README.md) FuseSoC generator script automatically when the simulation is at the build stage. |
| 66 | + |
| 67 | +It can be created manually by invoking [`regtool`](../../../../../util/reggen/doc/setup_and_use.md): |
| 68 | + |
| 69 | +${"####"} Sequence cfg |
| 70 | +An efficient way to develop test sequences is by providing some random variables that are used to configure the DUT / drive stimulus. |
| 71 | +The random variables are constrained using weights and knobs that can be controlled. |
| 72 | +These weights and knobs take on a "default" value that will result in the widest exploration of the design state space, when the test sequence is randomized and run as-is. |
| 73 | +To steer the randomization towards a particular distribution or to achieve interesting combinations of the random variables, the test sequence can be extended to create a specialized variant. |
| 74 | +In this extended sequence, nothing would need to be done, other than setting those weights and knobs appropriately. |
| 75 | +This helps increase the likelihood of hitting the design corners that would otherwise be difficult to achieve, while maximizing reuse. |
| 76 | + |
| 77 | +This object aims to provide such run-time controls. |
| 78 | + |
| 79 | +${"####"} Env cfg |
| 80 | +The `ac_range_check_env_cfg`, environment configuration object provides access to the following elements: |
| 81 | +* Build-time controls to configure the UVM environment composition during the `build_phase` |
| 82 | +* Downstream agent configuration objects for ease of lookup from any environment component |
| 83 | + * This includes the `tl_agent_cfg` objects for both TL interfaces |
| 84 | +* All virtual interfaces that connect to the DUT listed above (retrieved from the `uvm_config_db`) |
| 85 | +* Sequence configuration object described above |
| 86 | + |
| 87 | +All environment components contain a handle to an instance of this class (that was created in the test class via the parent `dv_base_test`). |
| 88 | +By housing all of the above, all pertinent information is more easily shared with all environment components. |
| 89 | + |
| 90 | +${"###"} Stimulus strategy |
| 91 | +${"####"} Test sequences |
| 92 | +All test sequences reside in `hw/top_${topname}/ip_autogen/ac_range_check/dv/env/seq_lib`. |
| 93 | +The `ac_range_check_base_vseq` virtual sequence is extended from `cip_base_vseq` and serves as a starting point. |
| 94 | +All test sequences are extended from `ac_range_check_base_vseq`. |
| 95 | +It provides commonly used handles, variables, functions and tasks that the test sequences can simple use / call. |
| 96 | +Some of the most commonly used tasks / functions are as follows: From `hw/top_${topname}/ip_autogen/ac_range_check/dv/env/seq/ac_range_check_base_vseq.sv`, |
| 97 | +* task 1: |
| 98 | +* task 2: |
| 99 | + |
| 100 | +${"####"} Functional coverage |
| 101 | +To ensure high quality constrained random stimulus, it is necessary to develop a functional coverage model. |
| 102 | +The following covergroups have been developed to prove that the test intent has been adequately met: |
| 103 | +* cg1: |
| 104 | +* cg2: |
| 105 | + |
| 106 | +${"###"} Self-checking strategy |
| 107 | +${"####"} Scoreboard |
| 108 | +It creates the following analysis ports to retrieve the data monitored by corresponding interface agents: |
| 109 | +* analysis port1: |
| 110 | +* analysis port2: |
| 111 | +<!-- explain inputs monitored, flow of data and outputs checked --> |
| 112 | + |
| 113 | +${"####"} Assertions |
| 114 | +* TLUL assertions: The `hw/top_${topname}/ip_autogen/ac_range_check/dv/sva/ac_range_check_bind.sv` binds the `tlul_assert` [assertions](../../../../ip/tlul/doc/TlulProtocolChecker.md) to the IP to ensure TileLink interface protocol compliance. |
| 115 | +* Unknown checks on DUT outputs: The RTL has assertions to ensure all outputs are initialized to known values after coming out of reset. |
| 116 | +* assert prop 1: |
| 117 | +* assert prop 2: |
| 118 | + |
| 119 | +${"##"} Building and running tests |
| 120 | +We are using our in-house developed [regression tool](../../../../../util/dvsim/README.md) for building and running our tests and regressions. |
| 121 | +Please take a look at the link for detailed information on the usage, capabilities, features and known issues. |
| 122 | +Here's how to run a smoke test: |
| 123 | +```console |
| 124 | +$ cd $REPO_TOP |
| 125 | +$ ./util/dvsim/dvsim.py hw/top_${topname}/ip_autogen/ac_range_check/dv/ac_range_check_sim_cfg.hjson -i ac_range_check_smoke |
| 126 | +``` |
| 127 | + |
| 128 | +${"##"} Testplan |
| 129 | +[Testplan](../data/ac_range_check_testplan.hjson) |
0 commit comments