Jump to content

Recommended Posts

Posted

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?

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.

×
×
  • Create New...