Search the Community
Showing results for tags 'virtual interface'.
Found 2 results
-
Hi, I have a doubt regarding an interface "X" being defined as : Driver code of the VIP: *********************************************** protected virtual X ChipIf; function void connect phase(uvm_phase phase); Y vif_container; super.connect_phase(phase); // Assigning virtual interface assert(uvm_config_object::get(this, "","V_IF_CHIP", temp)); $cast(vif_container, temp); ChipIf = vif_container.get_v_if(); endfunction : connect_phase ********************************************************** From the tb_top of the SoC , where the above VIP pkg is imported along with uvm pkg:*,please let me know how can I "set" the virtual ChipIf? -
Hi Everyone, I got some strange code (at least strange to me) from a college of mine and I can not understand why it works, reading the code I expect the tools to fail at compilation and elaboration but to my surprise it works fine. This is a description of what he trying to accomplish and how he did it: We have chip and within it we have a register bank that use an interface with modports to all the subblocks in the design. My college use an SPI to access the register bank but needed to "control" some of the signals going from the subblock to the regbank which are internal and already connected. To control these signals he probed down to the regbank and connected a virtual interface to the interface of the regbank (the virtual interface declaration use the same modport as the regbank) To control the signal he now simple write "virtual_itf.signal_name = 1'b0" to override the value from the subblock. To me this is strange for the following reasons: The interface signals are declared as "logic" and since we now have multiple drivers I would expect the tools to complain Different signal values are driven by the subblock and the virtual interface. I would expect the result to be 'X' but apparently the virtual interface has higher precedence than the subblock but I can not understand why Virtual interface is declared with the same modport as the regbank which means the UVM testbench drives an input signal which should also be flagged. By the way we use Cadence irun(64): 14.20-s002 I'm not an expert in SystemVerilog/UVM verification so I'm grateful for any help to understand it for the RTL coder within me is just skeptic about how this is hooked up and that it will work for any other vendor than Cadence Thanks Mikael