[Technology Report]
System-Level Languages Fight To Take Over As The Next Design Solution
Hardware/software designers must learn to dodge the rhetoric to find a language that eases the burden of system design.
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.
Reprints
