SystemVerilog DPI (Direct Programming Interface) is the equivalent to Verilog's PLI & VPI. All three are used to add system task (e.g. $display, $random, etc) to SV/V.
Not quite equivalent enough for me.
The PLI/VPI is a C interface to the simulator that is still relevant for SystemVerilog. It lets tool developers add functionality to the simulator like waveform dumping, analysis using design introspection. And yes, it does allow you to add functionality in C that would be more difficult to write in Verilog/SystemVerilog.
The SystemVerilog DPI is strictly a modeling interface, and it is bi-directional. SV can call C, and C can call SV without either side knowing that they are being called from a different language. That make is very easy for a model writer to integrate C and SystemVerilog without having to know simulator API specifics. You simply pass arguments on the call stack like would with any C program instead of having to use query based routines for access in the VPI. Using the DPI does require that you know which argument types are compatible; an
int is an
int in both languages, but a
bit has no corresponding type in C, but there are helper routines in C to access bit-level structures on SV.
Another key feature of the DPI is, as I mentioned, C can call SV. That includes C calling time consuming tasks. That is very useful for using C to generate stimulus, or having C models that interact with bus functional RTL models.
As for the benefits of writing in C versus using SystemVerilog, that depends on what you already have or readily available. You may already have reference models written in C by architects who need these models in a C only environment. Re-use of these C models in your RTL verification environment would be a benefit. An there is no longer a distinction between Verilog and SystemVerilog as far as most simulators are concerned. Verilog is just a syntactical subset of SystemVerilog.