Are you aware that a silent war is brewing in the EDA industry? The battle is between vendors and industry organizations. They're all vying for the chance to show you why the system-level language that they support or have developed is the solution to all of your design problems. The battlefield is every system-level design environment. To the victor will go newly found wealth and adulation for having come up with one of the key components in the next-generation system-design environment.
There's only one problem. Many of these language solutions were developed based on market dynamics and the desire for vendors to prolong the life or increase the market share of their tool offerings—not on the needs of design teams. With all of the information regarding these solutions being touted in the press, who's to know which language will meet your needs and which ones will just leave you wanting more?
There's no denying that many of the language proposals currently on the table will offer some benefit. Or, that they are craved by system-design teams everywhere. Much of this need stems from the dramatic upsurge in embedded consumer products. This trend has driven the need for a design environment higher in the food chain than VHDL or Verilog, the system level. Here, hardware and software designers are being forced to work together as part of a single team. They need a language that can describe the functionality of both sides. Unfortunately, the register-transfer-level (RTL) languages used by many hardware designers only describe the hardware.
How do you construct a language or environment that defines the functionality of both the hardware and software, and then allow these models to be carried down to the implementation stage without having to do manual refinement? Again, we find ourselves back at the original question: Which, if any, of the proposed language solutions will ultimately work?
In this article, I'll sort out the fact from the fiction when it comes to the proposed languages. We'll unravel the truth and take a closer look at some of the options that may play a defining role in the future of systems design.
Tell It Like It Is I suppose the first thing we have to ask when it comes to a systems-level design language is, "What's the big deal?" Actually, it's a very big deal. If the industry can come up with the right solution, designers, regardless of their area of expertise, will be able to work together concurrently. They'll model the behavior of entire systems, while at the same time efficiently make the needed hardware/software tradeoffs. Since designers will be able to find problems earlier in the design cycle, the system-design process will take less time.David Park, vice president of marketing at C-Level Design, says, "Use of a single common language will enable the incorporation of more hardware and software intellectual property (IP) from various sources. It will also enable the entire design to be simulated at a higher level. This will provide much faster simulation times and let the designer test the behavior of the entire chip before it is produced."
Of course, coming up with just such a single common language is no easy task. Design arenas speak radically different languages, have a host of varied constraints by which they must abide, and often interpret specifications in a dramatically different way. That's the whole reason why the discussion of system-level design languages has reached such a fever pitch. The design process has become so complex that designers simply can no longer efficiently manage the necessary constraints and make the required tradeoffs.
Of all the system-level design languages available today, those based on C/C++, like the ones from CynApps and C-Level Design, or the SystemC offering from Synopsys, CoWare, and Frontier Design, seem to be the most prevalent. C and C++ are often lumped together, since C++ is a superset of C. But some feel that for hardware description purposes, C++ is much more usable than C because of its extendability. For C++, the language is extended by means of defining classes which can be made available in a class library. With these libraries, solutions based on C++ gain the ability to realize such hardware-design concepts as concurrency and bit vectors.
Many vendors will tell you that these language solutions are the most logical choice for systems-level design. That's because C and C++ are already used extensively for hardware modeling at an architectural level, and have been for some time. Of course, not everyone agrees with this fact.
C++ Is A Complex Language Dave Kelf, vice president of marketing for Co-Design Automation, expresses his viewpoint this way: "C++ is not as widely used as people think, and it's a complex language to learn. The addition of class libraries to make C look like a hardware description language (HDL) is fraught with problems. The class libraries only work at the cycle level, eliminating most of the required hardware capabilities. The hardware capabilities which remain have the appearance of C, making their use alien to a hardware engineer.""C also contains none of the real system features for such things as protocol analysis, easy interfacing, and control structures, which makes it relatively useless for this type of work," says Kelf. "And, although C is fast for software design, as soon as the class library constructs are added in, tool performance dramatically decreases."
Steve Schulz, former president of the board of directors of VHDL International, states, "Languages such as C/C++/Java are useful mostly because some system architects are familiar with 'quick code' to exercise algorithms. Embedded software is often done this way. But that does not make it sufficient for the entire system-level design task."
What's the truth? It's a fact that C/C++ weren't originally developed to be used as a systems-level design language. C by itself, for example, has no hardware semantics. Class libraries can add basic notions of things like concurrency, yet a compiled C program only exhibits concurrency that's statistically and explicitly modeled, and fixed at compilation time.
That doesn't mean language solutions based in C/C++ are useless. They do offer an effective means of modeling hardware at a higher level of abstraction. David Park points out, "Class libraries bring you a sense of hierarchy and concurrency to get you to a level playing field, where a system-design methodology such as that being proposed by VHDL International can be used. Essentially, they help set up the framework for a hardware-design methodology."
In the case of the SystemC language from Synopsys, CoWare, and Frontier Design, the language has already garnered industry support— some 60 companies to be exact. But does that mean that as it is, it's the best solution for designers? Not necessarily.
In its present form, the language seems much more suited for modeling than actual system-level design. And the support that SystemC does have isn't necessarily from other large electronic-design-automation (EDA) companies, such as Mentor Graphics or Cadence. Mentor Graphics already has its own well-established model library, and therefore doesn't have to support the language. As for Cadence, its high-level system-design solution is language-independent. In other words, Cadence's tools don't care what language you use, and therefore neither does Cadence.
Like all of the other available system-level language solutions, SystemC will inevitably be forced to adapt into something that technically, and from a licensing point of view, meets the needs of the design community it serves. If not, it will meet an imminent demise as other organizations and/or companies step in to better serve that community.
With that said, it becomes all the more clear why some vendors might support C/C++ system-level language solutions. By doing so, they can gain control of the hardware/software design and verification market space. As a designer, ask yourself whether the development of a language that allows you to model hardware really addresses your systems-level design needs.
It's a good question. To answer it, let's back up a moment and define "systems level." Generally, this term refers to a level of design abstraction where hardware and software come together on equal footing. According to Gary Smith, EDA analyst at Dataquest Corp., it might also be defined as the point at which concurrent and serial languages operate together. Or, it's where hardware and embedded applications meet on the same playing field. In that case, many of the languages being proposed today based on C and C++ don't really offer the necessary design capability. It simply takes designers too long to translate from their embedded application code into a C or C++ language. Perhaps the industry really needs something even higher in the food chain (see "The Language Search Is On," p. 69).
Rather than requiring designers to all use the same language, maybe what's needed is a way to allow each group to design and inter-communicate using the language that they find most comfortable. That's the theory behind the proposed SUPERLOG language. As a conglomerate of C, C++, and Java, this language acts as a sort of translator between various design teams.
Then there's the Java solution. Software designers are certainly familiar with it, but it does have a downside. According to some in the industry, Java exhibits many of the same problems as C, but with even less performance and knowledgeable users. And it prevents direct access to hardware, so it's not suitable for writing initialization code and device drivers.
The Architectural Language Technical Committee (ALC), which was created under the auspices of Open Verilog International (OVI), is hoping to solve the system-level language problem by developing a system-on-a-chip (SoC) codesign language. This architectural/algorithmic standard will allow the modeling and verification of architectures, as well as the progressive refinement from the abstract layer to an implementation model. ALC also will attempt to identify appropriate links to Verilog/VHDL, while recommending possible language enhancements to enable this link.
The committee has already developed a document that defines the language requirements. Now, it's in the process of evaluating some of the commercial EDA-vendor language solutions as potential foundations for its own solution. The target date for first OVI standard approval is June 2000.
According to Robert Barker, vice president of marketing at LavaLogic, "It's unlikely that a single language syntax will meet the needs of the design community at large. That's why the industry needs to support the Open Verilog International effort to develop a Semantic Reference Manual for software languages. Synopsys made RTL-level synthesis popular when they standardized on a semantic relationship between Verilog and the hardware generated. OVI is attempting to do the same thing for software languages. If this happens, then a lot of energy can be redirected from supporting a particular language."
The Virtual Socket Interface Alliance is doing its part. Its System Level Design Working Group hopes to address the issues of system-level component integration and exchange by creating technical standards to help improve the comprehension as well as the interoperability of system models.
Before rallying around one system-level design language, the community and vendors must agree on what that language should look like. Here are some of the requirements, in no particular order, upon which most in the industry agree:
- The language must enable hardware and software to be designed together. Then, design information could be passed easily between hardware, software, verification, and systems designers. It also must handle analog, mixed-signal, and RF technologies as part of the design tradeoff space. In other words, the user must be able to quickly re-map models across hardware-software choices, explore consequences in multiple design environments, and manage/analyze multiple design constraints.
- Architectural design and implementation have to be linked through the language. Having the ability to model at a higher level of abstraction is crucial. But if those models can't be easily and automatically translated into an HDL without manual refinement, the language may not provide you the time savings and performance gains needed to make it worth your while.
- Does the language support an adequate simulation environ- ment? Once you can model pieces of your design, eventually you will have to simulate. If you're coming from a situation where you're used to working with HDLs, you become accustomed to having a simulation environment from which you can debug. Having a comparable solution at the system-level is probably important to you, so the language must be supported by a robust simulation environment—not just a simulator. It also must allow for the creation and application of advanced test structures without a loss in verification efficiency.
- Can the language adequately describe functionality and concurrency that are both explicit and implicit, such as non-intentional concurrent behavior? If so, can it be translated to parallel hardware without excessive use of class libraries or syntax restrictions? Lastly, is it based on a clear semantic foundation? If not, it may be too inflexible to actually be of use in today's time-to-market-driven design environment.
- The language must offer a substantial enough benefit that designers will feel compelled to change their current design practices. In other words, will it speed up your design, simplify the process of modeling design elements, and make the design process less error-prone? Can tools based on the language read legacy code?
These are important requirements. According to Kelf, "For any new language to be adopted, it must add real value for the main constituents in the design team. It should have advanced HDL features over Verilog or VHDL for hardware designers, software analysis features using C-like structures for the software guys, and verification constructs for the test guys, including random-directed testing-type stuff. It also should have systems-level features for the architects (protocol analysis, interfaces, etc.)." - The language must be usable. This sounds fairly obvious, unless you've ever been asked to use a so-called "easy-to-use" EDA tool that turned out to be anything but easy.
- It has to allow for the evolution of design from current methods, with a minimum learning curve. The design process is hard enough already, without the time investment that a long learning curve would require. Should the need arise, it becomes incumbent on vendors and industry organizations that any system-level design language be adequately backed by the availability of training and support.
Obviously, these aren't the only requirements. But they do offer a starting place from which to evaluate those solutions now being touted in the market. As this list of criteria continues to grow, it may help us to either zero in on the best system-level design language or refine what's already available until it adequately meets the needs of the design community.
A Plethora Of Choices One reason that this war is so confusing is that a number of different options are available today. That leads to so much discussion over why one is far superior to another. Chances are each will adapt in the coming months to address the needs and wants of the design community. Otherwise, it's a safe bet that their ultimate success will be determined on the nearest trash heap. In the meantime, to help clear up the confusion, here's a look at some of the options being touted today:- C++/Cynlib HDL. This language from CynApps is based on standard C++, with extensions to address the issues of a clock-based concurrency model and bit-accurate data types. These extensions are contained in the Cynlib class library. They provide the hardware-specific vocabulary needed to create detailed descriptions of hardware in C. The resulting language allows any hardware model written in the language to be compiled and executed with any standard C++ compiler. CynApps' tool suite then helps transform the hardware model into the required input format for standard logic-synthesis tools. The C++/Cynlib language is available now. Moreover, its source code is open to all users and vendors.
-
SystemC. SystemC is a modeling platform based on a set of C++ class libraries for expressing such hardware-design concepts as concurrency, abstract communication, and a simulation kernel. Once the models are complete, CoWare's Interface Synthesis technology can be used to synthesize the real implementation from the abstract description.
This language was developed with technology contributions from Synopsys, CoWare, and Frontier Design under the auspices of the Open SystemC Initiative (OSCI). Now backed by the endorsement of 60 companies, this initiative is dedicated to rallying the industry behind a single modeling platform.
SystemC version 0.9 is now available through an Open Community Licensing program at no cost to the licensee. It may be downloaded at www.systemc.org. Version 1.0 of the source code is expected to be released in March 2000. SystemC is fully compatible with a broad range of leading compilers for Solaris, Linux, and Windows NT platforms. -
SUPERLOG. This language is being developed by Co-Design Automation. It's based on Verilog and uses most of the C programming language and system constructs, as well as pieces of other languages currently in use like Java (see the code listing). This isn't really a new language, so it requires little to no learning curve and can be easily incorporated into existing design flows. And because SUPERLOG leverages the best parts of many conventional languages, designers can opt to design with it or the language with which they're most familiar, whether that's C, Verilog, or Java. VHDL is expected to be added to that mix.
Co-Design plans to announce a suite of products based on the SUPERLOG language early this year. In the meantime, specific details of the tools and language are being kept quiet as the company considers opening it up to the public domain. -
Java. The Java solution, as proposed by LavaLogic, comes complete with a programming language, platform, and environment. The programming language is simple, object-oriented, distributed, interpreted, robust, secure, and architecture-neutral. And that's not to mention portable, high-performance, multithreaded, and dynamic. Its underlying platform employs a stack-based virtual machine that executes byte codes. Java source files can be compiled into a ".class" file that contains all of the instructions (byte codes) necessary to implement the program on the virtual machine. This can be done using any Java compiler. The language also provides a collection of standard higher-level libraries in the form of application programming interfaces (APIs).
To help support the use of Java as a systems-level design language, Lava-Logic has come out with Java-based compiler technology. Known as Forge-J, this Java-to-Verilog compiler is now
