Get email delivery of the Cadence blog featured here
Seems that by now, every one in the industry realizes that multi-language verification environments are not a faraway vision, something only for eccentric verification experts. Multi-language is here, simply because we need it.
Because there is no sense in throwing away a high-quality verification environment just because someone else prefers coding in a different language. Because there is no sense in forcing engineers to work in a language that does not fit best their needs and knowledge. Because you keep integrating your environment with verification packages developed elsewhere—do you really want to develop everything from scratch?
In this blog, I’ll try to convince you that creating a verification environment by combining components implemented in different languages is much simpler than you might think.
Let’s start with a simple use model. For the sake of example, assume your next project requires UVCs implementing two protocols: XSerial and UBus. Your company has such UVCs, but the XSerial UVC is implemented in e, and the UBus UVC is implemented in SystemVerilog.
I recommend creating the environment in steps, especially when it is your first multi-language environment.
The first step would be to create a verification environment in which the SystemVerilog UVC and the e UVC run side by side, each exercising one i/f of the DUT, without any interaction between the two UVCs. In this first step, we just confirm that the UVCs can coexist. The environment we build is of architecture similar to this:
For creating such a verification environment there is no need to modify your code, or to use any special tools or libraries. Just compile the UVCs and the DUT RTL together.
irun sv/ubus_top.sv e/test_1.e dut_top_file.v <options>
The <options> are the regular irun options we use when running e or SystemVerilog environments: uvmhome flag (required for using UVM SystemVerilog), timescale, incdir, etc.
Now we have a simulation in which the two UVCs run side by side, as you can see in the screen shot below. The SystemVerilog components are instantiated in the normal UVM way, under uvm_test_top, and the e components are instantiated under sys. In this environment, each UVC is sending data to and from its designated interface, without any synchroniation between the UVCs—no synchronization of configuration, traffic control, or system-level checks.
This is the first step of creating a multi-language environment, quite quick to implement, which gives a preliminary confirmation that these two UVCs can coexist. Now we can start enhancing the verification environment, adding interactions between the UVCs. Some examples of such interactions:
A basic synchronization of e and systemVerilog can be implemented by connecting e ports to registers in SystemVerilog modules, and you can even call SystemVerilog tasks from e code. For connecting UVCs implemented in e to UVCs implemented in UVM SystemVerilog—in classes—we will start using UVM-ML.
The next blog, Multi-Language Verification Environment—Passing Items on TLM Ports, Using UVM ML, will shows how we add usage of UVM-ML to the verification environment, and will demonstrate implementation of a system-level scoreboard, getting items from monitors implemented in different languages.