Should UVM RAL write/read be used in UVM test, sequence or driver?

I have a testbench currently where I have register writes directly from a uvm_test using the uvm_reg function write(), although I’m not sure if this is the recommended way in doing things. Reading some forum items I keep reading on how we shouldn’t have any delay elements in any uvm_components, except for uvm_driver. This made me wonder, since register writes eventually devolve to bit-banging the necessary signals that have delays, should they reside in the driver? What is recommended?

In reply to kmcguire:

When stating that there should be no delay elements at the test level, this means that you should have no Delay or similar statements. A test will start many sequences, and each sequence may or may not consume time, but the time advancement will occur when the driver processes the associated sequence items.

Using the UVM RAL in the test sequence is appropriate. Even though the resulting sequence item will ‘bit bang’, this is done by the driver itself and not the RAL.

In reply to cgales:

Thank you so much for the response! Coming from writing directed testcases where it lacks re-use I think I see the importance of putting it in a sequence is the appropriate location.

If I understand correctly then, we should reserve the extended uvm_test to choose how we want to execute these sequences and the actual timing/delay of things is handled in the driver side.

Again, thank you for the clarification!