Is there any advantage to creating interfaces if I’m stuck verifying a DUT that uses legacy verilog code? I mean, I’m going to write a script to connect everything up anyway (since there’s no way I’m going to type out hundreds of connections by hand), so what advantage is there to going through an interface, instead of just driving things directly?
To verify using OVM/SystemVerilog the best way to drive it through virtual interface/modport (via clcoking block). In a reusable context this is the only recommended way as well. And yes indeed there are tons of advantages using SV/OVM for verifying your RTL (that could be in Verilog/V2K, SV, VHDL etc.).
If your dilemma is more about updating legacy RTL for mere interface connections, I don’t see a pressing need - sure it is better in many ways, but not a must.
HTH
Srini
www.cvcblr.com/blog
Srini,
My dilemma isn’t about updating legacy RTL for interface connections – modifying the RTL isn’t an option here.
That’s actually my problem. It’s unclear to me how I can even use interfaces in my circumstance. I need to test a collection of modules. Some of the modules contain direct references using full path names, so I have to instantiate the parts of the design I want to test with the full “real” hierarchy. Furthermore, on the design side, we use some proprietary tools that process that support verilog, but not SV, tools which expand macros that are necessary for the design.
If I could make a “normal” testbench, I could see how I could use a top level module that instantiates the modules I want to test via interfaces, but since my top level module has to be a straight-up verilog file, I don’t see how I can escape instantiating everything as legacy verilog modules, and having the testbench reach in and manipulate the input signals I need to directly.