This has been a fruitful year for new design-language solutions. Even though some marketing pitches seem to be confusing apples with oranges, if we sort through the smoke and avoid the mirrors, things actually start to make sense. We see that the real problem facing the design-automation industry has to do with hardware/software codesign. Regrettably, many vendors project the message that their language solution will solve all design problems, not just those associated with codesign. Let's break down the design problem as it relates to languages.
Gate-level design was driven by schematic capture. When the industry moved to the register transfer level (RTL), Verilog and VHDL became the languages of choice. Now, as we make the jump to the electronic system level (ESL), a new language is needed. Does that mean that Verilog/VHDL will go away? Are we going to need to learn a language just to continue RTL design work? Don't hold your breath. Designers still use schematic capture!
Think of it this way: The ESL is where we codesign hardware and software. The design is then synthesized and the results handed down to the hardware designer and software developer. While there is a continuing need to codevelop and then coverify, the coverification part already is being handled by current languages. It isn't until designers try to codesign that the use of multiple languages becomes impossible.
So what happens today? First, we describe the system using English, French, German, Japanese, or Chinese—you get the picture. These languages aren't exactly the most precise way to do an electronic system description. That's the problem which the VHDL International's System Level Design Language (SLDL) working committee is currently attempting to address. SLDL's Rosetta language is a formally provable systems-requirement language.
Design teams would start with the Rosetta language and then hand it down to C, C++, Verilog, VHDL, etc. As a result, designers could prove that, whatever language is used, the resulting lower-level description will meet the specification. That's a very comforting thought in an era of multimillion-dollar design programs.
Today, though, designers translate the English specification directly into C/C++ or actually a superset of C/C++. Hardware design is concurrent, whereas software design and design languages like C are sequential. That's what SystemsC and CynApps libraries are all about. They're simply standardizing a design practice that's been going on for 10 years. There are dozens, if not hundreds, of proprietary C libraries used for systems modeling. SystemC and CynApps offer concurrent C++ modeling library standards—nothing more, nothing less. These are vital in hardware/software codesign, as well as for use with the coverification tools presently on the market. Like all design, it starts with the models.
So what about Java? It's basically the same thing. It seems that C++ actually was a failure. That's why the standard language today is actually C/C++. C++ adds a lot to C. But if you try to use it as a standalone object-oriented design language, it doesn't work too well. Quality is a major concern. The pointer issue takes most of the blame. Also, one designer's objects don't talk well with other designers' objects. This is pretty familiar territory for a hardware designer. A growing number of people believe that Java will replace C/C++ within four to six years. But it's a sequential language and, as I pointed out before, we have a concurrent design problem. From a system-level perspective, it seems that for EDA tool vendors, the real dividing line in the design process may be between concurrent and sequential design (see the sidebar figure).
One of the major problems we've encountered over the system-level language issue is that few people actually understand the world of embedded design. Electronic-design-automation (EDA) vendors are actually application-software companies. They design in C/C++ like most other application-software vendors. They've wrongly assumed that the embedded world also uses C/C++.
What it comes down to is that there are two distinct styles of design in the embedded world. The embedded applications developers prefer C/C++, just like non-embedded applications vendors. On the other hand, firmware developers really dislike C/C++. The problem seems to be that they're solving a concurrent design problem. Sound familiar? So if a vendor tells you that designing hardware in C/C++ is the obvious choice, ask why no one has ever convinced firmware engineers of that. In fact, there's a chance that the "seam," or division between design styles that a system-level language is supposed to address, isn't really between hardware and software at all. It could just be between firmware and applications software. Or, in other words, between concurrent and sequential design.
That brings us to the issue of other alternate languages, such as SUPERLOG. Is what we're searching for really a concurrent language that can work well with a sequential language? That's my guess. Of course, adopting a new language takes multiple years, possibly four to six. Could it be that we're searching for our hardware version of Java?