Passing parameters from test_params_pkg to driver

UVM
, , ,
1

Hello,

I have a test parameters package containing constants derived from parameters such as clock frequencies.
I intend to use these constants within a driver. What is the recommended way to do that?

  1. Directly import the test parameters package in the driver class?
  2. Put the constants into uvm_config_db -set()- and read them within the driver class -get()-?
  3. ?

Kind regards
P.S.

2

In reply to Fipser@VA:

Your agent (and driver) should have a configuration object that contains all the parameters regarding the functionality of the agent. You should create this configuration at the test level, set the parameters as required, store it in the config_db(), and retrieve it in the agent during the build() phase.

3

In reply to cgales:

In reply to Fipser@VA:
Your agent (and driver) should have a configuration object that contains all the parameters regarding the functionality of the agent. You should create this configuration at the test level, set the parameters as required, store it in the config_db(), and retrieve it in the agent during the build() phase.

Thanks for your reply. Yes, I have the configuration objects set up as described in the cookbook, and they also get created at the test level (in the test base class xxx_test_base.svh) and retrieved in the agent’s build phase (as you described).
The thing is that these constants/parameters I need to access in the driver are mainly used as DUT generics. So the test_params_pkg is imported into the top lvl testbench module, and that’s it. But from a hierarchical point of view, of course I do not have access to these constants/parameters as components/classes are included bottoms up (and the driver being at the lowest level).
Do I still have to pass these constants/parameters via the configuration object now? I’m not sure at the moment how to achieve this.

4

In reply to Fipser@VA:

That’s a different situation. If you have parameters you want to be used by both DUT and testbench, the common package is the way to go. The config_db is for per-test parameterization.

5

In reply to dave_59:

In reply to Fipser@VA:
That’s a different situation. If you have parameters you want to be used by both DUT and testbench, the common package is the way to go. The config_db is for per-test parameterization.

Thanks for the clarification. So in order to be able to access the package from both the driver side and for the DUT generics I will have to import it at driver level (the corresponding agent package) as well? Meaning I have to push the test_params_pkg compilation to the front of the compilation order.

6

In reply to Fipser@VA:

Correct. Packages must be compiled before they can be imported.