Jump to content

DavidLarson

Members
  • Content count

    32
  • Joined

  • Last visited

  1. I'm going through the HAL documentation and it looks l like the only languages that HAL supports are: Verilog, VHDL, SystemC and e. No system verilog. Rats.
  2. I have found a related problem. When you need to send a 1 to a W1C register field, the normal flow doesn't work: register_model.register.w1c_field.set(1); // <--- this is set to 0 internally register_model.register.update(status); This is clearly not what the user expects. What is the correct flow for these registers?
  3. I can see that the uvm_heartbeat hasn't been updated to fix this bug: http://forums.accellera.org/topic/1256-bug-uvm-heartbeat-does-not-respect-the-comps-list
  4. DavidLarson

    Welcome to the UVM 1.2 Public Review

    I can see some very old code that should be cleaned up (such as the uvm_in_order_comparator). What is the timeline for a general code clean up?
  5. I just compiled your code (I added the endclass keyword): class addr_hole_seq extends uvm_sequence # (uvm_sequence_item); `uvm_object_utils(addr_hole_seq) endclass and it compiled fine. Now you need to check elsewhere ... the code preceding this, how you are compiling, etc.
  6. I see errors like this when the macro is not called correctly. Check these: If the object is parameterized you should be using `uvm_object_param_utils (<object_name>#(<parameters>)). make sure that the argument to the macro contains the name of the class and there are no typos. Make sure the registration macro isn't called more than once. Other than that, it would be helpful to see your source code.
  7. Hi Jadec, Yes, that makes sense. Thanks, David
  8. Hi Jadec, I agree that the get function is expensive, but calling it from the sequencer (rather than the sequence) is just as expensive since it is called the same number of times either way. David
  9. Hi mrforever, I just checked the UVM 1.1d library and the macro still exists. (phew!) You should email your question to support@synopsys.com (I think that's the right address) and a FAE will get back to you. Good luck! David
  10. If you are using a pre-compiled version of the UVM library then the macro will not change it. If you are not using a pre-compiled UVM library, then I would contact the Synopsys FAE and ask them what needs to change in your compile flow. I'm sure that the fix is something simple.
  11. Yes, I agree Logger. Since you have several items in your TB needing this setting then using the configuration DB is the way to go (vs. setting the items directly). BTW: Have you tried using uvm_resource_db instead?
  12. Hi mrforever, It looks like you are passing in the UVM_USE_CALLBACKS_OBJECTION_FOR_TEST_DONE macro as a run-time argument. It needs to be passed in during the compilation phase with a +define. Good luck and enjoy the heartbeat! David
  13. The uvm_config_db is used primarily to configure uvm_components. This is a snippet from the reference manual (italics are mine): The uvm_config_db class provides a convenience interface on top of the uvm_resource_db to simplify the basic interface that is used for configuring uvm_component instances. Regardless, I find that it is far better to set the variable directly. The real power of the resource DB is when the wildcard can be used in the path, but that doesn't apply to you in this case.
  14. Hi mrforever, I'm not sure if I understand your question correctly. It sounds to me that the forever loops in the monitor and sequence are intentional (not bugs)? So the sequence is sending background traffic? If so, then I would be sure that your sequence is not issuing objections. The monitor will continue to issue objections (raising at the beginning and dropping at end of the transaction), but that shouldn't prevent the test from ending, because as soon as the last transaction completes then all of the objections will be dropped. I would also be sure that you aren't setting a drain time anywhere. If you are, then the background traffic sequence will send another transaction before the drain time completes, raising objections again in the monitor and you'll never get out of it. HTH, David
  15. Hello, I am using the uvm_heartbeat object in my test bench and found that it always watches for all objection activity under the context component. By definition, it should only watch for the list of components registered to it. I found this when registering only one component to watch (my interrupt handler) and even after the component had no activity long after several heartbeat windows, a fatal HBFAIL message was not issued. Digging into the source code, I can see that the heartbeat keeps track of which components are registered by populating an associative array, like this: function void set_heartbeat (uvm_event e, ref uvm_component comps[$]); uvm_object c; foreach(comps[i]) begin c = comps[i]; if(!m_cb.cnt.exists(c)) // <-- This is the code to track... m_cb.cnt[c]=0; // <-- which components are registered if(!m_cb.last_trigger.exists(c)) m_cb.last_trigger[c]=0; end if(e==null && m_event==null) return; start(e); endfunction Skipping forward to the uvm_heartbeat_callback class, a counter is incremented every time a component raises or lowers an objection. When a component isn't found in the "cnt" associative array, it should have ignored it, but instead it sets a new index and sets the value to 0: virtual function void raised (uvm_objection objection, uvm_object obj, uvm_object source_obj, string description, int count); if(obj == target) begin if(!cnt.exists(source_obj)) cnt[source_obj] = 0; // <-- this is the bug cnt[source_obj] = cnt[source_obj]+1; // <-- BTW: isn't cnt[source_obj]++ faster? last_trigger[source_obj] = $realtime; end endfunction Instead, the code should have been written like this: virtual function void raised (uvm_objection objection, uvm_object obj, uvm_object source_obj, string description, int count); if(obj == target) begin if(!cnt.exists(source_obj)) return; // <-- bug fix cnt[source_obj]++; // <-- (seems like it should be faster) last_trigger[source_obj] = $realtime; end endfunction I have tried this change in my workspace and it works well. Thank you, David
×