Jump to content


  • Content Count

  • Joined

  • Last visited

About allancarter

  • Rank

Profile Information

  • Gender
    Not Telling
  1. The current write method sends a handle to a non-const object. This allows any subscriber to a uvm_analysis_port to modify the object in the monitor. This is BAD. To prevent this it would be ideal to make the write method take a const object. However, in SV the const keyword only affects the handle, not the object pointed to by the handle. In C++ you can make what the pointer is pointing to const. I don't see a way to do that in SV. Making the handle const is not useful in this case. With this language shortcoming, the monitor could copy its transaction before doing the write, thus ensuring that its copy can't be modiified. This would work, but a performance penalty would be paid for every write to an analysis port whether it was needed or not. If the object was declared const then it would force the subscriber to make a non-const copy only when needed. Am I understanding the limitation of SV correctly? If so, is there a request to fix it? If that happened, shouldn't the TLM interfaces be modified to pass const objects?
  2. The following fix gets rid of the null poiter reference: if (rw.local_map == null) begin if (rw.map == null) begin `uvm_error("RegModel", {"Register '", get_full_name(), "' is not registered with any map."}) rw.status = UVM_NOT_OK; return 0; end else begin `uvm_error(get_type_name(), {"No transactor available to physically access register on map '", rw.map.get_full_name(),"'"}) rw.status = UVM_NOT_OK; return 0; end end
  3. I guess related to this is that the following warning is output before this. Seems like it should be an error: UVM_WARNING /path/tools/uvm/uvm-1.1d/src/reg/uvm_reg.svh(1646) @ 0: reporter [RegModel] Register 'm_mem_block.regfile.regc' is not registered with any map
  4. I added a new register to a register block, but didn't add it to the map. When I try to read it in my test I get a null pointer access in: uvm-1.2c/src/reg/uvm_reg.svh, line 2624 The bug is that get_local_map returns a null pointer and rw.map is null because it wasn't specified in the read method. But the uvm_error macro references rw.map.get_full_name() when rw.map is null.
  5. I htink that the problem is in: uvm_port_base::size() function int size (); return m_imp_list.num(); endfunction For an imp with multiple ports connected to it this returns 1. However get_provided_to returns a list to the ports that are bound to it with the correct size. I believe that for an imp size should return m_provided_to.size().
  6. Is min_size or max_size ever checked after elaboration to check port/imp connections? I grepped through the 1.1d code and didn't see anything. The min_size and max_size are both set to 1 for an analysis_imp, however if you don't connect an analysis_port to an imp or if you connect more than 1 then there are no errors. This seems like a pretty critical oversight since it will allow imps to be unconnected regardless of the setting of min_size and max_size. Since this is a pretty easy error to make then it makes debug unnecessarily difficult. I did confirm that the uvm_analysis_imp::get_provided_to works as expected. I would expect this number to be checked after all connections are complete and compared to min_size and max_size and error to be reported if out not the correct value. Rlated to this, why are the constructors for the imp classes not overridden so as to allow different values for min_size and max_size. Right now they are hardcoded to 1 with now way to change them. I can conceive of cases where you might allow multiple analysis ports to write to an imp.
  • Create New...