creation of comprehensive core control configuration object

Created by: strichmo

This is a large PR that attempts to unify a common configuration class for our cores into an agent and drive that configuration into multiple agents.

If I have tagged you as a reviewer please take a deeper look at the diffs in the PR. Please give me any feedback on this PR or ask any questions if something is not clear. I set the DO NOT MERGE because there are a couple of items in the testbench (notably the PMA parameterization) that I do not want to merge and need to realign with the parameter setting Robin and Henrik are working on.

New Agent (uvma_core_cntrl)

Under lib/ I have created a Core Control agent. This agent provides the common configuration base class.

This is a virtual base class that:

• Provides common fields for active processor agent (to facilitate reuse in platforms)
• Provides common testbench flags (use_iss, scoreboarding_enabled disable_csr_checks, etc.)
• Provides ISA extension flag (ext_*_supported)
• Provides mode and common feature support flags
• Provides some common parameters (NUM_MHPM, PMA, etc.)
• Common bootstrap pins
• An API for configuring CSR checks
• Code to automatically remove CSRs based on extension and mode support (users are always free to restore as necessary via inheritance)
• Informative printing of core configuration, csr check values, etc. for easier debug

#   MIDELEG                         string                                    11    Unsupported                                                         
#   MIE                             string                                    35    Supported and checked in scoreboard                                 
#   MTVEC                           string                                    35    Supported and checked in scoreboard                                 
#   MCOUNTEREN                      string                                    11    Unsupported                                                         
#   MSCRATCH                        string                                    35    Supported and checked in scoreboard                                 
#   MEPC                            string                                    35    Supported and checked in scoreboard                                 
#   MCAUSE                          string                                    35    Supported and checked in scoreboard                                 
#   MTVAL                           string                                    39    Supported but not checked in scoreboard                             
#   MIP                             string                                    39    Supported but not checked in scoreboard                             

I also moved the CSR ISA definitions in this class as it is expected that our other agents (RVVI, RVFI, ISACOV) should import this class so we have a single definition.

Customizing the config class

Cores should inherit from the base config class and extend to:

• Add agent configuration handles
• Add any core-specific flags that may not be appropriate for the base class (e.g. pulp)
• Add constraints to set extensions, modes, etc. to legal combinations for the core
• Implement a post_randomize to customize CSR checks and any other common configurations
• Add a context and virtual interface for the core which includes parameters (tie to design parameters so env can read them) and bootstrap pins

Using config class in test

Note that in the base test, I rearranged a bit how the build_phase() works:

   create_cfg       ();   
   cfg_hrtbt_monitor();
   assign_cfg       ();
   create_cntxt     ();
   assign_cntxt     ();
   retrieve_vifs    ();
   sample_core_parameters();
   randomize_test   ();
   create_env       ();
   create_components();

Note sample_core_parameters() which actually "reads" parameters from the virtual interface in the context. This must be done before randomize_test() which will randomize the configuration using the sampled parameters as state variables. This will allow us to have the ability to set bootstrap pins as we wish and constrain them properly.

Also please note that how parameters are "generated" is not addressed by this PR. This PR still assumes that the testbench will set parameters of the DUT/Core based on ifdefs. This PR will then sample whatever those parameters are in-time for proper downstream randomization of the core configuration.

Core control derived "driver"

Via the factory, cores should setup a driver (uvme_cv32e40x_drv.sv) that is responsible for driving pins of the design (if agent is active) that will:

• Drive the bootstrap pins according to the random core configuration
• Drive any misc pins via traditional driver/virtual sequence. One example of a pin in the E40X is the fetch_en pin. There was some behavioral module to do this before, but it really should be a virtual sequence controllable via plusargs (just like interrupt, debug noise generation).

Reusing the core configuration

RVFI, RVVI and ISACOV agents now take in a uvma_core_cntrl_cfg_c handle as well. This will ensure that ISA/core configuration is done once and all agents see the same configuration without awkward constraints nor data duplication.

This has already paid dividends by finding quite a few missing CSRs from the RVFI/RVVI scoreboarding/monitoring.

Note that the cv32e40p ci_check still passes in this PR. No common agent changes in the PR are visible by the E40P's infrastructure.

ISS control file generation

Since the RVVI is now "aware" of the core configuration I went ahead and added the ability for the RVVI agent to generate its own ovpsim.ic control file. In the uvma_rvvi_ovpsim_agent I added a method called configure_iss called at end_of_elaboration_phase to setup the following so far: (we could easily add more)

Bootstrap pins

• mhartid
• boot_addr
• mtvec_addr
• nmi_addr
• dm_halt_addr
• dm_exception_addr

Parameters

• NUM_MHPMCOUNTERS
• PMA_CFG

Any "information" from the core configuration now can very easily be automatically configured into the ISS. The user only need configure the correct parameter, or constrain the bootstrap pin as desired.