Jump to content

Logger

Members
  • Content Count

    62
  • Joined

  • Last visited

About Logger

  • Rank
    Junior Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You should use a register model with multiple uvm_reg_maps. One per interface. Assuming you're generating your register model using some sort of tool (rather than by hand), you need to find out how your tool supports that.
  2. You need to provide more detail. Like, why do you currently have to select one at compilation time? What exactly do you mean by parallel access? Do you have 3 separate physical interfaces which can simultaneously access the same register? Or as often the case, do you have 3 masters which can all access the same registers via a fabric and a single physical interface to the registers? What are you using for your register model? RAL ( uvm_reg ) ?
  3. Looking for suggestions on the best approach to modeling something akin the following. value1 and value0 are implemented as value_reg[31:0] in RTL. The value actually stored in this register is always whatever you wrote to it. However, what you read back, and what HW sees when it looks at this register depends on the value of value_mode. When value_mode == DIRECT, you'll read back the whatever value is physically stored in value_reg[15:0] as value0 and value_reg[31:16] as value1. When value_mode == MULT, you'll read back a computed value instead. Let quotient == value_reg[15:0
  4. The short answer is yes. However, from the way you worded your question, I'm immediately inclined to use the PLI/VPI instead of the DPI. There are a lot of ways to skin this cat. If you want more guidance, you'll need to give more details about what you're trying to accomplish.
  5. Seen quite a few posts on various forums like this. Moving your register model to UVM-1.2 yields a bunch of warnings like this. [uVM/RSRC/NOREGEX] a resource with meta characters in the field name has been created As far as I can tell this is a bug in uvm_reg_block::configure(). If special regex characters are not allowed in the call to uvm_resource_db#(uvm_reg_block)::set(), then this function needs to sanitize the return value from get_full_name before passing it to set. get_full_name() is return hierarchical paths with dots in them, as it is supposed to, but those are regex ch
  6. This section of the LRM is vague. 18.11 In-line random variable control What is the expected behavior for the following code? class child; rand int a; rand int b; constraint cb { a inside {[0:100]}; b inside {[0:(2*a)]}; } endclass class parent; //Uncomment to force desired behavior: rand int a; rand child c; constraint cb { //Uncomment to force desired behavior: a == c.a; c.b >= c.a; } //Uncomment to force desired behavior: function void pre_randomize(); //Uncomment to force desired behavior: a = c.a; //Unco
  7. Bonus points for testing what happens when you change the constraint to the following: constraint c_1 { soft var1<100; }
  8. What am I missing here? Say you model an APB transaction that includes a cycles_before_delay member. The driver will have to implement that like this: seq_item_port.get_next_item( item ); // stall for item.cycles_before_delay; // do transaction seq_item_port.item_done( ); During that stall, no other transaction will be able to execute on that driver. Now there was the suggestion of forking this, but you can't call get_next_item() again, until you first call item_done(). Calling item_done() before the transaction is actually completed, is a non-blocking completion model, as the sequen
  9. So in the scenario where the spec says write register A, then wait 40 cycles before writing register B. You propose modeling that 40 cycle delay at the end of A, or the beginning of B. I know that is how a lot of models do it, but that doesn't make it right. In the case of APB, I'd like to allow other sequences to write to other registers during that delay. Which implies I now need to implement what otherwise would have been a simple in order atomic driver, as a non-blocking driver, so it can fork threads and return immediately. In addition to that, the sequence using the APB transa
  10. Good points. I've been real lazy about directly referring to m_sequencer rather than using get_sequencer(). You point out a good reason to stop that. I concur. I don't like this approach for two reasons: First and foremost, the delay before or after a transaction is not part of that transaction (mixing abstractions agains), but it is part of the sequence containing that transaction. Hence, the sequence needs some mechanism to perform delays. And time based delays doesn't cut it, so it needs to be cycle delays. Second, it requires you use a non-blocking
  11. I kind of have a gripe against directly referring to the interface from a sequence for these common use case scenarios. Different sequences on different interfaces can be doing the same thing, but implement it differently and it looks different. m_sequencer is the window/proxy by which a sequence knows which interface it is operating on. I was just meaning to say a virtual wait_cycles() method in the uvm_sequencer_base, would make it possible for all sequences to call m_sequencer.wait_cycles(x) without having to refer directly to the interface. That of course adds the burden of having to ex
  12. I have made it a standard practice to add a wait_cycles() task to all my sequencers to abstract this. Then in my sequences I can simply write: p_sequencer.wait_cycles(x); This requires you use the `uvm_declare_p_sequencer() macro in your sequence. Too bad that's not built into uvm_sequencer. -Ryan
  13. But that's the problem, this "standard operating procedure" is not a documented procedure, nor is it a single procedure. No two people do it the same way, and good luck finding an example when you google or search the UVM forums. You'll mostly likely come across someone raising the question, but it's never answered. So is there no canned solution, because we haven't yet agreed on how this should be implemented in the general case? Or is it just one of those things that UVM hasn't gotten around to yet?
  14. It would be really nice to be able to receive TLM messages in some sequences for the purposes of coordinating stimulus with monitored events. I have a solution which gets the job done, but it's not as clean as it should be, and this missing feature feels like a gaping hole in the methodology. I think a very nice solution would be to have uvm_analysis_imp#() class either implement the get() method, or maybe more clearly have a new method called wait_for_write( T t ). You could then extend your sequencer to have a uvm_analysis_imp#(), and use `uvm_declare_p_sequencer() in your sequen
×
×
  • Create New...