bottom-up or top-down reset

[shail]

I am working on adding reset to my UVC and that makes me think of two approaches

1. bottom up (meaning reset signal picked up from signals-via interface)

2. top down (meaning reset signal driven via sequence)

and I want to use both - because I want my UVC to reset when reset pin wiggles or when reset sequence runs.

uvm ref flow shows pin-wiggle reset implementation but it only reset dut signals in this case. What about stopping sequences, resetting agents, monitors , layered sequencers, models etc...???

There is nothing in uvm user guide about this.

For bottom-up, I was thinking of using get_parent() method to propogate reset in hierarchy.

For top-down, I was thinking of using get_children() method to propogate reset in hierarchy.

How have you implemented reset scheme in your UVC ?

In parellel- I am reading VIP guide on uvmworld site to see if it gives any insight.

[Erling]

For bottom-up, I was thinking of using get_parent() method to propogate reset in hierarchy.

For top-down, I was thinking of using get_children() method to propogate reset in hierarchy.

How have you implemented reset scheme in your UVC ?

Why do you need top-down reset propagation? For bottom-up, I find it useful to have the UVC monitor broadcast the reset via an analysis port when the reset pin wiggle is detected, and also have a callback in the driver to detect reset before it is asserted, for example to prevent the reset from happening for some valid reason.

Erling

[shail]

Why do you need top-down reset propagation?

I was thinking about top-down reset propogation because I was thinking of propogating reset through a sequence,which makes it top-down, but what I did not think at the time was that, top-down propogation of reset sequence would be through some control-interface (pin-wiggler interface) where as your active UVC would only be using bottom-up ..Agreed.

Next question though is, when you take bottom-up approach, how do you pass reset up to components agents, sequencers (layers) who do not have access to interface?

I could think of two ways:

1. jump to reset_phase in driver/monitor when it detects reset (driver & monitor or just monitor?) and then all components will get in their reset_phase and hence execute reset ?

2. use get_parent() and call parent's reset() method, recursively all the way upto env or agent, which can then call its childrens? -- This sounds complex and question arises- why do it, but this is needed because driver may call agent's reset() as its parent, but to get sequencers (layered) to have reset(), we need agent to call reset() to all its children.

thoughts ?

[Erling]

Next question though is, when you take bottom-up approach, how do you pass reset up to components agents, sequencers (layers) who do not have access to interface?

Not sure I understand what you mean. Components without pin access should not suddenly need pin access just because a reset was detected? A scoreboard, for example, can just be notified about a reset, it does not have to be soldered to the reset pin. I'd be careful about drivers calling its agent reset() directy (or vice versa). This may create dependencies difficult to maintain. Note sure about the phase jumping. It seems best to wait with this until advice exists about how to use safely.

Erling

[shail]

Not sure I understand what you mean. Components without pin access should not suddenly need pin access just because a reset was detected?

By "passing reset", I did not mean "give pin access", I meant, driver/monitor calling reset() methods of agents or having monitor jump phase to reset_phase .. something like

mymonitor extends uvm_monitor;

...
  @(posedge vif.reset);
   parent.reset();

and then agent can have

myagent extends uvm_agent;

task reset();
  uvm_component children[];
  children = get_children(this);
  foreach (children[child]) begin
     children.reset();
  end
endtask
endclass;

problem is how far up do you go ? stop at env or stop at agent.. one thing is for sure- we need a way to pass information that reset happened to components that are not connected to reset pin (like sequencers, scoreboard) etc...

Also, my main question still persists - how is it being done in UVC out-there now ?

[Erling]

we need a way to pass information that reset happened to components that are not connected to reset pin (like sequencers, scoreboard) etc...

If your monitor already detects and report reads and writes from/to your dut, then one thing to try is simply to add a non-rand reset bit to the read/write transaction and report the reset through the regular analysis port for r/w transactions, for example:

class MyMon extends ...

  uvm_analysis_port #(DutRW) m_rw;

  function new(...);
    m_rw = new(...);
  endfunction

  task ResetMon();
    forever @(posedge reset) begin
      DutRW rw = new();
      Reset(); // local monitor reset
      rw.reset = 1;
      m_rw.write(rw);
    end
  end
  
  function void Reset();
    // whatever
  endfunction

endclass

With this arrangment, any component interrested in dut reset can subscribe to the m_rw port of the monitor, for example:

class MyComp extends ...

  uvm_analysis_imp #(DutRW, MyComp) m_rw;
  
  function new(...);
    m_rw = new(...);
  endfunction

  function void write(DutRW rw);
    if (rw.reset) Reset();
  endfunction

  function void Reset();
    // whatever
  endfunction

endclass

This may look like overkill for reporting a single bit, but is actually efficient behind the scenes, and reset does not happen that often anyway. The same reset bit could also be used to have the driver (if there is one) assert the reset.

Erling

[shail]

Perfect. I would take it one step further and create a standalone ResetObserver (InterfaceCtrl ) component or may be even UVC that can drive reset as sequence and also observe reset as monitor.

Resetobserver monitor can be simple component that observes reset and writes to its port, when reset is asserted and released.

It can then be extended if other such events of the bus needs to be observed and broadcasted.

Thanks.