Scenarios for return of "UVM_NOT_OK" as status from a RAL-based read

Hi All,

During front-door read access from a register, I am faced with the return of an erroneous status being returned in the form of ‘UVM_NOT_OK’. This begs me to raise the following question:

Under what situations is such a status returned? And why is it returned in the first place? How do I overcome or work-around such a condition?

Would appreciate your inputs.

Regards,
Kautilya

In reply to kautilya87:

Generally for read operation, whenever bus transaction are converted to register transaction using bus2reg API of reg_adapter, status is assigned to the rw.status.
Please note that, based on interface behavior you have to assign the status to register transaction handle of bus2reg() method.

In reply to mitesh.patel:

In reply to kautilya87:
Generally for read operation, whenever bus transaction are converted to register transaction using bus2reg API of reg_adapter, status is assigned to the rw.status.
Please note that, based on interface behavior you have to assign the status to register transaction handle of bus2reg() method.

Thanks for the reply, Mitesh. Could you also tell me why the “UVM_NOT_OK” status should be obtained? I understand that the ‘status’ is assigned to ‘rw.status’ but under what scenarios does it return an erroneous ‘UVM_NOT_OK’ or an ‘UVM_IS_OK’ status?

Regards,
Kautilya

In reply to kautilya87:

Its totally depends on interface of protocol, which is connected with RAL model. RAL doesn’t provide any erroneous status. user has to implement register adapter and based on protocol requirements, user can update the status in bus2reg() method of adapter.
Converted register transaction returns the read value.

In reply to mitesh.patel:

So, essentially, a status of “UVM_NOT_OK” or any status, for that matter, can be corrected by reviewing the RAL adaptor?

Regards,
Kautilya