UVMREG write/read control of the reset signal (reset is stays unknown-X)

Hi, All –

I am writing a simple UVMREG test for a 4-register x 16-bit general purpose registers. The registers include an asynchronous low-true reset.

I have the non-UVMREG test working fine, but when I try to use UVMREG writes and reads, the reset line in my simulation goes unknown and I am not sure how to control it (both to do an asynchronous reset and to not do reset).

The reg2bus method has controls for rw-control, addr, and data, but no control for the reset pin. Do I have to control the reset pin from the driver? (make sure the reset pin is always high in the drive_item task?)

Looking for best methods to control register resets during UVMREG-write/read operations.

BTW, I can see all of the other addr, data r_wn signals wiggling in the waveform display, and the non-UVMREG version of the test runs fine. It is just the reset signal that is always X, so it is a rather uninteresting simulation!

Regards – Cliff Cummings

In reply to cliffc:

Looking for best methods to control register resets during UVMREG-write/read operations.

You normally control reset separately. It would help if you could describe the sequence of events you’d like to generate here.

Thanks, Warnerrs - this gave me a clue.

I added my typical reset bus transaction but that did not get rid of the reset-X during register operations.

What I did try (and it worked) was to modify the reg2bus() method in the adapter. It had always bothered me that this method controlled the r_wn, addr, and data signals but nothing else. Since reset is part of my transaction, I added tr.rst_n = '1; (reset-off) to the method and then the register transactions worked as expected.

  virtual function uvm_sequence_item reg2bus (const ref uvm_reg_bus_op rw);
    trans1 tr = trans1::type_id::create("tr");
    //--------------------------------------------
    // Set the transaction r_wn bit / addr / data
    tr.r_wn  = (rw.kind==UVM_WRITE) ? '0 : '1;  // Write(0) / Read(1)
    tr.addr  = rw.addr;
    tr.din   = rw.data;
    tr.rst_n = '1;  // ADDED THIS - RESET-OFF

    return(tr);
  endfunction

The follow-on question, is this a proper technique? I suppose I could have added a soft constraint to the transaction code to keep reset off(??)

Is there a better way to handle the proper driving of reset, or is this what you (warnerrs) were talking about? Perhaps I am the only person who has had this problem(?)

Regards - Cliff

In reply to cliffc:

Given how rst_n is modeled in your transaction class, driving it that way is the right thing to do.

Your transaction raises a question for me. Register bus resets typically are not modeled in the transaction, as applying reset is really a logically separate operation. I generally have a separate driver for the reset, and the reset is then an input to the bus VIP just like the clock. In the case of an interface that supports burst transactions, using a separate driver allows you to apply reset in the middle of a burst ( from another thread ), which isn’t possible with how reset is modeled in your example.

-Ryan