UVM Recommeded Practices for BFM configuration

In UVM, what is the ideal way of setting run-time specific properties of a BFM implemented as an interface?

To be more specific, let us say that a UVM Test makes a register write that changes the endian-ness and ordering of samples being output by a Transmitter DUT. Assume that in its run_phase, the UVM monitor class calls a task from the BFM (interface) that waits for and returns valid output samples from the DUT.

It’s clear that both the interface and the UVM Agent (together acting as a receiver for the DUT) have variables that need to be updated so that they can correctly capture the samples. I have two following questions from this scenario, with regards to recommended practices:

  1. How does the BFM see any of these changes?

  2. How do UVM Agents (and the components within, like the monitor) ‘see’ register-writes? Should they always access the register model, or should the UVM Test immediately update the Agent’s configuration object after doing a register update?

Thanks,
Udit

In reply to ukhanna:

The register content is not the origin of your configuration. It is already a consequence.
The origin might be a parameter or a configuration object. Both you can pass to the configuration db and retrieve the corresponding object from there in any place wher you need this.

In reply to chr_sue:

If I understand your reply correctly, you’re saying that the interface should have an instance of the configuration object that is made to point to the agents’ configuration object somewhere in the build_phase of the UVM Agent. All methods/code in the interface should access variables in the config object to decide the behavior of this BFM.

However, is the use of class objects in the BFM emulation friendly, (where the BFM is typically implemented as synthesizable transactors)?

In reply to ukhanna:

No this is not what I’m saying. configuration objects are class-based constructs and they play an important role in other class-based objects and components. Static constructs like modules and interfaces are typiclly configured using parameters. Parameters can be hold in packages and they can be passed to the configuration db. I’m not familiar with the requirements for emulation, but the configuration of a component will be done prior to the synthesis.