editor's blog
Subscribe Now

Validating Serial Protocols

When I was approached to talk about a new product from Arasan, I ran afoul of my favorite source of confusion from the Bureau of Arbitrary Definitions: I thought it was a verification story, when in fact it’s a validation story.

In case you think those two sound like pretty much the same thing, I always like to reinforce the confusion by defining verification as the act of proving that your design is a valid implementation of the design spec, while validation is the act of verifying that your design works properly in its desired setting. (Confused more? You’re welcome.)

Most of what we discuss in these pages is verification – making sure that there are no implementation deviations from the design spec. We spend much less time on validation, where the design is put into its native operating environment to see if it works as intended. This is often the domain of emulators, where you can connect in real system components or drive in real data traffic at speed to see how things work.

Arasan notes that this is becoming a problem with protocol stacks that communicate across gigabit (and higher) serial links – the emulators can’t keep up. They might be able to handle the physical layer (for instance, if there are FPGAs in the emulator, it’s likely they can handle serial data), but even so, the higher level portions of the protocol stack will be emulated, meaning they can’t run at speed.

They say that the standard solution for this is to place a rate-matching unit between the emulator and whatever is being used to validate the design. But because the emulator is slow, you end up waiting a lot – it certainly doesn’t reflect what a real traffic pattern would look like. In addition, apparently not all protocols have a rate-matching solution: MIPI, for example, can’t be handled that way.

So Arasan has released what is essentially a small tester that can be connected to a high-speed prototype board to test the design without an intervening rate matcher. It has a processor that handles the top levels of the protocol stack; that’s then shipped over to an FPGA that handles the bottom 4 levels of the stack and drives out directly to the design you’re testing.

They have different connectivity boards that can be swapped out for different protocols. Yes, in theory you could combine them, but they say that it’s rare that a design team needs to validate more than one protocol: a specific connection will operate on only one.

You can find more information in their press release

Leave a Reply

featured blogs
Dec 5, 2019
In November, we wrapped up our technical debt cleanup, upgraded several of our back-end APIs, and rolled out several small user-experience updates throughout Samtec.com. These updates will pave the way for some exciting new applications and e-e-commerce features in 2020. Here...
Dec 5, 2019
Hello everyone! I am Aravind R, Principal Support AE at Cadence, and I have been supporting various users at our customer sites to generate and validate various formats of standard cell and IO... [[ Click on the title to access the full blog on the Cadence Community site. ]]...
Dec 4, 2019
At their recent Open Innovation Platform (OIP) Ecosystem Forum held in Santa Clara, CA, TSMC named Mentor as their OIP Partner of the Year in four categories during the awards luncheon: Joint Development of 6nm Design Infrastructure Joint Delivery of SoIC Design Solution Join...
Dec 4, 2019
Any reasonable thinking being knows that the Earth cannot possibly be flat -- if it were, cats would have pushed everything off it by now!...
Nov 29, 2019
[From the last episode: We saw what it means for an electronic system to sleep.] You'€™re on a phone call having a conversation, and you hear the sound that indicates that someone else is trying to call you. So excuse yourself to the person you'€™re talking to and quick t...