DavidLarson

For 1: You can use the schema files provided by Accellera. Run them with xmllint. For 2: No. Pretty sure there isn't an open-source tool to do that for you.

Forget my last question. I believe I figured it out. Now to figure out how to put hdl_paths in a hierarchy....

Thank you Erwin. Yes that does help. Our situation is a little different, where we have a hierarchy of components, each with their own bank of registers. So, we won't be looking to connect sibling components, but connections would be from parents to children. Can that be done with IPXACT?

Hi Erwin, Thank you for the info. I've been reading through the User Guide and it doesn't seem to provide all the info I need to do this. For example, in section 3.1.6 it says: Yet, it doesn't explain how to put a memoryMap in an addressSpace. You can only put segments in addressSpaces, not memoryMaps. Can you please provide an example of what that would look like? Regards, David

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.

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?

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

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?

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.

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.

Hi Jadec, Yes, that makes sense. Thanks, David

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

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

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.

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?

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

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.

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

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

Actually, now that I think about this more, I would create an analysis port in the monitor that the driver subscribes to. The monitor would advertise what it saw and the driver can react to it.

Hi kumarv. This is a great question. This class does indeed look very VMM-ish. I haven't used the class before, but I'd like to see if I could use it as my test case somehow (that seems to be the usage model), though test cases should be extended from uvm_test, not from uvm_random_stimulus. I'll play around with it.

Yes, I agree with yangyuf. Semaphores are the way to go. You could even get fancy and pass the reference of the semaphore to the monitor and driver through uvm_config_db#(semaphore) (not tested, though).

Hi Peter, Wouldn't setting byte_addressing to 1 configure the map to be addressed on a byte-boundary? Don't we want the addresses to be n_bytes apart (set to 0)? Thanks, David

Hi Peter, The tool we are using creates this call to create_map(): default_map = create_map("", 0, 4, UVM_BIG_ENDIAN, 0); Does that help? Thanks!