Methodology Is Important But Language Matters - Part 1

Historical trends in languages

Many of us have traveled around the world, and while we can often communicate with local people in our own language, we realize it is best to communicate using the local language. It helps to "break the ice" if you at least try to use some of the local language, perhaps from a guide book. The moment you do it, barriers are removed, and you are more trusted. All this considered, it is still a significant handicap to use the wrong language for the task at hand, especially if you need to have a serious conversation. We see the same barrier (or need) as we look at design and verification languages.

In 1989, short time after I started my career at Daisy Systems, I enjoyed teaching customers VHDL as a new design language replacing schematic diagrams. Several years later, I witnessed the transition of the market to Verilog and eventually the migration to mixed-level design using both Verilog and VHDL. I saw the transition from OVL to PSL to SVA, as assertion languages, and eventually the support of the mix of these languages (the design, the verification, and the assertion).

In the next two blogs, I would like to discuss the directions in the languages that will be chosen for TLM (or ESL) design and verification addressing hardware developers. Obviously, we can't ignore the other target audience - the SW developers. Software developers have no "religious" preferences about hardware design languages. All they want is speed and early access to the hardware platform while they continue to work in their friendly development environment.

The new hardware design language - C/C++ vs. M vs. SystemC

As we at Cadence engage with customers using high-level synthesis (HLS), we see two camps: one that drives SystemC (with TLM) as the main design language and another that drives C/C++ as the main design language. And while other languages are being used at a higher level of abstraction (such as M-Matlab), I do not see them becoming part of the mainstream design flow in the near future since their output produces Quality of Results that are far from being ideal for implementation.

Cadence endorses the industry standard SystemC extension of C/C++ and drives this as the key design language for new IP development. Cadence also provides tools that let customers' model simple datapath functions in pure ANSI C or C++, and then automatically import or convert them into a complete SystemC environment. SystemC has many built-in capabilities for supporting hardware modeling at abstract level as well as standard TLM APIs for software virtual prototype. We see SystemC as the basis for an order of magnitude increase in productivity - one can model their entire hierarchical design (datapath, control logic, or complex bus protocols) in an industry-standard way to understand and validate concurrency and complex code, while using high-abstraction untimed C++ for most of the main functionality. One can synthesize the hardware design and get a virtual model from a single source code - eliminating today's huge risk where the software is designed to work on a virtual platform which operates similar to, but not the same as how the actual hardware platform operates. ("What you see is what you get!"). This new approach can combine three use models (algorithmic model, virtual prototyping model and architectural model that can be implemented) into one.

So where do we go from here. Will RTL disappear? Not likely.

RTL will continue to be part of the flow similar to gate-level today and we will see more designs that will create RTL automatically as an output rather than hand coded.

So, is it worth it? Why should we change? Our customers reporting 3-4X better  productivity during the creation of their IP and 10X when they reuse or explore architectural trade-offs for their IP. As design cost is increasing and IP reuse becomes major part of development process, 10X productivity improvement can not be ignored by the executive management.

Do you agree? I would like to hear your opinion too. My next blog will be dedicated to TLM verification language.

 
Ran Avinun