Although it is possible to avoid creating a fully specified AXI item, I recommend against it. But first, I’ll address your question.
uvm_reg_adapter only supports converting to/from sequence items that fully specify register transactions.
The alternative is to use a translation sequence. It’s poorly documented and not used as much, so it’s hard to find examples. The following article, which is focused on using a translation sequence to implement support for register bursts, covers the topic pretty well.
Back to my advice against doing this. Using this approach effectively makes uvm_reg_item your fully defined sequence item. AXI has order dependencies between the various channels, and that is why I recommend against this approach for AXI.
If you think only of the simplest case, where you issue a series of register reads and writes from a single sequence ( using a single value of AWID/ARID ), then it’s straight forward. However, once you account for multiple sequences running concurrently with different IDs, each arbitrating to get access to the proper channels in the proper order, going through a fabric where different slaves respond at different rates, it quickly get’s much more complicated.
You will need to embed all of this coordination logic into your register translation sequence, which is possible. The problem is, this logic is not unique to register sequences. You also need to enforce these ordering rules when directly issues transactions on the AXI without using the register model.
You might think, well I’ll just directly use uvm_reg_item as my transaction type when I want these ordering rules enforced. The problem is, uvm_reg_item does not expose all of the AXI features, so you won’t have full freedom to model any possible AXI transaction. For these reasons, it’s best to define a fully defined axi_item.