What's the best class naming convention for re-usability in higher level testbenches (avoid multiple classes with same names)

UVM
,
1

Example first:

  • Assume a testbench for a DUT has an environment class called env.
  • Assume I have multiple testbenches for multiple DUTs, each having an env class name.
  • Now I create a ‘multi-device’ testbench that includes these DUTs together.
  • There will be three classes named ‘env’

Question: What is a preferred strategy to prevent ‘collisions’ or one env getting replaced by another?

I’ve brainstormed some possible answers:

  1. best to make the names unique in case you decide to make a multi-device testbench in the future. E.g., dut1_env, dut2_env…
  2. Package and compile them individually to preserve the scope of each env within the package (I’m really guessing here, so is this possible and what’s the high level concept of how this would be done?)
  3. keep everything with simple names (env) in each DUT testbench. Then compile them into separate libraries so they don’t collide. (would this really help? The compiled libraries are still all included when the simulator is invoked anyway and the tool may just use the first ‘env’ that it finds)
  4. I’ll need to write code using a ‘config’ constructs to specify which libraries are associated with each dut, etc…

Bottom line: If you knew you may have a multi-device testbench in the future, what method/strategy would you use to avoid these collision problems?

Thanks in advance for your insights,
Brian

2

In reply to jnbkeller:

Unfortunately UVM doesn’t it make this easy with the factory using string names that don’t include the package name. You are going to need to come up with names that are globally unique.

3

In reply to dave_59:

I hadn’t even considered the factory aspects; that’s a deal breaker. Unique names appear to be the only way.

Thanks Dave.
Brian

4

In reply to dave_59:

Hi Dave,
I’m a little confused about this (what I’d think is simple) re-use concept that is apparently very practical. It seems like a primary goal of UVM is to create re-usable test environments. From your response, it seems like because of the factory, I can’t really re-use anything.

If I had a top level testbench that brought in a lower-level test environment multiple times, It sounds like I’d have to re-code and rename everything. E.g., say I had a block level testbench and I wanted to create a super-block testbench that incorporated multiple blocks.

superblock testbench contains:
block1 → block2 → block1 (2nd instance)

This seems like a common thing to do. Are you saying I’d have to copy block1, rename the environment and other components in the testbench so that I’d have something like a block1a and block1b? (i.e., instead of env, I’d have to create block1a_env and block1b_env).

This seems like a lot of work. If I didn’t plan on over-riding anything, would that make a difference?

Thanks for some further insight.
Brian

5

In reply to jnbkeller:

I should have expanded on my comment about the factory with identical class names. It’s not that you can’t use it, it just that you can’t use it with string-based factory registration. String-based registration is necessary only when registering the top-level test name and identifying that test with a string name using the +UVM_TESTNAME switch (and there are workarounds for that).

Type-based factory registration and overriding is more efficient and likely to catch more mistakes during compilation instead of at run-time.

So you can name classes the same as long as they are in different packages and the packages have unique names. In any case, a 3-letter class name like env seems too short. Multiple instances of the same class name are not a problem for the factory.

6

In reply to dave_59:

Thanks Dave,

That makes more sense. I’m hoping you might know of an example I could look at that shows this testbench sharing environments from other testbenches, or the superblock made of blocks. I’m wanting a better understanding of the syntax in the top level environment that shows the lower level environment being created. e.g., package_name::lower_env etc…

My goal is to better understand the structure of the environments and how to best name and create them.

Any thoughts on where I might look?
Thanks again,
Brian

7

In reply to jnbkeller:

I believe what you are looking for might be called “Vertical re-use”

Some places to look are

https://www.verilab.com/files/verilab_dvcon_eu2015_2_reuse.pdf

8

In reply to dave_59:

Thanks Dave, I’ll take a look.