I am struggling with the following architectural problem for a UVM environment. I have several UVM agents that I want to connect to a system level DUT (an SoC with several GPIOs). I am looking for a design pattern that allows me to dynamically alter the connectivity between the pre-existing UVM Agent drivers and the DUT. I.e. I want to be able to dynamically control to which of the DUT’s GPIOs the UVM driver’s vif signals are connected to with support for bidirectional signals (I’m looking for something like a behavioral IO multiplexer in the form of a UVM component to alter which agent is connnected to which DUT ports). The only, quite laborious solution I can think of without completely rewriting the driver of each of the agents (unfortunatelly they are using virtual interfaces instead of abstract class methods to toggle the signals) is to write a Monitor that translates the drivers signal toggles back to individual sequence items and sending them to a “second stage” UVM agent that drives the actual DUT. Does anyone know of any more elegant solution?
Thanks very much in advance for any suggestions,
meggiman
It would be hard to give advice without know thin existing infrastructure you are trying to work around. Like I don’t know why you couldn’t dynamically change the virtual interface handles, or use an array of handles that were selected by a dynamic index.
Thanks a lot for addressing my question. Maybe to give a bit more context: The existing infrastructure consists of several IO peripheral verification agents (I2C, SPI, UART etc.). Each agent’s driver uses virtual interface handles (each one with its own SV interface) to interact with the RTL. The DUT contains a full-crossbar like IO multiplexer that allows to route any IO signal (e.g. I2C’s clock signal) to any IO Pad, thus my goal to have dynamic control of the external connectivity to verify the peripheral/IO multiplexing interplay in the fully integrated system.
Your idea to change the interface handle would certainly work for a smaller number of connectivity “configurations”. But, please correct me if I miss something really obvious, I was under the impression, that to use your approach I would have to instantiate and connect an interface instance for every possible way the peripherals could be connected to the IO pads upfront. I was under the impression, that SystemVerilog interfaces, like modules are static objects that cannot be instantiated dynamically like class objects. Unless there is some way to create and connect an SV interface to the DUT dynamically I’m not sure this approach would work in my situation. The array of interface handles that covers all possible connectivity configurations (>10^15) would be to enormous.
Again, I apologize if the question (and the follow-up) is a result of some fundamental lack in understanding SV but I would really appreciate your insights in how to approach this specific scenario.