Bridging the gap between latest methodologies and older HDLs

ABSTRACT:

Generic method for using a dynamic class based environment inside a static top level environment using wrappers.

With the advent of Hardware Verification Languages (HVLs) like SystemVerilog (SV), the memory footprint Verification IPs (VIPs) is generally smaller than older VIPs, which were based on Verilog or VHDL. This is primarily because, SV based VIPs may have objects created dynamically (i.e. in between the simulation) and also objects get freed when not needed thus freeing up memory. Whereas in case of older VIPs based on Verilog or VHDL, the instances or variables never free the memory as they are static in nature and they consume memory from the start of simulation till the end.

Any System on Chip (SoC), today will typically have over a hundred IPs instantiated. Hence it requires many “Verification IPs” (VIPs) to be instantiated in the testbench, for verification. Since SoCs are already large in size and complexity, having lighter weight VIPs results in lesser memory and faster simulation, this eases the task of SoC verification. However, a lot of companies still have legacy test environments created. In such a case, migrating from an existing SoC test environment to a fully HVL based test environment is time consuming and the project schedules do not permit such additional time. So generally people tend to sacrifice the advantages of SV based VIPs and to stick to the older/ legacy VIPs, that have static memory and are bulky.

In this article, our team has proposed a methodology in which we have kept both the aspects in mind. We are proposing a methodology that helps to create a Verilog type user interface for a HVL or SV based Verification IP. Such a VIP can be instantiated in the legacy and static test environment of the SoC and the VIP still provides the advantages of lower memory footprint.

OUR GOAL:

• For Legacy Verilog based SoC / DUT Environments:
  • Use SV Dynamism
  • Design light weight VIPs
  • Overcome disadvantages
• Provide environment:
  • Existing user interface
  • A dynamic behavior internally
  • Rigorous DUT testing

THE RISK:

The risks are many:

• If we compromise for lesser changes in the legacy environment, then we might not be able to      use the advantages of SystemVerilog’s randomization, assertions, functional coverage etc., which makes testing to be to less regressive and the SoC verification is at risk .
• If we think of making the changes in the existing environment and migrate to HVL based test environment, then the time to stabilize the SoC test environment would get added, potentially delaying the project schedule and manual labor would also be costly.

THE SOLUTION:

The only solution for such an issue is merging both the problems, and coming out with a unique answer that gives a familiar interface with dynamic capabilities!

In general every company follows some methodologies for creating their VIP environments 

Some of the standard methodologies are:

• UVM
• OVM
• VMM
• AVM

One such solution is to wrap the SV or UVM based VIP in a Verilog wrapper, thug giving it the look and feel as required by the legacy SoC test environment and allowing the dynamic features of HVL to function internally. Let us talk in detail about the UVM to Verilog environment converter (Wrapper):

STEPS TO DESIGN UVM TO VERILOG ENVIRONMENT CONVERTER (WRAPPER):

There were many challenges at first when this task was taken up. Following a general Idea that a familiar interface should be our first priority we targeted the boundaries of the VIP .

• Our requirement was to make our UVM VIP communicate with the Verilog DUT in a Verilog environment.
• For this, we made a Verilog testbench module to be used as the top and we instantiated a Verilog DUT module in it.
• Now, we had to somehow instantiate the UVM VIP in the Verilog top testbench and connect it with the Verilog DUT.
• A wrapper was made over the VIP testbench module with the ports implemented in it to communicate with the outer Verilog environment.
• .Now, we were able to instantiate this VIP wrapper module (which is containing the complete UVM VIP environment in it) in the Verilog top testbench and it was connected with the Verilog DUT.
• Next challenge was to drive the user-defined data packet on bus instead of the randomized packet get from UVM sequence by UVM Master. This option was to be implemented for an user who wants to use his Verilog tests with the desired stimulus.
• We made a Verilog test to write user-defined data and configurations and all this data was overwritten on the data packet made by UVM sequence so that this user-defined data can be driven by the UVM Master verification component when VIP is connected to RX DUT.
• In this way, UVM Master that was able to drive only those packets that are received from UVM sequence, now was able to drive the user-defined packet on bus.
• Another option was also implemented by which user can use stimulus generated by UVM sequences present in UVM VIP with his Verilog tests.
• In this way, UVM VIP can be used by a user who wants to test a Verilog DUT in his Verilog environment using Verilog tests either with user-defined stimulus or stimulus generated by UVM sequences.

CONCLUSION:

In this way, we can get the advantages of HVL based Verification IPs even in static test environments. The important points to be taken care are interface for instantiation, phasing of HVL VIP and the static environment, and the testcase finish logic to be synchronized between the HVL and static environments.