Jump to content

jeff.schroeder

Members
  • Content Count

    14
  • Joined

  • Last visited

About jeff.schroeder

  • Rank
    Junior Member
  1. In uvm_create_random_seed() (in uvm_misc.svh) is the following code that returns different seed values for a given {type_id, inst_id}: seed_map.seed_table[type_id] = seed_map.seed_table[type_id]+seed_map.count[type_id]; seed_map.count[type_id]++; return seed_map.seed_table[type_id]; The problem is that this can return a seed of 0, which is not a valid seed value to srandom(). Am I missing something, or is this really a bug? Thanks, Jeff Schroeder
  2. I don't think the problem is with the sampling time. In bus2reg(), it looks like you're clobbering the data in your AHB transaction with these statements: tr.m_nNumBytes = 4; tr.m_bvvData = new[4]; You set the data in your AHB transaction to 0, then copy it to the uvm_reg_bus_op.
  3. uvm_reg::read() and uvm_reg::mirror() can compare the value read from the register with the expected value. Apparently this is used with implicit prediction. However, they both use uvm_reg_field::get() for the expected value, which gets m_desired, not m_mirrored. I would expect the comparison to be made against m_mirrored. uvm_reg_predictor uses uvm_reg_field::get_mirrored_value() for the expected value when it does a comparison after read. Is there a reason for the difference?
  4. jeff.schroeder

    default phase sequence

    It looks like an informational message at UVM_HIGH verbosity, most likely to help with debugging. I don't think it's meant to imply that something is wrong.
  5. In OVM, ovm_report_warning(), ovm_report_error(), and ovm_report_fatal() ignore the verbosity level and always report. The UVM class reference states that this is also the case in UVM (see page 51 in the UVM 1.1 Class Reference). However, in looking through the reference library code, I see that this isn't the case. It is possible to suppress warnings, errors, or fatals through verbosity level settings. Is this a deliberate change from OVM? If so, what's the reasoning here? It just doesn't seem reasonable to suppress error checking based on verbosity. I would expect a test to behave identically at different verbosity levels.
  6. I did pretty much what you did. Essentially, you need a factory that creates a specific subtype based on the data that you collect. The way I did it, the base class is the factory: As you unpack into it, it creates the subtype when it has enough information to determine the type. (I build the decoding into the transaction class, so the monitor just puts raw data into the transaction object, and the transaction populates itself from the data.)
  7. Use sprint() instead of print(), which will return a string with the formatted printout, and then use uvm_report_info() to print that string. Actually, you should use the `uvm_info macro, and embed the sprint() call within the macro arguments. The macro will avoid the overhead of evaluating the message expression (your sprint() call) if the message isn't going to print because of the verbosity level. I've never used print(), for precisely the reason that you can't control the verbosity of what gets printed.
  8. I've run into this before myself, so I'll take a stab at it. I believe what you're looking for is polymorphic behavior from the virtual interface: There is some set of behaviors that all parametrized versions of bus_if share, and you want your driver, monitor, etc. classes to be able to use these common behaviors without caring about BUS_WIDTH. That way you don't have to parametrize your classes. Of course, interfaces are not classes and cannot use inheritance and polymorphism. What you can do, though, is to make a wrapper class for your interface and manually abstract the behaviors you want into the wrapper. Here is an example: `define MAX_ADDR_SIZE 64 interface bus_if #( BUS_WIDTH= `MAX_ADDR_SIZE ) ( input logic clock ); logic [BUS_WIDTH-1:0] addr; endinterface // bus_if virtual class bus_if_wrapper; pure virtual function int get_width(); pure virtual function logic [`MAX_ADDR_SIZE-1:0] get_addr(); endclass class bus_if_param_wrapper #(BUS_WIDTH=`MAX_ADDR_SIZE) extends bus_if_wrapper; virtual bus_if #(BUS_WIDTH) intf; function new(virtual bus_if #(BUS_WIDTH) intf_); super.new(); intf = intf_; endfunction virtual function int get_width(); return BUS_WIDTH; endfunction virtual function logic [`MAX_ADDR_SIZE-1:0] get_addr(); return {{`MAX_ADDR_SIZE-BUS_WIDTH{1'b0}}, intf.addr}; endfunction endclass module top; wire clk; bus_if #(32) if32 (clk); bus_if #(64) if64 (clk); bus_if_param_wrapper #(32) wrapper32 = new(if32); bus_if_param_wrapper #(64) wrapper64 = new(if64); initial begin bus_if_wrapper wrappers [] = '{wrapper32, wrapper64}; foreach (wrappers[i]) begin $display("width=%d, addr = %x\n", wrappers[i].get_width(), wrappers[i].get_addr()); end end endmodule Here the behaviors I abstracted are the ability to get the bus width and to get the address from the interface, zero-padded to the maximum address width in our system. Of course, if the behaviors that you want to access from your classes do depend on BUS_WIDTH, then you have no choice but to parametrize those classes.
  9. jeff.schroeder

    uvm_reg_bit_bash_seq usage..

    1. uvm_reg_bit_bash_seq walks through each bit of the register. It inverts the bit, writes the register, reads and compares, then inverts it again, writes the register, and reads and compares. So, yes, the first time the register is written, the first bit will be inverted relative to the reset value. When the sequence is all done, the register should be left in its original state. 2. uvm_reg_bit_bash_seq uses front door access, so as long as you have the register model connected to your DUT through an interface that consumes simulation time, you should be able to observe the registers changing values. The register model values will be buried in your test bench class hierarchy. It might be easier and more meaningful to observe the registers changing in your DUT.
  10. jeff.schroeder

    uvm_reg_bit_bash_seq usage..

    It looks like rg should be set to point to the register on which you want to run the uvm_reg_single_bit_bash_seq. Look at how uvm_reg_bit_bash_seq sets it on line 269 of uvm_reg_bit_bash_seq.sv (UVM 1.1). Is this really what you want to do? The intended usage seems to be to run uvm_reg_bit_bash_seq on a whole register block, and let it run uvm_reg_single_bit_bash_seq on each register.
  11. jeff.schroeder

    uvm_reg_bit_bash_seq usage..

    It looks like rg should be set to point to the register on which you want to run the uvm_reg_single_bit_bash_seq. Look at how uvm_reg_bit_bash_seq sets it on line 269 of uvm_reg_bit_bash_seq.sv (UVM 1.1). Is this really what you want to do? The intended usage seems to be to run uvm_reg_bit_bash_seq on a whole register block, and let it run uvm_reg_single_bit_bash_seq on each register.
  12. So, why does the uvm_reg_access_seq skip registers that have RO fields? I would think that accessing via back door using read() and write() would properly predict and set values according the access policies of each field. Indeed, when I comment out the code that skips the RO registers, the sequence is able to operate on registers with RO fields without errors.
  13. jeff.schroeder

    looking for a replacement for vera_crc()

    I realize this thread is a bit old, but in case you're still interested, I would recommend reading the paper at http://www.ross.net/crc/crcpaper.html. It's a very good layman's explanation of how table-driven CRC algorithms are derived. Using that, I was able to create a small SV package that implements a parameterized class that calculates CRCs for any polynomial that you desire. It's a worthwhile exercise both in understanding CRCs and in creating an efficient SV class implementation, and it's a fairly small undertaking. The real challenge is figuring out what parameters to use for any given standard. (The polynomial is just one of several.) The paper gives you the parameters for Ethernet, so you're set there.
  14. jeff.schroeder

    I need help with compilation failure

    Did you, by chance, use the `uvm_component_utils macro on a class that is not derived from uvm_component?
×