Does the UVM testbench always need uvm_sequence

Hi
I designing a UVM testbench. In this model, I am having a config object and UVM_components communicating using TLM FIFO. The components generates the input packets according to the config and drives the DUT.

I am keen to understand if there are other ways to design UVM testbench not following the standard producers based on requirements. Something like design patterns in software.

Thank you
Regards
Sudarshan Vempati

In reply to Sudarshan:

uvm_sequence is actually an implementation functor design pattern in SystemVerilog.

But the point of design patterns and other standard practices is promoting re-use and maintainability.

In reply to Sudarshan:

Hi
I designing a UVM testbench. In this model, I am having a config object and UVM_components communicating using TLM FIFO. The components generates the input packets according to the config and drives the DUT.

What are you saying is omly half the truth. The testbench is used to genearte patterns for verification. How these patterns have to be generated is defined by the sequences (extension of uvm_sequence.
uvm_sequence is not part of the testbench itself.

Hi Dave / Sue

Thank you for the responses. Well, the patterns for verification are generated by a model. So this model can be seen as a sequence (extension of uvm_sequence). It may be defined explicitly or implicit (if this model is defined as a component which is continuously generating patterns and pushing to TLM Fifo).

Is this way of looking at a sequence correct?

In reply to Sudarshan:

I would not say this. The question is what your model is and how it is integrated in the UVM environment.
Using sequences is a very flexible, simple and reusable way to generate simulation pattern on the fly. You don’t have to generate the pattern first and connect them afterwards to yout verification environment.

In reply to Sudarshan:

The way you are generating stimulus from a component versus a sequence achieves the same functionality. Using a sequence involves slightly more setup, but has the advantage of being much more flexible and the more common approach. Only you can make the decision form the perspective of your environment which method is better overall. Just make it clear (i.e. document) why you chose this method, because anyone who picks up your code will want to know why you deviated from the common practice.