uvm_resource locking interface seems to be broken

[Erling]

Consider these statements:

initial begin

uvm_resource#(int) r = new();

r.write_with_lock(123);

r.read_with_lock(v);

end

The code fails with these errors:

"# UVM_ERROR @ 0: reporter [LOCKED_WRITE] Resource is locked and cannot be modified at this time"

"# UVM_ERROR @ 0: reporter [LOCKED_READ] Resource is being read by the non-locking interface while it is locked by the locking interface. This could result in the incorrect value being returned"

Anyone who happens to know how reading a resource could result in the incorrect value being returned? I can't find any read/write or write/write conflicts in the normal resource read/write interface.

Regards,

Erling

[Tedd]

Hi Erling,

I suspect this is a uvm-1.0p1 bug.

BR,

Tedd

[Tedd]

already fired , http://eda.org/svdb/view.php?id=3411

[Erling]

already fired , http://eda.org/svdb/view.php?id=3411

The bug seems to have been fixed by removing the locking interface (and delegating locking to a policy class).

However, my concern is not as much about this particular bug, it is more about the rationale behind the locking interface and the threading policy of uvm in general. It seems there is no clear policy. For example, the excessive forking in uvm_objection can not work no matter what the runtime threading semantics are. At the other end of the spectrum are locking for apparently no valid reason. Consider write() of resource#(T) as an example, it boils down to an assignment:

val = t;

In order to have an write/write conflict here, an interleaving write would be required. But that can't happen on a system running uvm in a meaningful way.

What adds to the confusion is that uvm code for thread safe operation is not necessarily thread safe in itself, i.e. if it was really needed, it would be broken. For example, in resource::read(), there is a test on the lock_state being zero. But if thread safe operation is an issue here, then this test seems to be of limited value, since the lock_state can be non-zero immediately after the test. Also, in resource::lock, the semaphore used for locked operation is put before the lock_state is updated. One should think that these statements would have to be reversed for thread safe operation.

I wish someone could clarify what threading issues (in execution time) users of uvm has to think about. Threading in simulation time is hard enough, and doubts and uncertainty about threading in execution time is not going to help. If uvm experts can come up with code like the resource locking interface, what then about the users, how are they going to deal with unclear threading semantics?

Regards,

Erling