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.