Jump to content

Are concurrent accesses possible with a user defined uvm_reg_frontdoor?


Recommended Posts

Because the uvm_mem implementation breaks burst_write and burst_read transactions into a series of individual transaction and we are using an AXI bus where I want actual bursts, I choose to implement an uvm_reg_frontdoor that could create transactions (1 to max) to be sent to our AXI agent.

This worked well until I attempted to have 2 threads simultaneously use that memory to write the design. What I get is the following error:

UVM_FATAL @ 705.00 ns: uvm_test_top.va_env.axi2.master_env.master.sequencer@@fd_access_1 [sEQ_NOT_DONE] Sequence uvm_test_top.va_env.axi2.master_env.master.sequencer.fd_access_1 already started

What I believe is happening is that for each mem/map there is only a single *instance* of the frontdoor (actually a sequence). The uvm_mem starts this sequence every time it gets a new write or read. For the simultaneous case, this results in the second transaction trying to (re)start the running sequence.

This doesn't happen when using a non-user defined frontdoor access because a new sequence_item is created for portion of the burst. If there are are bursts from multiple threads, the start_item() is called on different instances and this allows the agent sequencer to arbitrate.

Am I missing something? Is there a better way to get uvm_mem to generate bursts?

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...