Indago Protocol Debug and IP Verification

7 May 2015 • 3 minute read

Nothing beats knowing, a late electronics-industry veteran used to say. That’s no more crucial than in debug, where Cadence has recently rolled out the new Indago Debug Platform to attack the biggest bottleneck in the IC functional verification flow.

Richard Goering, who blogged about the announcement, wrote: “Part of the Cadence System Development Suite, the Indago Debug Platform can reduce the time to identify bugs in a design by over 50% compared to traditional debug methods.”

We know the challenges verification engineers face today, but many use the same traditional debug processes that have been in place for 20 years: code, simulate, analyze some waveforms, debug. Repeat.

Proliferating Protocols

Consider now an increasing challenge facing today’s SoC designers: Interface standards (see example in graphic, below). PCI Express, USB, Ethernet, ARM’s Advanced Microcontroller Bus Architecture (AMBA), and the Double Date Rate (DDR) memory interface have become universally deployed standards in recent years.

Designing with these interface standards was once straightforward but now is a complex undertaking in part because these few standards have sprouted many variations.

Take, for example, DDR memory: A single specification in the year 2000, it today boasts 15 different variations. ARM’s AMBA now has eight variations. And the list goes on.

Verifying these standard interfaces has to be done, and that process has become one of the most resource-intensive tasks for verification engineers. And that’s a problem because verification engineers seldom have more than a couple weeks to ramp up on a new protocol before they have to start verifying designs incorporating it.

“The diversification of standard interfaces is a legitimate trend, something that people have to deal with,” said Moshik Rubin, product marketing director from Cadence. “And it makes the debugging process that much more difficult for verification engineers.”

Verification IP (VIP) takes much of the strain out of this, but it’s not enough amid this interface explosion.

Let’s examine what this looks like in practice: Let’s say you’re designing a new controller chip that’s going into an external disk drive and it needs a USB interface on it. You start to simulate that, and your verification IP flags an error: The chip issued a command and the host on the computer (played, in this case, by the VIP) issued another command. It says “hey your chip responded with wrong response.”

The verification engineer, dealing with SystemVerilog code for his testbench, looks at the long string of packets received by VIP to try to determine the problem. At this point, the pressure’s on him to translate the design behavior and protocol specification requirements to figure out the root cause.

New Views

With the release of the new Indago Protocol Debug App on the Indago Debug Platform, engineers now have a way of understanding their design behavior in the context of the protocol specifications to help understood the root cause of the problem.

The new app features a lab-equipment style view—a user interface with which verification engineers are familiar. It’s essentially the same view an engineer would have if he or she hooked up the real device to a piece of lab equipment. This gives them better visibility into design behavior as it “speaks the language” of the specifications.

The app’s channel view abstracts the communications between the VIP and whatever it’s talking to (in the above example it’s a disk drive) as commands that are found in the USB specs. Rather than describing the results at the RTL chip-level details, this feature offers a higher level view of how the communications are conforming to the particular interface specification. Therefore, it's easier to see whether the sequence of commands and responses is correct. A state machine view is also provided that shows what state the VIP is in and how it got there. No longer does the verification engineer have to extrapolate between his observations about what the design is doing and what the interface spec says it should be doing.

And in this way, you can see where your design may have a bug with respect to implementing the specification.

Brian Fuller

Indago Protocol Debug and IP Verification

Proliferating Protocols

New Views

Related Blog Posts