ESL from a Software Developer's Viewpoint

Few people would disagree that the spiraling complexity of system-on-a-chip (SoC) design is taxing the ability to designers to create these chips economically and in a timely fashion. The seemingly insatiable consumer demand for increased product feature sets—at decreasing prices—has resulted in the so-called design gap, the spread between the number of transistors that can reside on a chip and the number that a designer can actually implement into an SoC design, to widen with each process shrink. Clearly, current design methodologies, based on RTL languages such as Verilog and VHDL, are hitting a brick wall.

The generally accepted solution to this problem is to raise the design abstraction level above RTL, using Electronic System Level (ESL) languages. ESLs have been around for several years and have taken two paths-open languages such as SystemC, with support from the Open SystemC Initiative (OSCI) and System Verilog, supported by Accellera, along with several proprietary languages, many based on C, developed and promoted by various EDA vendors. Now, if you accept the use of an ESL to increase chip-design productivity you need to ask yourself—what do I expect to get out of designing with an ESL? This requires a quick analysis of what goes into the design of an SoC.

Successful SoC design is a merging of efforts of two groups of people, one group that does the hardware design of the chip and the other that develops the embedded software to run on that chip. The software development team has become more important as SoC design has matured, since performance and feature sets are increasingly driven by a chip's embedded software. The software also provides the chip vendor with product differentiation and flexibility. The role of software in SoC design was summed up nicely by a remark made by a Cadence employee a few years ago, "silicon without software is just sand." To successfully be accepted as a "new" SoC design language to replace current RTLs, an ESL must provide benefits to both the chip hardware and software design communities—this is where the confusion of how an ESL will be accepted and used arises.

Despite the best efforts of EDA vendors and designers, SoC hardware and software co-design has not been successfully implemented. Various EDA companies have developed tools and techniques for helping hardware designers and software developers work more closely and earlier, through methods and tools such as hardware emulation and virtual prototyping. However, by and large, software development still begins relatively late in a chip's overall development cycle and the software and hardware teams continue to work pretty much independently. When the idea of an ESL was first proposed, many believed that that the 'right' electronic system language would be embraced and used as a design language by both hardware and software developers. This is not now, and probably never will be, the case —hence the 'soft spot' of ESLs. However, this does not mean that an ESL is undesirable and that it will not provide substantially enhanced design productivity for both SoC hardware designers and embedded software developers alike. A key point is to understand how this benefit will occur.

In speaking to several people involved in the development and use of ESLs, I found that each agreed with the assessment that an ESL will not replace C or C++ as a software developer's language of choice for algorithm and embedded software development. All thought, however, that an ESL would benefit the software-development community in several ways, simplifying the way software developers work with hardware designers.

Dennis Brophy is Chairman of Accellera, a standards organization whose mission is "to drive worldwide development and use of standards required by systems, semiconductor and design tools companies, which enhance a language-based design automation process." As the head of the organization developing the SystemVerilog standard, Dennis is in a good position to understand what an ESL should "bring to the table."

In an ideal world, Dennis says, there would be a common design language for hardware and software developers that would eliminate the human talent needed for software/hardware partitioning. However, he thinks that there are too many dynamics for this to happen. Dennis feels that the "art and science" of software engineering is different enough from hardware design to have hardware designers dictate what would work for software developers. However, it is critical that the hardware people address their designs with a software focus. This is where a 'good' ESL fits in—it adds commonality and "software friendliness" to the processors and other hardware that hardware designers use it to implement. Dennis feels that an ESL must be 'friendly' to C and C++, and that both SystemC and SystemVerilog have this attribute.

David Stewart is CEO of CriticalBlue, a company that has Cascade, a coprocessor synthesis tool for translating embedded software into a custom microprocessor. David shares some of Dennis' concerns on how an ESL should benefit embedded software developers. With hardware and software design being two very different processes, David emphasizes that it is impossible to generate 'perfect' hardware from C, since there is no concept of timing, in a hardware sense, in C. This is analogous to not being able to develop your embedded software from an HDL like Verilog. He feels that the electronics industry is looking for embedded software to work with C, not for C to work with hardware. An ESL is used by hardware designers to accelerate their chip designs. Like Dennis, David believes that rather than being viewed as a language for software developers, an ESL should provide software developers with an easier way to work with the hardware design team.

Mark Milligan, president of the OSCI, focuses on models as the key to a successful ESL. Mark believes that software developers don't care about another development language—they use C now and may start using Java down the road. However, he does believe that they need better hardware models and that this can be done via an industry-standard ESL that connects the hardware designers and software developers early in a chip's design cycle. Design tools built around such an ESL provides various types and levels of design views to both the software and hardware teams, thus better 'connecting' both groups of developers. Mark emphasizes the "industry-standard" aspect of an ESL—he believes the a proprietary ESL will not enhance the communication between hardware designers and software developers due to different hardware sources, models, use of legacy code, and other factors.

Finally, Matthew Bellantoni, a product marketing manager for Carbon Design Systems, a provider of tools for pre-silicon chip and system validation, echoes the superior modeling advantage of an ESL for both hardware and software teams. He emphasizes that an ESL-based methodology is truly a system-design methodology, not one where hardware is conceived and then software is developed. With an ESL-based design flow, software developers can begin their jobs earlier in the project schedule and can make use of virtual hardware models that can be created more quickly than with an RTL-based design flow.

The bottom line is that the role of an ESL in SoC design is misunderstood. There is general agreement that an ESL can accelerate the design of a chip's hardware. However, software developers won't use an ESL directly to develop their software. With an ESL-based design they will, however, have an easier job working with the hardware design team through enhanced models, available earlier, and through better communications between the hardware and software development teams. Also critical will be the availability of design tools that can take advantage of the attributes of the ESL, including good behavioral synthesis tools (which have been a long time in development, but are still not at a stage where they are used for mainstream chip design).

Now if we can only get the SoC community to decide which ESL language to rally around.

Jim Lipman is currently Vice President, Client Services for Cain Communications, specializing in the development and implementation of communication and marketing services programs for companies serving the semiconductor, silicon-IP, EDA, and other high-tech electronics-industry segments. Jim's experience includes chip-design R&D, marketing, marcom, consulting, technical editing, technology training, and on-line publishing of technical content for engineers. His email address is jlipman@caincom.com.