In p.433 of the UVM class reference manaul, sequence.kill() refers to a sequencer.unregister_sequence() method.
Where is the unregister_sequence() method? It is not in the sequencer API?
Horace
↧
where is the sequencer.unregister_sequence() method?
↧
UVM events with data.
Hi,
In UVM 1.2, the UVM event class is declared as follows:
class uvm_event#(type T=uvm_object) extends uvm_event_base;
The trigger function has the following line of code:
uvm_event_callback#(T) tmp=callbacks;
The assignment to callbacks, refers to the uvm_event_base member callbacks[$].
The uvm_event_base is not parameterized, and callbacks[$] is declared in uvm_event_base as:
protected uvm_event_callback callbacks[$];
Thus, making the parameterized type of callbacks[$] the default of callbacks[$], which is uvm_object.
How can the uvm_event be parameterized to a non uvm_object? There is no casting done in the trigger function. Lets say that I tried following:
class uvm_object_extend extends uvm_object;
...
endclass
uvm_event#(uvm_object_extend ) my_event;
My compiler generates and error indicating that in the trigger function, the assignment of:
uvm_event_callback#(T) tmp=callbacks;
in the trigger function is not valid, since callbacks in the uvm_event_base is of parameterized type uvm_object, but uvm_event_callback#(T) is of parameterized type uvm_object_extend.
This seems to be an issue in UVM, or am I not using this correctly? Does anyone have experience with uvm_events which use extended uvm_objects for data passing?
Thanks,
Borna.
↧
↧
Incorrect prediction of uvm_reg_field
Hello,
I am using UVM RAL (UVM 1.2) and have the following problem. When using explicit prediction and the adapter's flag "supports_byte_enable" is set to 1, and when a bus write transaction happens to a register containing a multi-byte field, sometimes the register is not predicted properly.
This happens when the byte_en is not set to all 1's. The adapter's bus2reg() method correctly passes the byte_en value to the uvm_reg_bus_op object, however the uvm_reg_field's "do_predict()" method does not make good use of it.
So it happens that when byte_en[0] == 1 the entire multi-byte field is updated, regardless of the value of the other byte_en bits. Similarly, when byte_en[0] == 0 the entire multi-byte field is NOT updated, regardless of the other byte_en bits.
In my particular case, I am using APB 2.0 (AMBA 4) with PSTRB and the data width is 16 bits. When a write transaction happens on the APB bus with PSTRB[1:0] == 2'b01 to any given "RW" register containing a single 16-bit field, the entire register is updated in the UVM RAL while only the lower byte (LSByte) is actually written in the RTL. Again, if similar transaction happens with PSTRB[1:0] == 2'b10, the entire register is NOT updated in the UVM RAL while the upper byte (MSByte) is actually written in the RTL.
I consider it a bug. Could someone from the UVM working group review and file a Mantis ticket if really needed?
Thanks,
Stefan Yankov
↧
Problems with starting_phase
I'm trying to use the new get_starting_phase() mechanism in UVM1.2, but it's not working for me.
For UVM1.1, I have the following working fine:
task pre_body();
if (starting_phase != null)
starting_phase.raise_objection( this, get_type_name() );
endtask
In UVM1.2 RC8, I add:
task pre_body();
uvm_phase phase = get_starting_phase();
if (starting_phase != null)
starting_phase.raise_objection( this, get_type_name() );
endtask
This just doesn't work. get_starting_phase() returns null everytime and the objection is never raised so the simulation immediately ends.
Attached is a simple testcase - in UVM1.1 the sequence successfully waits for 20ns, but after adding get_starting_phase(), in UVM1.2 RC8 the simulation ends immediately.
Have I misunderstood how get_starting_phase is suposed to work?
↧
M_UVM_FIELD_QDA_INT does not work with dynamic arrays or queues
I've found a use for set_int_local and noticed that it does not work with dynamic arrays or queues.
Issue can be demonstrated with this code: https://www.edaplayground.com/x/6B8e
The problem appears to be on the first line of this code block:
else if(uvm_is_match(str__, {__m_uvm_status_container.scope.get_arg(),$sformatf("[%0d]", index__)})) begin \
if(index__+1 > ARG.size()) begin \
int sz = index__; \
int tmp__; \
`M_UVM_``TYPE``_RESIZE(ARG,tmp__) \
end \
if (__m_uvm_status_container.print_matches) \
uvm_report_info("STRMTC", {"set_int()", ": Matched string ", str__, " to field ", __m_uvm_status_container.get_full_scope_arg()}, UVM_LOW); \
ARG[index__] = uvm_object::__m_uvm_status_container.bitstream; \
__m_uvm_status_container.status = 1; \
end \
At this line, str__ is set to "cfg.arr_var[0]", this:
{__m_uvm_status_container.scope.get_arg(),$sformatf("[%0d]", index__)}
evaluates only to "arr_var[0]", hence the match does not succeed. I believe that the code would be correct if it used get() instead of get_arg().
↧
↧
stop_sequences / stop_phase_sequence
↧
class uvm_test_done_objection
Hi. I would like to confirm if the class type uvm_test_done_objection is deprecated in IEEE 1.2 release or in future releases.
in Accellera uvm.1.2
//------------------------------------------------------------------------------
//
// Class- uvm_test_done_objection DEPRECATED
//
// Provides built-in end-of-test coordination
//------------------------------------------------------------------------------
class uvm_test_done_objection extends uvm_objection;
But in the other source code, i see it is still being used.
Thanks
Best Regards
↧
uvm_factory performance improvement for object creation
Hi,
As I read the code in uvm-1.2 package, the type override lookup (by uvm_default_factory::find_override_by_type()) seems to be done every time a new UVM object is created.
This really hurts performance because object creation happens most frequently in a UVM environment.
My idea is: The implementation needs to be changed so that the type override info is put inside each object proxy, instead of a factory's queue (m_type_overrides). When set_type_override_by_type() is called, it sets the override info for every affected object proxy. So when a new object is created, we just use the override info already available inside its proxy to do creation and no more type override lookup needed. The call of set_type_override_by_type() should happen much much less frequently than object creation, I believe.
The override info for each object proxy should have 2 element as below:
- override: the type that overrides this type
- override_to[$]: a list containing all types that are overriden by this type.
so that when set_type_override_by_type() is called, we can traverse all the affected types regardless of the calling order of multiple calls of set_type_override_by_type(). For example:
- set_type_override_by_type(): B overrides A
- set_type_override_by_type(): C overrides B
then finally C must override A regardless of 1. or 2. being executed first.
Best regards,
Thien
↧
set_verbosity inside the uvm_report_catcher.
Does anybody know how the set_verbosity works inside the uvm_report_catcher. As I understand default verbosity is UVM_MEDIUM hence I set the verbosity to UVM_HIGH so the message wont get displayed. Looks like the message is still getting printed on the logfile, another workaround is to use set_action(UVM_NO_ACTION). but what shld be the correct value to set in the set_verbosity("") so that it wont display on the logfile.
Example here:
edaplayground.com/x/4T8p
↧
↧