Multiple threads writing to different fields of a config register

[horacelau]

I have a case where there is a config register with many fields that will be set separately from different sequences/threads.  Initial thought would be to do a read-modify-write on the register from each thread.

 

Is this necessary?  The register model should contain the current value of the register (assuming no passive funny business)?  So does this mean the read is not necessary and the threads can jump straight to calling set() on the field they want to modify?

 

Assuming the threads are trying to write different fields of the same register, if the threads are each doing field.set() and reg.write(), are there any scenarios where some thread's new field value gets clobbered?

 

I guess ultimately what I'm trying to figure out is if I need to implement an atomic RMW method for this register, or does UVM allow for the operations described above in a value-safe way?

 

[tudor.timi]

I'm not sure how arbitration works at the register read/write level, but if you have 2 writes scheduled because the bus sequencer is busy with some other transaction, I could imagine that you can run into some "unexpected" behavior. I could see a scenario where the following happens:

 

- bus sequencer is busy doing some item

- thread 1 does field1.set() and starts waiting

- thread 2 does field2.set() and starts waiting

- item finishes on bus sequencer

- thread 1 gets the sequencer, writes the val (reg with both fields set)

- thread 2 gets the sequencer, writes the same val as thread1 wrote

 

This won't "clobber" any field value, but it will just do the same write twice, which shouldn't be a problem.

[horacelau]

It matters less to me if the same value is written more than once, as long as there's no scenario where one of the values gets clobbered.

 

What happens if I dumbly do a read-modify-write?  Is it possible that with certain timing, that the overlapping read/modify stages could possibly clobber something?  Is it bad form to do a read because uvm_reg is supposed to keep proper state of the register?

[tudor.timi]

I don't see why doing a read would be bad form, seeing as how this is most probably how the real software would work. The fact that you have the state of a register stored and can rely on it is a "nice-to-have". If you want to do RMW, what you want to ensure is that this is treated as an atomic operation, i.e. there are no other accesses in between. To do this you can grab your register sequencer before doing the read and ungrab it after doing the write.