hi sir,
i’m a newbie for uvm framework.
in the given alu examples, test bench explicitly instantiate two interfaces/agents/bfms: alu_in_pkg and alu_out_pkg.
after revisiting the src code, i thought all the alu_out_pkg could do can also be implemented in single alu_pkg/alu_agent which contains full functionalities of driver and monitor.
for separate driver/driver_bfm, i understand it will offer benefits for co-emulation.
for separate alu input/output signals, and furthermore in/out agents, i could not get the point.
anyway, i looked through other packages such as ahb/wb/fpu.
it seems only fpu/alu explicitly defines in/out agent, while ahb/wb do not.
so i guess there is something special for alu/fpu that a separate in/out agents will do thing better.
could anyone help to explain there tricks?
thanks a lot!
In reply to zxwbobo:
Greetings!
The ALU example is a great starting point due to its simplicity, but that is a double-edged sword, for reasons that you have pointed out. It differs from some of the other example interfaces such as the wishbone or AHB in that it is not associated with a bus interface but a specific design function.
The design target for the ALU example is an ALU block (just one interface). The wishbone and AHB interfaces are used in environments that target “bridge” designs (wishbone goes in, AHB comes out, for example) and thus use multiple underlying interfaces for driving/monitoring.
To test out this ALU design we have to monitor both its inputs and outputs. Yes, we could accomplish this in a single agent with a monitor that had access to all of the design block’s signals, and from the point of view of maintaining the code we perhaps could have saved ourselves some effort by condensing it into one package/interface.
Functional organization of any agent/interface is up to you - the ALU interfaces provided as an example could have been set up as a single agent with a single monitor looking at all of the I/O of the design block, but sometimes there are situations where it is easier to break the monitoring of signals up, especially for more complex designs. Imagine, for example, if we had a more complex ALU that could handle more than one input command at a time and provide the results out-of-order. At some point it might make things easier to have two dedicated interfaces (one for input commands and another one tracking results) that are each feeding analysis port data to a predictor/scoreboard independently. If these two interfaces were condensed into one, you may wind up having to put prediction-level intelligence into your monitor in order to properly associate input activity with potentially out-of-order output activity. Alternatively you could have a single interface/monitor with multiple analysis port outputs (one AP that triggers on input activity, one for outputs) but with UVMF that is currently more easily accomplished through separate agent/interface definitions.
In reply to jcraft:
@jcraft
great explanation! it solves all of my confusions of how to use uvm framework.
also, your answer also explicitly tells me under what condition it’s really useful for using dedicated in/out interface.
thanks a lot!