uvm_reg predict() and mirror() interaction.

[mszabo]

My system has a bunch of status registers that are relatively easy for my scoreboard to predict, however accessing these registers goes through a multi master bus that may have a relatively long arbitration period.

I had planned on having my scoreboard call predict() whenver it detects a status register will change, meanwhile an independant sequence would just randomly call mirror() to check that my device correctly updated the status register.

The problem I have encountered is calls to predict() fail when it detects a race condition where the monitor sequence was actively reading the register being changed. At this point the scoreboard knows about the new value and in all likelihood by the time the actual bus transaction occurs the device will return the new value and mirror() will generate an error.

It seems somewhat backwards to me that predict() generates the race condition warning and fails to actually update the mirror value. Wouldn't it be better if mirror() detected the race condition and skipped the compare? For my system I wouldn't mind losing out on a couple of random register compares (they are random after all), as the alternative generates hard miscompare errors (as the mirror is never updated).

Is there an elegant solution to this problem? I suppose I could create a queue that handles updating the register models mirrors and will keep trying until the register isn't busy, but then there is still the issue of the mirror() call failing in the meantime.

I somewhat punted here with my monitor sequence calling get() before and after a read() and performing a manual compare only if the two get values match() this works in my system as it isn't possible for a register to change from A to B back to A while a single read is pending. I also had to 'cheat' and call predict() with UVM_PREDICT_READ instead of UVM_PREDICT_DIRECT as this bypasses the errors, this only works because I don't have any "RC","RS" register fields.

Overall this seems like a bit of a hack, but any other fix seems just as bad. I'm hesitant to directly derive a new class from uvm_reg and do my own thing with regards to prediction and mirroring since a) My register model is comprised of automatically generated code and I don't want todo something that becomes problematic when new versions of the UVM standard is released.