UVMF parameters

UVM
1

In the ALU example provided in UVMF, same parameters appear in multiple yaml files, for example ALU_IN_OP_WIDTH appear in
alu_bunch_cfg.yaml top_env_params section, interface_params section
alu_env_cfg.yaml parameters section.

What’s the link between all these parameters that appear in different places? Does changing one of them change them all? How are these achieved?

I searched in UVMF user guide as well as yaml reference but found no information on this.

Any explanation would be great!

2

The params in the YAML are passed down from bench to environment to interface.
If you look in the alu_bench_cfg.yaml file the parameter name is TEST_ALU_IN_OP_WIDTH.
If you look in the alu_env_cfg.yaml file, the parameter name is ALU_IN_OP_WIDTH.

Back in the alu_bench_cfg.yaml file, the environment is instantiated
This is like a component instantiation where we pass the bench level param TEST_ALU_IN_OP_WIDTH to the environment level parameter ALU_IN_OP_WIDTH

  top_env_params:
    - name: "ALU_IN_OP_WIDTH"
      value: "TEST_ALU_IN_OP_WIDTH"

The evironment and Interface YAML files use the same param name. Would have been clearer if they had a unique prefix like ENV_ALU_IN_OP_WIDTH & IF_ALU_IN_OP_WIDTH. But basically the bench level params can be set at runtime when you simulate and they can be passed down through the environment and subsequently down to the agents to set the ALU input OP width.

3

Thanks.
You explanation helps within alu_bench_cfg.yaml where the value 8 is sent from TEST_ALU_IN_OP_WIDTH down to top_env_params and interface_params.

Though in alu_env_cfg.yaml The parameter ALU_IN_OP_WIDTH is also set to value 8, and passed down to agents.

Is it safe to assume ALU_IN_OP_WIDTH in alu_env_cfg.yaml is independent from the one set in alu_bench_cfg.yaml?
For a unlikely example one can be set to 8 and another one can be set to 9 and they won’t affect each other right?