Sampling and checking the counter continuously

UVM
,
1

I need to come up with a UVM testbench for a counter. It looked simple initially. But now, i am looking at the best way to sample the output.
Here is the RTL interface:

module up_down_counter (
  input clk,    // Clock
  input clk_en, // Clock Enable
  input rst_n,  // Asynchronous reset active low
  input [7:0] load_value,
  input load_counter,
  input up_dn_counter,
  output logic [7:0] current_value,
  output logic count_reached
);

To check the current value of the counter, i need to maintain a reference model for the counter. can we have this counter in scoreboard? how do we take care care of the counter update on every clock? Is monitor a best place to maintain the counter?
what is the best practice in above case?

I have been thinking on those lines. any leads would help. Thank you!

2

In reply to susdesai:

Hi,

Let me breakdown the use of the each UVM class for this counter example.

→ Add all the signal the interface.
→ Code all the configuration parameter
( like when to start the counter etc. which can be easily pass across the uvm component using config dB) in the configuration class which have uvm obejct type.
→ Drive all the input signals from driver (set the config parameter also when you start the counter. so scoreboard can also start at same time)
→ Monitor all the output signal in monitor class and send the transaction to the scoreboard at each clock.
→ Code the counter reference model in the scoreboard and compare the reference data with the received data from monitor.

Hope this will help you.
3

In reply to Rahul Patel:

Wow! Thanks for the stepwise guide. I did go through various material and cane up with a similar plan. I don’t have any registers though.
Now I am kind of stuck with handling reset on environment side. Will post that as a separate topic.

Thank you!

4

In reply to susdesai:

It looks like you want to implement a complete UVM testbench. You can do this from scratch or using a UVM FRamework generator like the one from Doulos. Please see here:
https://www.doulos.com/knowhow/sysverilog/uvm/easier/

5

In reply to chr_sue:

chr_sue, thanks for your reply.
Will go through the link.
Here are my questions, appreciate if you could clarify:

  1. Right now i am doing module level verification of an up-down counter. Is it required to have reset handling on environment side? Eventually I would move to TOP level verification. Is it recommended to do the reset(on the fly) handling at chip level? what is the usual industry practice?
  2. If I decide to not to handle on-the-fly reset for module level verification, I still need to have a initial reset, right? Is it recommended to have this reset generation in top file or in driver? Is it that, generating it at Driver may help to align the reset with reset phase? Any leads to see the flow/example?
  3. If reset generation in in top file, its usually done in initial block, right?
  4. In case of reset handling at chip level, what is the best practice. I do see many links online.
  5. I will go through the above link you have sent. Hopefully it clears some of my questions.
6

In reply to susdesai:

While looking for reset handling, came across below post. I did get most of it and it handles reset through UVM phases.

But I saw in this UVM forum that the preferred way to handle reset is using reset sequences. I have no idea about it and have been looking for some examples. Please point me to some reference. Thanks

7

In reply to susdesai:

Reset-Handling depends on the reset procedure and whether it is a requirement. This is valid for all levels of verification.
You should have alwyas a reset if your DUT has a reset.
Reset and clock generation are done in the initial block. clock generation can be doen also with an always.
I do not understand what you mean with 'reset handling on chip-level? Do you have a reset procedure or only a simple synchronous/asynchronous reset?

8

In reply to chr_sue:
“You should have alwyas a reset if your DUT has a reset.” answers my basic question.

'reset handling on chip-level? " by this i meant, on-the-fly reset generation/handling.
My point is, for module level verification, i can just activate the reset in initial block. This is true only if i want to apply the reset in the beginning.
My point is, for the module level testing, i can generate reset using initial block. (this doesn’t generate on-the-fly reset, right?)

When i move to chip level verification, can focus on on-the-fly reset generation/handling. Even the above module would also be covered for on-the-fly reset.
I believe there are many ways to generate/handle the on-the-fly reset : using reset sequences and using UVM phases. I did come across a post mentioning, using reset sequences is better approach, is that right?

Thanks chr_sue for your replies. I am able to make decisions and progress. I had done some online UVM courses and now started working on UVM verification. Hence these questions.