Real Intent’s Pranav Ashar on converging design and verification

Sometimes it’s useful to take an ongoing debate and flip it on its head. Recent discussion around the future of simulation has tended to concentrate on aspects best understood – and acted upon – by a verification engineer. Similarly, the debate surrounding hardware-software flow convergence has focused on differences between the two.

Pranav Ashar, CTO of Real Intent, has a good position from which to look across these silos. His company is seen as a verification specialist, particularly in areas such as lint, X-propagation and clock domain crossing. But talk to some of its users and you find they can be either design or verification engineers.

How Real Intent addresses some of today’s challenges – and how it got there – offer useful pointers on how to improve your own flow and meet emerging or increasingly complex tasks.

“We’ve seen this and said this before, but for today’s big systems, you don’t want to do a lot of separate design and verification,” Ashar says. “Each represents a major project in itself and until now each has required its own process. When things become as complex as they have, you have to interweave them.

“This isn’t just because it is inherently more efficient. The level of complexity is such that it becomes predictable that the boundary between the two will blur. That’s happening and it will continue to happen. It’s critical to understand that it is almost a natural evolution.”

The next issue is how to communicate this and the flow changes it requires on both sides of the D&V divide. In some cases, you don’t. Instead, you present information to different communities in the way they most easily understand given existing working practices.

In Real Intent’s latest update to Ascent XV (its X-verification and reset suite), the company worked from the assumption that different disciplines look at things in different ways. The verification engineer concentrates on X-related issues; the design engineer wants detail on resets, power management schemes and proliferating clocks. The company tailored the tool’s interfaces and outputs accordingly.

Real Intent is not alone in adopting this approach. But perhaps it is only a beginning.

Fuzzy verification boundaries

Ashar draws a useful comparison with the ongoing debate over hardware-software co-design, and the similar tailoring of tools to users that it has seen.

“The underlying technologies for hardware and software are in many respects very similar. For example, execution paths are important on both sides. Having said that, though, the computational paradigms are different as are the data management procedures. Aspects like that, right now, explain why debug tools have different flavors, why they are presented to the user in different ways,” he notes.

“But, in terms of this whole hardware/software debate, we still seem to talk more about two separate worlds. Where there seems to be less discussion is, again, in terms of these fuzzy boundaries. So, we don’t talk much about how the hardware is increasingly looking like the software. Yet, the abstraction layers above RTL do look more and more like software algorithms, and they are becoming a lot more important in terms of how a system is assembled.”

Coming back to the world of verification, Ashar suggests an approach that, while it may not define two different disciplines, could more closely align them.

“Simulation,” he says, “is a last resort. It largely comes about because of things that we do not understand. It is a back stop.”

More and more, we do use simulation where we cannot attack an issue in another way. Then the challenge becomes using both design and verification processes to do this and simulate as little as possible.

“From how we position our own tools, that’s very much how we look at it,” Ashar continues. “Within the Ascent family we have linting, which makes sure your code is ready and has no synthesis issues, and we have capabilities to manage X issues – optimism and pessimism – as well as resets. That is all very much about doing what you can to get ready for simulation.

“Within Meridian, the focus is on clock domain crossing. There you are dealing with finding important bugs that are hard, sometimes impossible to find in simulation. Yet you can’t let them get out into the field.”

Real Intent has itself expressed this overall strategy as a path toward a true ‘SoC sign-off’ flow as well. It’s an equally useful shorthand for broadening out the user range – a top-down one as opposed to the the more bottom-up thinking offered here.

However, if these convergences are ‘natural’ and ongoing processes, it cannot hurt to offer both arguments to the market. If a process is already happening and is likely to accelerate, the sooner one understands the drivers for that change, the better. And for all the performance gains that the main simulator suppliers continue to eke out, they too have moved toward this idea of pulling tasks out of simulation bit by bit.

But most important of all, change is coming. However you choose to describe it, it is a natural process and therefore one that is unavoidable. And whether you buy one company’s tools or another’s is pretty much irrelevant. Though, of course, those who are better at articulating the shifts ahead are also those likely to shift more licenses.