Hi,
I am doing a project on AHB2APB protocol. There are a few signals in AHB interface which drives the APB. Is it advisable to use the AHB interface in my APB UVC? In that case there will be 2 interfaces in the driver as well as the monitor. If there is an alternative can anybody suggest me.
Narayanan
Usually, a driver is deployed to allow the testbench to drive an interface to the DUT. If your driver needs to know what state some AHB signals are in to be able to drive the APB interface directly, then it’s OK to pass the AHB virtual interface to the driver. Note that this limits your ability to reuse your APB agent in a strictly APB environment in the future, but you may not care about that.
In reply to tfitz:
Thanks for the info. So is there any other alternative other than this? And here in my project the protocol is an AHB2APB bridge, so wherever I find this bridge I can reuse the whole environment that contains both AHB and APB combined. Correct me if I am wrong.
Or is it advisable to use a common interface for both ahb and apb, and then put it in both AHB and APB agents.
In reply to nani:
If your DUT is the AHB2APB bridge, is it the case that it has an AHB interface on one side and an APB interface on the other? If that’s the case, then your environment would have an AHB agent connected to the AHB interface of your DUT and an APB agent connected to the APB interface. Then, in your environment you could pass any information between the two agents you think you need to.
Does that help?
In reply to tfitz:
I have created 2 separate agents for APB and AHB. And I have connected to separate environments. I think I should use a single environment for both . In that case I must not add ahb interface in the apb and vice-versa.