I recently was working with a customer who was using our verification IP for the first time.  His quote was memorable: “Your VIP doesn’t work.”  Odd, I thought as we have extensive regressions, have compared it to the standards body golden model and run it with our own core IP.  And yet, “It doesn’t work.”  On to a call with the customer to sort out what is the issue: simulator, OS/platform, test environment issue.  It turns out, the VIP was doing exactly what it was commanded to do.  That is to go through initialization of the link and then send packets.  This is great for 99% of the cases out there except for this one.  The issue, it turns out, is that the VIP wasn’t told how to initialize the DUT for this particular application.  Of course, how could it know?

This brings me to my point, communication isn’t just for chips.  In this case, the designer hadn’t let the verification engineer know all of the nuances of the design and some fundamental information was missing.  And the protocol had a specific sequence for the initialization that the verification engineer needed to know for this application.  The point is that we need to work on our communication.  It’s about knowing the design, the protocol, the intent of the tests (see Core IP - Check!…).  And it’s not limited to just the design and its test environment.  It’s about support too.  When sending in a question for support, help out by providing log files, waveforms or code fragments up front.  This will help speed up the time to response to the question.

So, how did our customer do?  Well, once we got the design nuances and protocol initialization worked out, the DUT came up and packets were successfully sent through the DUT.

Communication: it’s really not just for chips!

Until next time, Jay.

One of the core decisions we made with the OCP VIP was to give the user complete randomization control, external to the transactors. This isn’t something we have practiced in the past, or something that has been enforced in the other suites. But its something we feel makes for the optimal usage model relative to VMM, so we expect it to become the norm as opposed to the exception.

The reason this makes things optimal is the simple fact that it puts the user completely in control. Instead of “magic” happening once something goes into the transactor, the testbench gets to make the decision up front, and can rely on the transactor just doing what was requested.

To understand this more fully, consider one of the items typically randomized by transactors — delays. In OCP there are delays between phases and transfers, as well as handshake delays such as the delay between when MCmd appears on the bus and when the corresponding SCmdAccept is placed on the bus.

With OCP these delays are all defined in the transactions. So the user has total control of the delay values, and the transactor just implements the delays requested by the user testbench.

Consider what typically happens when transactors control the delays. They might do one of the following:

• Pick a specific delay
• Randomly choose what they consider to be a “reasonable” delay
• Let the user define the delay range and randomly pick something in that range

Now consider what the user can do if they are completely in control of the delays. In addition to the above, they could:

• Choose a random delay based on the command type (e.g., RD, WR)
• Choose a random delay based on pretty much any other information in the transaction (e.g., burst length, burst sequence, etc.)
• Choose a random delay, biasing the values to smaller (or larger) values using weights
• Manually define specific delays in order to accomplish a specific delay situation

Basically, the user now has the freedom to do whatever they want to control the delays, and they are not limited to the few choices that the transactor developer came up with. Freedom (and control) is a good thing.