Open IP Development Tools

By Pascal Chauvet
How much time have you wasted trying to understand software tools by deciphering the logic of their creator? I always find it very frustrating to be limited by features and tool capabilities that do not do exactly what I want, or which do not work at all with my other applications. We are engineers! We can learn and adapt, but we often want to be able to extend and improve the tools we are using. Why is that not always possible?

Adding or replacing an EDA tool from different vendors in your design flow does not have to be a headache. It should never force you to make major modifications in your methodology and overall environment. So how is it achieved? Enforcing the support of standards for tool interoperability is an obvious first step.

In the world of SoC architecture exploration and platform assembly, the IP-XACT standard, despite its flaws, has been widely adopted. IP-XACT also is used to ease IP integration. Similarly, IP model interoperability has benefited from SystemC TLM 2.0. For performance analysis and system debugging, UVM transaction recording and SCV transaction recording have made it easier to share instrumented models or RTL monitors to analyze simulation results.

Modularization of functionalities, in order to be shared across a common software platform such as Eclipse, opens up new opportunities for tool interoperability and integration.

Scripting capability built around the base commands of any tool transforms it into a very powerful application in the hands of its user. The most successful EDA tools have such a customization layer.

The de-facto language for user-level scripting in the EDA industry is TCL. Many CAD departments have managed to build complete infrastructure around their tool flow with TCL. I believe it is safer to stay away from any wholly proprietary language, or even any more exotic language, as these defeat the purpose of language unification.
The support for industry standards, along with the scripting capability of tool environments, defines what is called the “openness” of these environments. The more “open” the tools, the easier it will be to use them together and to adapt them to your needs.

EDA vendors are not the only companies building CAD tools for their users. Tools built by IP providers are often underestimated and should also be subjected to close scrutiny about openness. The more configurable an IP, the more sophisticated will be the tools associated with it. Memory subsystems and on-chip communication networks (interconnect or network on chip) are perfect examples of highly configurable IP. Ironically, even if these complex IP products are architected and designed to be easily interfaced with all other IP cores in a system, their tools may not be built with the same objective in mind.

Architecting and assembling a large SoC implies intimate knowledge of all the IP components that compose the system. That is why it can be extremely challenging for an EDA vendor to build such design environments. Until recently, the big 3 (Cadence, Synopsys and Mentor Graphics) had not shown much interest in tools for architects, or even tools for platform assembly. Perhaps the numbers for the ESL market were considered too small to be taken seriously.

EDA vendors tend to build new tools starting with very broad objectives. They want to determine if the tool creates any interest, but unfortunately these vendors usually barely scratch the surface. It is not until they work with a lead customer and address customer-specific requests that they refine the implementation. Openness and more precisely scripting is a must, so the user can add their own “know-how” to the tool.

IP vendors, on the other hand, have full knowledge of their IP, but they will often sacrifice having an open environment in order to limit dependency on external elements out of their control. This approach is indeed a safer, easier, and faster way to get a tool out that addresses your IP needs. But does it really help a customer to achieve their goals?

Forcing architects to systematically translate the requirements and constraints of the large system they are building into IP specific ones is an inefficient task. At the end of the day the entire SoC has to perform as expected so it can implement all the supported applications.

Buyer Beware. Any company evaluating a new IP should pay close attention to these tooling aspects. It is necessary to look beyond the mere “eye candy” UI. Ask yourself these questions: How will this tool play with the rest of your environment? And will you be able to extend it and mold it to your needs? Always be wary of vendors that assume they know more than you do.

—Pascal Chauvet is an application architect at Sonics