Know Your Protocol: A Verification IP Perspective

It takes more than just acquiring the IP and throwing it together to verify your design. Purchasing third party IP for cores and verification models greatly accelerates your design and verification schedules but you still need to have the basic understanding of the IP that you are using. If you have purchased from a trusted IP supplier, you can rest assured that the IP you have purchased has been fully verified to faithfully implement the protocol for which it was designed. What you need to do is verify the connectivity of that IP with the rest of your design. You need to have knowledge in areas such as reset, initialization, legal protocol traffic and exception handling.

There are some good reasons why you will need to know about the protocol. Let's start at the beginning with reset and initialization. Many protocols have initialization requirements and sequences that need to be followed in order to function. Quite frankly, if you can't get the interface initialized you are going to have a very uneventful simulation – no pun intended. Purchasing IP doesn't relieve a verification engineer from the task of understanding what the protocol is doing and when it needs to do it. Let's look a little closer at how we get PCI Express initialized. If we're using the PIPE interface, after you assert and de-assert reset there are handshaking of control signals and clock generation from the Phy that needs to occur before you'll go into link training. During link training, ordered sets are sent between the upstream and downstream devices to establish synchronization on the link and then there are flow control credits and configuration packets. The VIP will take care of letting you know what is being sent and if it sees errors but it cannot infer the intent of your test. Let's take a hypothetical case of the link coming out of reset but the link never enters the L0 state. It could be that the appropriate order sets weren't sent or lanes were not connected the right way for your configuration. The VIP will provide you with indications about what is happening in the simulation (i.e., symbol log files, transactions logs, protocol messages) and you're knowledge of the protocol will help you interpret what is going on. Getting past initialization, you start sending packets back and forth and life is good. But now it's time to venture into the land of error injection. After you get through link training, suppose you choose to send corrupted packets. You'll need to know the packet structures, when packets are ACK'ed and NAK'ed and what happens when each of those responses is received. It is also helpful to know what causes a packet to be retried. Or you may want to force the downstream device into a different lower-power states. In order to make the appropriate choice, you'll need to know the states, the rules regarding those states and what makes sense from a forcing standpoint.

The VIP are a tool for you to use in verification. But like any tool, you need an understanding of the underlying processes that are taking place and how to position/interpret/manipulate what is going on. The bottom line is that you really need to understand the protocol in order to develop useful tests for your DUT. Similar examples can be cited for USB, SATA, XAUI, etc.