Porting UVM Env between different customer projects

Hi All,

What’s the best suitable way to port my UVM env between different customer projects?
I mean from customer project to another, there are some features which added to the design, I need to set the UVM env with a configurable way to support this features set this features or not.

Also some times the checker equations may vary from project to another, How can I set it using a configurable way.

In reply to m.assal:

I think there is not a correct answer to what you are asking for.

What I would do is the following, set up the hierarchy with a top environment that can contain another environment inside, whenever you have to change project you are going to have a subclass of this top environment connecting things for project A, and another subclass for the project B.

Of course, there can be parts that are depending on the configuration and you have to take care of this.

If you give more details of what you have maybe we can help.

In reply to Marc43:

Hi Marc, Many thanks for your answer.

For example:
1-changing the equation parameters inside the monitors.
2-changing the constraint limits inside the sequence_item.
3-changing arrays elements which used in the driver.
4-changing some configuration values which I set them from the testcases using set_config_db, from outside world.

Thanks,
Assal

In reply to m.assal:

You can do anything you want to do. The UVM is really powerful. But you should consider
(1) you do onot know all your requirements from the very beginning, resulting in chnages after it has been developped.
(2) it might become too complicated for your customer to employ this testebnch.

In reply to m.assal:

Software architecture has the important principle of Separation of Concerns. This applies to testbench development as well. It’s why the UVM has many different components for drivers/monitors/scoreboards. And TLM communication helps separate dependancies.

Within each component, you can further adopt separation of concerns by encapsulating your code into virtual methods that can be extended and overridden by the UVM factory. Another methodology is adopting the strategy/policy pattern.