Dynamic DUT instantiation

UVM
,
1

Hi,

Firstly, I am quite new at both UVM and verification in general but I’ve been putting a lot of effort into it and the resources I’ve found here have been extremely useful so thank you for your efforts.

I am currently verifying a chip that works in one of 3 modes - as a master, a slave or an “individual”. This is decided via a ChipId, which is to be hardwired. In short, the chip is part of a sensing system so we have a control mechanism and a readout mechanism.

The system I’m verifying is essentially working in one of two scenarios:

  1. Up to 6 slaves share a line to communicate with a single master (via a token exchange mechanism), which in exchange passes its own and the slaves’ data to the outside world using a specified high speed link.
  2. Up to 9 “individuals” share a control line but each has an instance of the aforementioned high speed link to get data out.

What I would like to do is have a DUT module that gets information from the test configuration and decides how many chips of each type to instantiate.
Here are a couple of examples:

  1. Run a test with a single master and 6 slaves or a master and 4 slaves (say 2 have experienced a glitch and stopped working, which is likely). Ideally, I’d be randomising the number of faulty slaves and their position along the string of slaves.
  2. Run a test with a variable number of “individual” chips.
    Example 1) above is really critical for me, as we have observed bugs as a result of a single slave breaking down (to do with the token exchange mechanism). Anyway this needs to be verified.

Naturally, I can just cover the basic cases and create a number of DUT instances and TOP modules to correspond. However, this is not really in line with basic principles taught here, hard to maintain and makes regression testing difficult. I can’t really get a configuration object from the DB before instantiating the DUT in the TOP level.
Another option I see is instantiating enough devices to be able to cover every scenario and selectively wiring some of them to GND. However, I don’t think this is ideal as it clutters and slows down the environment.

I hope I’ve managed to properly explain my issue. Please, feel free to contribute any ideas since I am not at all happy with the options I’ve come up with.

Regards,

Svet

2

You can’t dynamically instantiate a module. If you instantiate all devices and selectively tie their inputs to GND you will not pay any run-time penalty, just some elaboration setup time.

What I have recommended in the past is to have a two-step flow where you use the randomization features to write a SystemVerilog package that is used in the second step to configure the DUT for running the test.

Dave

3

In reply to dave_59:

Thanks for your reply!

I shall proceed with that option then - I was just hoping there might be a trick I’m missing to make the whole thing a little more elegant.

Svet

4

Hi Dave,

If possible could you please point me to your past recommended post?
I would like to understand what is the ideal way to tieoff the DUT signals during the run time.

Should I look for command line args in the tb_top and tie off the redundant DUT signals or is there any better approach to achieve this run time DUT configuration?

Thanks,
Somasekhar M

In reply to dave_59:

You can’t dynamically instantiate a module. If you instantiate all devices and selectively tie their inputs to GND you will not pay any run-time penalty, just some elaboration setup time.
What I have recommended in the past is to have a two-step flow where you use the randomization features to write a SystemVerilog package that is used in the second step to configure the DUT for running the test.
Dave

5

In reply to M Somasekhar:
https://verificationacademy.com/forums/ovm/randomizing-module-parameters

module1 inst1(..., .input_portN(input_to_module1), ...);
module2 inst2(..., .output_portM(output_from_module2), ...);


assign input_to_module1 = mode ? output_from_module2 : constant_to_tieoff;