Jump to content


  • Content Count

  • Joined

  • Last visited

  1. Hi Justin, Thanks for your reply. I don't have the modified code yet. But I'd like to make my proposal clearer as below. The problems with the factory are: An associative array lookup step needs to be done to retrieve instance override info of requested_type: uvm_factory_queue_class qc; qc = m_inst_override_queues.exists(requested_type) ? m_inst_override_queues[requested_type] : null; Iterate through m_override_info queue to check for override loop. Iterate through m_type_overrides queue to check for type override. Recursive calls of find_override_by_type() for the case of "B overrides A, C overrides B, etc": (in function find_override_by_type) // inst override; return first match; takes precedence over type overrides if (full_inst_path != "" && qc != null) for (int index = 0; index < qc.queue.size(); ++index) begin ... return find_override_by_type(qc.queue[index].ovrd_type,full_inst_path); // type override - exact match foreach (m_type_overrides[index]) begin if (m_type_overrides[index].orig_type == requested_type || ... return find_override_by_type(m_type_overrides[index].ovrd_type,full_inst_path); All above things happen for every creation of a UVM object which uses the factory. So I propose to put type override and instance override information in the type proxy itself (i.e, uvm_object_wrapper), so that we can get the override info directly from requested_type and no more lookup needed. It's responsibility of set_type_override_by_type() to do all the awful stuffs, because this method is called only once for each override setting. The override info inside uvm_object_wrapper should be: ovrd_insts [$]: a queue of {<instance-path>, <override-type>} pairs for instance override. ovrd_type: for type override. Set to this type when the type specialization is created or registered to the factory. affected_types [$]: a queue of types that are overriden by this type. Used like a linked-list pointer for set_type_override_by_type() to traverse in the mentioned case "B overrides A, C overrides B, etc". Pseudo code of set_type_override_by_type (original_type, override_type) is as below: function set_type_override_by_type (original_type, override_type) { __set_type_override_by_type (original_type, override_type); // add original_type into 'affected_types' of override_type override_type.affected_types.push_back(original_type); } function __set_type_override_by_type (original_type, override_type) { original_type.ovrd_type = override_type.ovrd_type; // note: ovrd_type defaults to the container type // until it is overriden. // set override for each affected_type of original_type. // may be recursive for each affected_type child of that affected_type, ... foreach original_type.affected_types[i] { if original_type.affected_types[i] == override_type.ovrd_type error("Override loop detected"); else __set_type_override_by_type(original_type.affected_types[i], override_type.ovrd_type) } } Pseudo code of create_object_by_type (): no more lookup or recursive calls to find the override type. function uvm_object create_object_by_type (uvm_object_wrapper requested_type, string parent_inst_path="", string name); // ... code to make full_inst_path from parent_inst_path, etc as in current uvm-1.2 code // instance override. takes precedence over type override. foreach requested_type.ovrd_insts[i] begin if(uvm_is_match(requested_type.ovrd_insts[i].full_inst_path, full_inst_path)) return requested_type.ovrd_insts[i].ovrd_type.create_object(name); end // type override return requested_type.ovrd_type.create_object(name); endfunction The modification for this point is rather simple, but it may impact other functionalities such as factory.print() and name-based override. So please give me some time to do the modification thoroughly. I'll get back when it's done. Best regards, Thien
  2. 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
  • Create New...