Logger Posted June 10, 2012 Report Share Posted June 10, 2012 Has there been any thought towards adding atomic accesses to the register layer? When trying to model and validate real firmware algorithms, I need to be able to block all but the desired thread from being able to execute registers accesses through RAL. Some flexibility is needed here. You should be able to lock a physical interface, meaning a thread could lock one interface for itself, but other threads could still use other interfaces. Or a thread should be able to lock a block, blocking other threads from accessing any register in the block regardless of the physical interfaces. After doing some experimentation with SV's fine-grained process control I believe the mechanism could be added to RAL without modifying any of the existing API, only some additions would be required. From the user's stand point, uvm_reg_block and uvm_reg_map would both gain lock() and unlock() tasks. Calling lock() would block all other threads from accessing that block or map. unlock() would like-wise release the current thread's lock. Multiple calls to lock() by different threads would be resolved in the implementation by a mutex. This also could be implemented without fine-grained process control, by adding an additional key parameter to all of the methods that cause a physical interface access. The default would be 0, so existing code doesn't need to change. Calling lock() would now need to return an integer key, which you would need to use anytime you are doing an atomic operation. After a quick examination of the classes, I do not see any way to layer this capability on top of the existing class library. I'd probably need the RAL classes to extend a `define macro, to enable me inserting this functionality at the right place. Anyone else interested in atomic RAL operations? -Ryan Quote Link to comment Share on other sites More sharing options...
janick Posted June 25, 2012 Report Share Posted June 25, 2012 That can be accomplished by grabbing the sequencer that corresponds to the address map where you want to perform an atomic operation. See uvm_sequencer_base::grab(). Quote Link to comment Share on other sites More sharing options...
Logger Posted June 26, 2012 Author Report Share Posted June 26, 2012 Are you implying that each RAL user that wants to do atomic operations needs to have it's own unique map? If two threads are both doing RAL accesses to the same map, I don't think one thread can use this method to lock out the other thread. Quote Link to comment Share on other sites More sharing options...
janick Posted June 26, 2012 Report Share Posted June 26, 2012 No, there must be only one instance of the register map as there is a semaphore in each register to ensure their access is atomic. All threads must go through the same map -- which will then go to the same sequencer. By grabbing that sequencer, a thread can lock the others out to ensure atomic operations. Quote Link to comment Share on other sites More sharing options...
Logger Posted June 27, 2012 Author Report Share Posted June 27, 2012 That works, thanks! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.