Reputation: 89
Let's say I have a DUT (e.g. l2 cache) with AXI bus in master port and I have created a class AXI_transfer extended from sequence_item, 100 sequences of interesting test scenarios and a uvm driver. Now, the bus protocol of DUT has changed from AXI to AHB. Testbench components that need to be modified are the sequence_item, and the driver (because they are protocol dependent). Now, I don't like to redevelop sequences for AHB because they are transaction level scenarios. Instead, I'd like to reuse all my sequences tied to AXI_transfer items. What would be the best methodology?
My idea is that I define a base_transfer extended from sequence_item and extend AXI_transfer and AHB_transfer from this base_transfer. Also, I modify all my sequences to be parameterized with this base_transfer type. Now, in my uvm test, I can do base_transfer::type_id::set_type_override( AXI_transfer::get_type()); if I need to use AXI_transfer or base_transfer::type_id::set_type_override( AHB_transfer::get_type()); if I need to use AHB_transfer. For driver, I need to develop two drivers -- one for AXI and the other for AHB.
Do you think this would work? If not what other methods are recommended?
Upvotes: 1
Views: 751
Reputation: 1209
In general, I believe you seek a LAYERED approach. Your upper layer simply sends and receives abstract traffic. It's up to the lower layer to handle details of the protocol.
This is exactly the approach used by the uvm_register_adapter. See something like this: http://cluelogic.com/2012/10/uvm-tutorial-for-candy-lovers-register-abstraction
In practice, what is causing you to have a hundred different sequences for an interface? The things that are causing you to create additional sequences are quite likely the kind of things that will cause difficulty translating between protocols. Your AXI/ACE will certainly use memory barriers, but how are you going to create them on an AHB interface, for instance?
Upvotes: 0