We are using a VIP from a vendor that exposes internal state transitions through a callback.
By registering the callback class in the bfm (through the bfm API) and by overriding a specific ‘end point’ (I’m deliberately abusing the term in this context), we can take action and do something based on the bfm internal state.
Here’s an example:
class mycb extend bfm_callback;
virtual function state_transition(state_e from, state_e to);
// do something when there's a state transition
endfunction
endclass
Now it so happens that I’d like to build a model of my DUT that predicts what to observe on one of its interfaces based on the internal status of my bfm.
So how do I pass the state transition information to my predictor? I can see two choices:
- instantiate an analysis_port in the callback and have that connected to my predictor
- instantiate the predictor handle in the callback and have the state_transition function invoke the predictor accessor to pass the state transition
In both cases I would need the environment to build and connect those objects either through standard TLM connect method (1) or by passing the predictor handle (2).
Both approaches seem to me relatively reasonable but I would err for the first one so my predictor only has ‘standard’ connectivity w.r.t. the rest of the environment and I can override the transaction passed. Additionally, if the predictor doesn’t need anything else that bfm internal state to make its prediction, I can have a simple uvm_subscriber with an overridden run_phase().
So far I haven’t found any clear pattern or recommendation to address this usecase, that’s why I’m here to get some feedback on the proposals, as well as on alternatives that would better suit the problem.