During development of the Accellera UVM 2017 Implementation, the UVM Working Group has encountered the following issues which resulted in the implementation deviating from the 1800.2-2017 standard.
- The
uvm_callbacks::get_all
method as defined in section 10.7.2.5 is insufficient to retrieve all callbacks registered on a given instance of an object, as there is no way to filter based on an object instance. The implementation adds an additional argument to the method to overcome the issue of resolving the instance specific callbacks.
The implemented signature is:
static function void get_all ( ref CB all_callbacks[$] , input T obj=null );
- The
uvm_packer::set_packed_*
anduvm_packer::get_packed_*
methods as defined in sections 16.5.3.1 and 16.5.3.2 usesigned
arguments while theuvm_object::pack
anduvm_object::unpack
methods are specified in sections 5.3.10 and 5.3.11 asunsigned
. The implementation keeps the argumentsunsigned
, so as to remain consistent with the other packing APIs.
The implemented sigatures are:
virtual function void uvm_packer::set_packed_bits( ref bit unsigned stream[] ); virtual function void uvm_packer::set_packed_bytes( ref byte unsigned stream[] ); virtual function void uvm_packer::set_packed_ints( ref int unsigned stream[] ); virtual function void uvm_packer::set_packed_longints( ref longint unsigned stream[] ); virtual function void uvm_packer::get_packed_bits( ref bit unsigned stream[] ); virtual function void uvm_packer::get_packed_bytes( ref byte unsigned stream[] ); virtual function void uvm_packer::get_packed_ints( ref int unsigned stream[] ); virtual function void uvm_packer::get_packed_longints( ref longint unsigned stream[] );
- The
uvm_phase::get_objection
method is defined in section 9.3.1.7.1 as being non-virtual
. The implementation has made the function virtual to ensure uniformity with the other Phase done objections methods defined in section 9.3.1.7.
virtual function int uvm_phase::get_objection_count( uvm_object obj=null );
- The
uvm_printer
anduvm_comparer
classes have methods defined for configuration in sections 16.2.5 and 16.3.4. Each of these configuration values is specified as being cleared via a call toflush
; however sinceuvm_object
always callsflush
on these policies when they're invoked with an active object depth of 0 (see 16.1.3.4), only the default values could ever be used. The implementation does NOT clear these values on a flush.
- The
uvm_printer::set_default
,uvm_table_printer::set_default
,uvm_tree_printer::set_default
, anduvm_line_printer::set_default
methods defined in sections 16.2.2.2, 16.2.10.2.3, 16.2.11.2.3, and 16.2.12.2.3 allow the user to set the associated default printer instances. The standard does not explicitly call out what happens when these default values are set tonull
, indicating that all of the associatedget_default
calls should be guarded withnull
checks on the return value. Instead of forcing these checks on the user, the implementation ensures that the return value will never benull
. Whenget_default
is called after a correspondingset_default(null)
, the implementation returns the printer instance that would have been returned ifget_default
had been called without any previous calls toset_default
.
- Section 16.4.7.7 states that the
uvm_recorder::do_record_object
method ispure virtual
, while also stating that it has a default implementation. As it is impossible to provide a default implemntation to apure virtual
method in SystemVerilog, the implementation declares the function asvirtual
.
purevirtual protected function void do_record_object(string name, uvm_object value);
- The
uvm_resource_db::read_by_name
anduvm_resource_db::read_by_type
methods are defined in sections C.3.2.2.6 and C.3.2.2.7 as having an output argument val of type T. This is backwards incompatible with previous UVM versions, and would result in the user needing to keep additional copies values in order to avoid a failed read overwriting a previous value. As such, the implementation keeps the arguments as inouts to avoid these problems.
static function bit uvm_resource_db::read_by_type(input string scope, inout T val, input uvm_object accessor = null); static function bit uvm_resource_db::read_by_name(input string scope, input string name, inout T val, input uvm_object accessor = null);
- The
uvm_sequence_base::do_kill
method is defined in 14.2.5.12 as being non-virtual
. This runs in contradiction to the fact that the method is defined as being a user hook. As such, the implementation declares the method asvirtual
to allow extension.
virtual function void do_kill();
- The
uvm_sequencer_base::ungrab
anduvm_sequencer_base::unlock()
methods are specified in sections 15.3.2.12 and 15.3.2.13 as being tasks. This is backwards incompatible with prior UVM releases, and produces a problem for any user code which needs to unlock in zero time. As such, the implementation declares the methods asfunction void
.
virtual function void unlock( uvm_sequence_base sequence_ptr ) virtual function void ungrab( uvm_sequence_base sequence_ptr )
- Section 18.2.3.5 says that an address map may be added to multiple address maps if it is accessible from multiple pysical interfaces. This map structure was not supported in UVM1.2 and an attempt to add to multiple address maps would result in an error. Adding such support will require extensive rework and likely API enhancements, which was not in the scope of the 1.0 implementation effort. This implementation will still produce an error if an address map is added to multiple address maps.