What is Verification IP [VIP] in VLSI ?

In this article, we delve into key aspects of verification, beginning with an overview of general verification strategies that are essential for ensuring reliable design and functionality. We explore the need for robust verification processes, emphasizing their role in enhancing design accuracy and reliability, especially in complex systems. A detailed verification flow chart is presented to guide viewers through the structured sequence typically followed in verification. We also explain the concept of Verification IP (VIP), outlining the general verification blocks included within VIP and comparing these with those in a regular testbench. Additionally, we discuss the unique advantages of using VIP, particularly its ability to streamline verification and enhance testing efficiency, and conclude with an open example that demonstrates VIP in action.

Once you complete the article you will understand:  

1. What is verification IP in VLSI? 

2. Why a robust verification plan is necessary in VLSI with respect to the VIP context? 

3. How general verification test bench is weaker than a verification IP for the same protocol? 

4. Understanding verification IP using a open example

General Strategies of Verification:

Understand the architecture and micro-architecture; partition logic to create efficient RTL descriptions using moderate gate count blocks. Apply a bottom-up approach, and deploy synchronizers at the top-level design if needed. Use synthesizable constructs during RTL design and non-synthesizable constructs for RTL verification. Use blocking assignments for modeling combinational logic and non-blocking assignments for sequential designs. Avoid mixing blocking and non-blocking assignments. Apply optimization constraints at the RTL level to improve performance. Refer to subsequent chapters for better design and optimization understanding. Develop a robust verification architecture and verification planning for the design. Understand coverage requirements and implement verification strategies to meet coverage goals.

The above one is a picture of a desktop computer motherboard. There are so many types of connections are present which includes  connection for the hard drives, SATA ports, allocation for RAM,  the processor and on top of it, there will be a fan, PS 2 ports, USB port,  RG 45 socket, multiple D shaped ports, audio ports. 

It has to interact with the keyboard and mouse. It has to interact with other plug and play devices like printer, scanner. It has to interact with the monitor. It has to interact with the audio devices whether it is a microphone or a speaker. And here, it will interact with the 1 or more hard drives that are connected. In real time, when you turn up a desktop PC, right, for this CPU, we currently have a rush of information around it. However, when you had it on pen and paper, right, here you have listed things. But in real time, everything will be jumping from here to there, from there to some where else. So all these in and out operation will be simultaneously getting performed. And obviously, the hard OS will be booted from the hard disk. Now you can imagine a enormous data flux is coming from all around all on a sudden, and they are coming simultaneously. It's not that in sequentially, they are coming when you have turned on. The boot sequence has been performed, the OS is loaded and, your OS interface has been ready whether it is a Linux or it is a Windows or it is a Mac. So the user interface is ready. Now multiple things are already started to operate. Simultaneously, multiple operations are ongoing. So this is a real time scenario. That means our CPU has to take a load from all of these kind of applications. This is a practical example that you encounter every day and that's why I have picked this to make you understand why we need a robust verification. To incorporate all these kind of complex things can happen with the CPU. We have to write a exhaustive verification deck for the device under test. Here, the device is CPU. In your case or my case, it could be a design under test. That means a block. So to understand the need of the hour of the robust verification by these particular simple infographics. So this is a very sweet and simple example that will help you to understand why we need a robust verification because from beginning days, you know about the truth table. You will say, okay, we have a truth table kind of stuff and the device will operate like a standard defined way. However, in real time, in real life, when a chip is plugged into the board and the board has so many components and they will forward data and address in multiple direction from multiple sequences, the design can get crashed. And the target of verification is that we will make sure that at what time and what condition this DUT, that means your block or the full SOC, can crash. So we have to crash it. That is the purpose of the verification and hence we need a robust verification plan. So we are done with this particular infographics. Let's move on to the next slide. General verification flowchart.

General Verification Flow Chart

Here we will show you a general verification flowchart. This will contain several blocks. So at the left, there will be some block and from here we will fork outside and right side, there will be block some block. So this will happen maybe in parallel and at some point, we'll have a merger here. So wait for that.

We say so to have a proper kind of idea what we are going to see. So first, we have functional specification. It is also known as spec. That means we use the 4 alphabet, s p e c, for this. Generally, you can see as a spec or it could be a functional specification full word. Next, come the test plan. In previous slide, we have mentioned that your design under test can be bombarded with multiple address and data details from multiple directions simultaneously. We have to have a good test plan. Next, we have the assertions.

Now what are the assertions?

Assertion means you are saying affirmatively that this design will obey these kind of tasks. That means it could be a port having a particular sense of operation or it could be a bus that should be behaving in a particular way like this. So once you go in detail of the coding, you will understand what are the assertion. But as a overall, we can see assertions are way of hard coding the way the particular code or the block of code or the section of code which corresponds to our design behavior should remain in a firm way. And in case there is a violation, the verification text should flag a error or warning, whatever is applicable. Next, we proceed for hardware description coding, then RTL and also including the UPF. So we have verilog series. We already have UPF series. And for RTL, we have synthesis series. Each of them now has a marathon so that you can get the entire series in a single video as a marathon. In case you need to learn, you can go ahead and learn. We have all the resources here already in our channel. And in this arrow direction, the flow will go farther forward. Now comes the linting.  Linting, we already have published a linter on TCL  in this channel. You can go ahead and see that. You will find it in the TCL playlist. Or in case you search it, you will get it. The linting is nothing but a syntax checker routine that allows, engineer to verify the code even before running it. So that if there is a syntactical error or a semantical error, it will be flagged by the Linter tool. Linter tool could be there for Tcl. It could be for Verilog, system Verilog.

It could be there for PERL , Python, any kind of language, whether it is a programming language or a scripting language or hardware description language (HDL) or hardware description and verification language (HDVL). Linting is a general concept, and you can find linters as resources to use them for your good. Next is simulation with assertion and checking. Here, we said about the assertion. That means assertion and the code are there, and it is limited.

That means that we have almost eliminated kind of, in tactical or semantical errors. And then we simulate along with assertion and checking. So up to this stage we have reached. Now comes the bridging part. Now we have the test bench that means with the HDVL like systemverilog, and we plug it in here.

This was the hardware description and linting, and with assertions, we have done some checking for the code and everything. It is ready. Now we plug in the systemverilog test bench to our design. That is the DUT. Next, we will look for the functional coverage and the code coverage.

These are 2 detailed subjects. We will  not go in detail about them, but this will make sure that the exhaust stiffness of the robust verification are implemented as we have discussed with the infographics in earlier slide. Finally, if needed, from this step, we can go back to the test bench again and we do some modification or we may have to insert assertion or something like that as needed. And then we again come back to this state. This loop may go around until you are satisfied that the exhaustive and robust verification is implemented.

It was planned here. However, in coding, when we go for coding, we think in a way and we implement the code and then we try to check. And there is some flaw at the code level deviating from what we have thought in the planning stage. So we have to put some additional ports there to make the code go complete in nature and to tally with our test plan. And once this loop completed, then we will have the functional coverage and the code coverage, and we will have the verified RTL code and verification results.

So here, our verification, we end and we have it verified. So here in this slide, we have talked about, general verification flowchart. In actual practice, when you work in a company or you are using particular tool, you can see there is a little modification way around this particular flowchart. Obviously, because one representation can be represented by different persons in different way and with different perspectives. So all those perspective will be rest to the respective tool person or whoever or maybe the verification engineer who are doing the actual verification.

So this is a general concept. Keep it in mind and stay flexible that something can come in between or this kind of flowchart may have some changes because as we are proceeding further right, many more things are getting updated and things can come in between. So this is a very simple structure to understand the verification flowchart. 

What is Verification IP (VIP):

Verification IP (VIP) in VLSI is an essential tool in the chip design and development process. It provides a standardized, reusable component to verify and validate chip functionality against specific protocols or behaviors. Verification IP is a reusable, modular component used specifically in the verification phase of chip design. It is employed to test and validate the behavior and functionality of the design under test (DUT). Verification IP simplifies the process by providing a pre-built, standardized way to test whether the DUT complies with certain protocols or functions. VIP reduces the time and effort required to ensure that a chip design works correctly before moving to manufacturing.

General Verification Blocks in VIP:

Test Generator: Creates stimuli to drive the DUT.

Monitor: Passively observes and captures DUT signals for analysis.

Checker: Compares DUT output with expected values for

correctness.

Scoreboard: Tracks and compares transaction-level data

over time for consistency.

Verification Blocks Comparison : Regular TestBench Vs VIP

Advantages of Using VIP:

Each VIP is configured to simulate the behavior of these protocols and verify that the DUT adheres to their specifications. For example, a PCIe Verification IP will emulate data transfers, error scenarios, and ensure compliance with PCIe protocol standards. 

There are many such Protocols for which VIPs are created/avilable , such as:

1. PCIe (Peripheral Component Interconnect Express)

2. AXI (Advanced eXtensible Interface)

3. I2C (Inter-Integrated Circuit)

4. Ethernet

5. USB (Universal Serial Bus) .... & many more.

6. Time-saving: Reusable across multiple projects.

7. Comprehensive Testing: Provides a wide range of test scenarios, including edge cases.

8. Standardization: Ensures the DUT adheres to industry-standard protocols.

9. Automation: Automatically generates stimuli and checks results, reducing human error.

Open Example of VIP from GitHub :

We have talked theoretically and info graphics about the VIP. Now the VIP concept is with you. Now we will unbox one particular open example from GitHub. 

You can directly reach to this URL and this VIP is for AXI  protocol. Mostly the author name is Kumar Rishav. And here you can see this is a MIT license is there, and you can go through it. Now if you go down further, scrolling down the page here, you can see this is the block diagram of the VIP. Now here you can see the test bench top and we have the test module here. Inside that, we have sequence. You can find similarity with the block diagram that I have shown in the slides.

However, you can see there is a difference in arrangement. Now here it is a master slave architecture. And we have write sequencer. We have read sequencer. We have monitor. We have driver that drives this sequenced data into the interface. And interface will talk with the DUT. Since the DUT is not here, it is not shown because your VIP will not contain the DUT. It is the verification capsule for your DUT.

So here you can see the driver is here, okay, for the slave and monitor is here for the slave. So we have a master and slave architecture and hence we have 2 different monitors and 2 different drivers. And finally, we have a scoreboard and coverage routine here in this block diagram. Now you have seen the block diagram, which is very much familiar to which we have already discussed . Now we will go down further and here you can see the list of components.

So there is sequence item, sequencer2. We have driver. We have monitor. We have scoreboard. We have environment.

We have test and testbenchtop. And we have environmental config and test config. Okay. All these are there. You can read by yourself and understand.

Now you will have a real VIP in your hand. You can investigate in detail. How we will investigate? Do the up scroll again and here you can see there is a lot of code. Those are uploaded in GitHub and here you can see. Let's see the monitor code. Once I click, it will open a pin like this. It's similar to an ID you have in the left hand side the files and right hand side each file open in the port viewing window. So here you can see that the monitor has several amount of port. This is in either SV or UVM.

Generally, you can see here it's in UVM. So you have the UVM component here. And you can investigate this code by yourself. For that, at least, you have to have the knowledge of systemverilog and UVM.

Next, we have the master part. We have our the silver log code here for the master, and I think somewhere could be slave. Here it is the slave. This is the code for the slave. And here you can see it is very much protocol centric and that's why we have its division like this, xi slave. And here is the code of the slave and let me show you the driver. 

So here, you can see the driver will contain different, data width and etc , and it will have sequence items like this. So it will have task and functions to do the driving action. And if you go through the data, you will understand by the comments.

Now let us let me take you to the interface which, was there at the bottom of the infographics of this particular VIP. Our interface is nothing but the port connection. So in SV, we have a method called interface where we define the different ports. Here logic means it is available in only in SV not in Verilog. So guys you need to have the knowledge of SV to understand.

And here you can see all the connections are explicitly mentioned. That means if you instantiate this particular module, axi_ intf,   instantiate it, that means you can use it in a very macro way of connecting different plug and play manner, different ports, you will be doing the plug and play with this interface. So that is the beauty of the interface kind of codes in Systemverilog as well as in UVM . So we have all the codes and this is the test bench top from where we are pulling the control. And here you can see it's very simple.

We have the interface instantiation and we have the clock. We scroll down. We have the configuration here. And all the things will be in very simple manner at the top level. And here you can see, we have included the EXI package, the header file and the SV file.  And here is the test. So this is the detailed test thing. We have all the routines here for testing. And here is the code of the sequencer for the right one. There is a sequencer. So you can go up to this and have a detailed view what are there in the sequencer. 

Watch the video lecture here: 

Courtesy: Image by www.pngegg.com