Merits of Overriding Sequence Items

UVM
,
1

I am going to strongly disagree with the statement “Therefore, from a practical point of view, sequence_items are unlikely to be overridden” (Cookbook Section UVM/Sequences/Overrides).

I am going to provide two examples of how type overrides with sequence items has been very useful for me.

While I do want to test the entire state-space of possible stimulus, I often want to narrow my stimulus for certain tests. By heavily constraining my stimulus I am actually able to hit certain scenarios. An example could only running maximum or minimum size packets for an extended duration. If I need to run a large number of these packets in a row to create a scenario, then this is unlikely to happen without additional constraints. I could do this by writing a new sequence that constructs these derived sequence items that have additional constraints, but that seems like it would be slightly more code and more files than extending a sequence_item and using a type_id_override().

My other example is that I often find bugs and sometimes I am not responsible for fixing them. However, I still want to find other bugs while that bug is being fixed. Therefore I create a test that exhibits the bug and document it. However, I then introduce new constraints in a derived class to mask the bug and have all my other tests use type overrides to enforce these constraints. This allows me to temporarily mask known issues while I hunt for more bugs or work on adding more coverage.

2

In reply to James.Kolar:

I agree with your disagreement. They were probably only thinking about overrides that added new class member variables or methods. Overriding class constraints is a very common factory override for any class with random variables.

3

Hey Dave,
I also agree with your point but I didn’t understand you line,
“They were probably only thinking about overrides that added new class member variables or methods.”
Can you elaborate more about it.
Thanks

4

That section of the cookbook explains how the sequence-to-driver communication is specifically designed for a particular sequence_item. It wouldn’t make sense to add a new variable to a sequence_item unless the driver is also extended to read that variable. However, there are numerous cases where extending a sequence item is beneficial. Many people create base sequence items and extend them for use with a driver, while also extending them differently for use with a monitor by adding responses. Of course, the cases raised by the original poster, which involve extending the sequence item to add constraints, are a common practice. Therefore, the cookbook statement is clearly misleading.