Provide mechanism for a test-program to select its configuration

[Mike Thompson]

This issue is inspired by Issue #336 and Pull-Request #2159.

Background

As detailed in the Common Makefile for the CORE-V-VERIF UVM Verification Environment and TOOLCHAIN READMEs, each test-program in CORE-V-VERIF has an associated test.yaml that specifies various compile and/or runtime options used by the CORE-V-VERIF Makefiles and scriptware to compile and run the test. The scriptware also parses a global yaml file which defines a set of common options applicable to a number of test-programs. For example:

$ make test CFG=pulp_cluster_fpu_zfinx TEST=pulp_hardware_loop

will compile and run the test-program found in <core>/tests/program/custom/pulp_hardware_loop using <core>/tests/cfg/pulp_cluster_fpu_zfinx.yaml.

Some tests are intended to use one-and-only-one global yaml from <core>/tests/cfg, while other test-programs are intended to be used with multiple global yamls. Recall that in the absence of a CFG parameter on the make command-line, <core>/tests/cfg/default.yaml is used.

The Issue

Currently, there is no way for a human to know which global yaml to use for a given testcase. For example, as discussed in #2159, $ make test TEST=pulp_hardware_loop will not work because the default.yaml does not specify the MARCH needed to compile this test-program.

Proposed Solution

Currently, the scriptware will parse <core>/tests/cfg/default.yaml in the absence of a CFG parameter on the make command-line. The script YAML2MAKE could be updated to look for a "default_cfg" variable that would specify the default global yaml file to be used for a given test. For example, <core>/tests/program/custom/pulp_hardware_loop/test.yaml could look like this (the line with "default_cfg" is added):

# Test definition YAML for PULP_HARDWARE_LOOP test-program

# Debug directed test
name: debug_test
default_cfg: pulp_cluster_fpu_zfinx
uvm_test: uvmt_$(CV_CORE_LC)_firmware_test_c
program: debug_test
description: >
    Debug directed test

The default_cfg could be overridden with any other cfg using the CFG option as above.