commit 83f8d4ccb1e0aba7f74f386326db0d17bdaa1cb5
author Timothy Trippel <ttrippel@google.com> Tue Mar 29 23:10:27 2022 -0700
committer Timothy Trippel <5633066+timothytrippel@users.noreply.github.com> Wed Mar 30 12:34:14 2022 -0700
tree 321b1c0a2d300f5243a943d52ff7fccb9a631c4c
parent 6dd8b2236f099ad56abfe79585006d93e2d0aabc

[bazel] add DV sim target to opentitan_functest

To support transitioning SW builds to bazel, additional rules needed to
be added to build sim_dv-specific device artifacts. These included a
sim_dv-specific bootstrap image (#11640) rule, and a sim_dv-specific SW
logging database extraction rule (#11755).

While both of these rules have already been added, they were not yet
invoked by the main test macro. Specifically, at a high level, the
`opentitan_functest` generates a `test_suite` of `sh_test` rules. The
SW artifacts (ELFs, BINs, VMEMs, etc.) are marked as data runfiles of
each `sh_test` rule, so they get built when either `bazel build
<opentitan_functest name>` or `bazel test <opentitan_functest name>` is
executed. Since there was no DV sim specific `sh_test` rule in the
`opentitan_functest` `test_suite`, the sim_dv-specific artifacts were not
yet built when the prior commands.

To force bazel to build SW artifacts for the DV sim environment, an
additional `dv` target was added to the `opentitan_functest` macro.
Additionally, an associated `sh_test` target was added that runs a simple
shell script that echos the proper `dvsim.py` command a user should
execute to run the associated test in the DV simulation environment.

The reason the DV `sh_test` does not invoke `dvsim.py` directly, is
three fold:

1) `dvsim.py` has two components, an open-source component (that is
   included in this repository) and a closed source component (that is
   not included in this repository). The open-source component has the
   ability to launch DV simulations locally, provided a supported RTL
   simulator is installed locally on your machine. The closed-source
   component has the ability to launch DV simulations on
   cloud-infrastructure, that is often organization-specific. Teaching
   bazel how to handle the dependencies between these components is a
   topic for future investigation, outside the scope of this commit.

2) As written, `dvsim.py` invokes the SW build system as part of the
   process of launching simulations. If those simulations are launched
   on remote cloud infrastructure this will result in `dvsim.py`
   building SW artifacts twice, once locally when `bazel test
   <opentitan_functest test>` is invoked, and once on the remote machine
   when `dvsim.py` itself invokes `bazel build <opentitan_functest
   test>`. Resolving this inefficieny is outside the scope of this
   commit.

3) `dvsim.py` accepts a wide array of command line arguments that enable
   adjusting various simulation configurations and parameters (e.g.,
   whether to generate waves or not, whether to collect coverage or not,
   which random seeds to use, etc.). Integrating those into a bazel test
   target will require additional design / thought outside the scope of
   this commit.

This fixes #11684.

Signed-off-by: Timothy Trippel <ttrippel@google.com>