OSPI Register Model (unmapped register and non-register access)

[Henry]

Hello everyone,

I am trying to create a register model in UVM for an Octal Serial Peripheral Interface (OSPI) and have encountered the following two issues.

(1) One of the registers inside the OSPI Slave is not in the address map. This register is accessed through a specific command.

I know that in the register model we can specify that a register is unmapped when adding it (see below function add_reg). However, I don't know how to create/specify the "Handle to register frontdoor access object".

function void add_reg (uvm_reg rg,      // Register object handle
	uvm_reg_addr_t offset,              // Register address offset
	string rights = "RW",               // Register access policy
	bit unmapped=0,                     // If true, register does not appear in the address map
                                        // and a frontdoor access needs to be defined
	uvm_reg_frontdoor frontdoor=null);  // Handle to register frontdoor access object

Could you explain to me or give me an example on how to create this handle?

(2) I have created the register adapter, so my model can be explicitly updated whenever a transaction is detected by the monitor.

However, not all transactions are register accesses, so the bus2reg function needs to ignore them, but I don't know how.

// bus2reg
virtual function void bus2reg(uvm_sequence_item bus_item, ref uvm_reg_bus_op rw) ;
    spi_transaction spi_tx ;

    if ( !$cast(spi_tx, bus_item) ) begin
        `uvm_fatal("Not an OSPI Transaction", "Wrong type for bus_item")
    end

    rw.kind   = ... ;
    rw.addr   = ... ;
    rw.status = ... ;
    rw.data   = ... ;

endfunction: bus2reg

I would like to know how can I ignore those transaction inside the bus2reg function. As far as I know, the transaction is an OSPI transaction,

but it's neither a UVM_WRITE nor a UVM_READ, so what kind of value will rw.kind take?

 

If something is unclear, please let me know.

Thank you in advance for your help.

[chr_sue]

I believe you have a wrong understanding of the UVM RAL. A few aspects only:

(1) the frontdoor sequence you are mentioning is not frontdoor/backdoor. It is a specific class to define a complex sequence related behavior. See the UVM Ref.Manual for the details.

(2) the OSPI sequence does not go through the adapter using reg2bus and bus2reg.

(3) The adapter is used to convert a generic UVM RAL sequence into a OSPI sequence.

(4) Each register sequences has to have a specific access type like RO, RW etc.

This might be a few ideas to work on your issue.

[Henry]

10 hours ago, chr_sue said:

I believe you have a wrong understanding of the UVM RAL. A few aspects only:

(1) the frontdoor sequence you are mentioning is not frontdoor/backdoor. It is a specific class to define a complex sequence related behavior. See the UVM Ref.Manual for the details.

(2) the OSPI sequence does not go through the adapter using reg2bus and bus2reg.

(3) The adapter is used to convert a generic UVM RAL sequence into a OSPI sequence.

(4) Each register sequences has to have a specific access type like RO, RW etc.

This might be a few ideas to work on your issue.

Hi chr_sue,

Thanks for your answer.

(1) Could you point me to the UVM Reference Manual? And do you know of any tutorials or examples on this?

(2) I forgot to mention it. In my current UVM environment I have a monitor that broadcasts all OSPI transactions to all subscribers. One of these subscribers is a spi2reg predictor. This is where I wanted to filter out transactions that were non-register accesses.

(3) Inside the adapter there are two functions: reg2bus and bus2reg. bus2reg is not only used by the adapter, but also by the predictor. So it not only converts UVM RAL sequences into OSPI transactions, but vice-versa.

(4) Yes, I know this.

[chr_sue]

I found an example on the Doulos webpage. The code is in the EDAPlayground:

https://www.edaplayground.com/x/4vf

Hope this helps.

[Henry]

Hi chr_sue,

Thanks a lot! I managed to implement the user-defined frontdoor.

I also solved my other issue by extending the uvm_reg_predictor, and overriding the write function.

I think this thread can be considered closed.