Jump to content

ddayan14

Members
  • Content Count

    5
  • Joined

  • Last visited

About ddayan14

  • Rank
    Member

Recent Profile Visitors

437 profile views
  1. Yeah, I followed Tudor's suggestion: typedef class indirect_reg_map; class my_reg_block extends uvm_reg_block; semaphore blk_sema; ... new, build with indirect map ... endclass class indirect_reg_map extends uvm_reg_map; my_reg_block model; // We override the do_read/write tasks and implement the indirection task do_read(uvm_reg_item rw); model.blk_sema.get(); ... model.blk_sema.put(); endtask ... endclas
  2. Hi Tudor, Not yet, it's on our fallback options. But just counting the number of registers, we're talking about create additional tens of thousands of sequences. I'm sure you can agree even before trying that there are much better options. I'm now thinking about overriding the start task of the frontdoor sequence on do something like this: virtual task start (uvm_sequencer_base sequencer, uvm_sequence_base parent_sequence = null, int this_priority = -1, bit call_pre_post = 1); semaphore.get(); super.start(sequencer, paren
  3. Locking the sequencer will not work since the FATAL is caused even before it enters the arbitration queue. The sequence is in a "Running" phase, and trying to start it again will cause the error. Locking the reg_adapter sequencer can work only when no frontdoor sequence is involved. How can I specify a different sequence to each thread? They don't even use it directly, they simply do something like: reg_model.reg_a.write(...) Trying to synchronize all threads that are accessing the reg_model is pointing me to somehow have a semaphore on the reg_map. But then again, I'm not really sure how..
  4. Hi We're trying to use a used defined frontdoor sequence for our register model. Most of our registers are accessed through an indirection mechanism, so creating a custom frontdoor sequence looks like the way to go. Everything works well, except when parallel threads are trying to simultaneously access the model (*NOT* to the same register of course) we're getting into some trouble - the frontdoor sequence is started again causing a UVM_FATAL error. Here's the code from uvm_reg: // ...VIA USER FRONTDOOR if (map_info.frontdoor != null) begin uvm_reg_frontdoor f
×
×
  • Create New...