As integrated circuits (ICs) continue to grow in size and complexity, designers are faced with the challenge of keeping track of exponential increases in data volume and design complexity. The move to hierarchical design styles, in conjunction with the incorporation of large blocks of functional units of intellectual property (IP), is providing only a limited ability to stretch the existing RTL tools to meet today’s demands. Current tools max out at 40 millions, give or take - far short of the promised real estate at 90 nanometers, let alone 65 nanometers and below. Not surprisingly, people are now looking for the next breakthrough in design productivity and are thinking it may be in the electronic system-level (ESL) tools.

The key here is to move to the next level abstraction, to start at the architectural level and refine down from there. The tools to support this move will have to simultaneously address large, high-level blocks such as processors and large peripherals, and the gate-level detail of an address decoder. In addition, the tools will need to handle the integration of hardware and software, since one of the parameters for optimization is system throughput versus power consumption.

What is ESL?

Unfortunately, in the rapidly growing area of design tools, getting everyone to agree on basic definitions is a challenge. The definition of ESL is in a state of flux. Originally, the term referred to the concept of system-level design. Now, ESL seems to include at least some reference to hardware-software interactions, as well as higher levels of abstraction. A possible distinction is to see ESL as an activity, not as a language syntax. Either way, ESL needs to address the system-level tasks.

At least one good starting point for the discussion then, is to distinguish between areas of design specialization, whether it be hardware/software, SoC, embedded, or component-based design.

Hardware-software tools evaluate the interactions of the proposed hardware architecture and the software that runs on that hardware. Early evaluation of this set of partitions allows the design team to move blocks of trial code into either a hardware or software model. The architect can then adjust the partitions for better optimizations.

SoC-based tools approach the process with a hardware-centric view of the design at the functional block level. These tools assume the software will run on a final hardware platform of some sort. The SoC approach can take into account the many implementation details and is, therefore, most like the current RTL flows.

Embedded-based design tools come at things with much more of a systems view, offering more emphasis on the software part of the design. The hardware portions are assumed to be a known collection of standard function blocks, while the principle differentiation in the system is in the software.

A component-based design style looks at a design as the assembly of building blocks, not dissimilar to an SoC style of design, but less dependent on a standard mix of function blocks. This component-based approach is closer to the assembly of systems as collections of discrete components and interchangeable boards in the system.

Maintaining the legacy

Gary Smith, chief analyst at Dataquest, notes there still is gate-level design going one today. The new ESL flows sit on top of these legacy flows, but they never replace them. Instead, RTL is becoming the new back end, or at least a portion of it. The idea being that back end is implementation, and front end is design. So, what you’re seeing is in fact design moving to the next level of abstraction. It’ll take a while, though, because the move to ESL is being driven by verification at this time.

Some tool suppliers disagree with Smith on this issue. Drew Wingard, CTO of Sonics, Inc (Mountain View, CA) point out that ESL is not about an entry language, but a new methodology. Wingard says, “There is a chasm between the entry point at the HDL and the system architect. There is no way to cross the barrier. The chasm is also part of the organization, as well as the design types. Design teams need an executable model to bridge the system architect and the implementation people.�

Mark Milligan, vice president of marketing at CoWare, Inc. (San Jose, CA) maintains that ESL represents a change in the flow for design. Milligan says, “At the ESL, design will be new and revolutionary with the requirement that the outputs from the new tools and flows somehow be transferred to the implementation facets that exist today. There is a real need to connect the design and implementation functions through a verification process, so the designer and the CAD people don’t have to re-enter or recreate the ESL design.�

Meanwhile, Simon Napper, CEO of Synfora, Inc. (Mountain View, CA) describes ESL as a way to mask the details of a design, and also to increase the level of automation. ESL needs to be a methodology that goes from top to bottom, according to Napper, not an add-on to the existing RTL flow. It’s a methodology shift as well as a way to abstract the details away from the designer, he says. The tools have to create a “correct by design/construction� implementation flow all the way from entry to GDS-II

A picture is worth at least a thousand words

In the business data arena, companies are starting to use graphical visualization tools to understand the myriad data associated with their business. These tools take the equivalent of multiple spreadsheets and construct images that link various parameters for evaluation and review, thus providing intelligence to the datasets.

However, the amount of data most businesses are evaluating in this process is considerably less than that required for even a small design, one with just a few million gates. Clearly, the data volume and complexity of a large IC design far outweigh the capabilities of any business analysis tools. Nevertheless, the idea persists that people are starting to view the interrelations between datasets as linked graphics, allowing the users to use millions of years of human evolution to take advantage of our distinctly visual-centric natures.

In a similar vein, the software world has transformed from bit- and byte-level machine code, to assembly languages, to interpreted languages, to compiled languages, and now to object-oriented languages. They changed from 1’s and 0’s, to words, and then to pictures. These changes in the design paradigm have resulted in a higher quality and greater reuse in the software development world. Again, the changes are towards graphics and images, rather than words or numbers.

The electronics design community has always been raising the level of abstraction. Design capture started at polygons (rubylith), moved to schematics, then to gates, and now to functions. In contrast to other industries, IC designers started with, and continue to use Spice-generated netlists. As the technology evolved, designers were given access to integrated schematic capture and simulation tools. Now they’re using HDLs for the bulk of their designs. And, as much as engineers claim they only design in HDLs, most still use the hierarchy browsers, waveform displays, and other graphics tools for their debug and analysis. Even today, engineers go to a whiteboard and start drawing pictures to describe the functionality or the problem when discussing a part of a design.

Again, the reliance is on graphics to comprehend the higher complexity. Increasing the level of abstraction should lead towards more graphical representations of the design.

Meanwhile, it appears that some variant of C is likely to be the language of choice for ESL - whether it’s SystemC, however, remains to be seen. The value of SystemC is in its fairly high compatibility with the software design flow, although the language is not the optimal choice for every type of design. Hence, the design community is still in need of a standard language for widespread use.

Although SystemVerilog is admired by many, and is appropriate in many situations because it’s synergistic with C for many tasks, SystemVerilog is not going to be the language of choice for ESL. SystemVerilog has a hard time with the mixed hardware-software simulation and that’s a problem.

Restraints and constraints

ESL can be seen as a way to use an entry language similar to the way XML allows a user to burrow deeper into the data on a website to get to the appropriate levels of details. The hyperlink to the more detailed data allows the prevailing level to display only the content of relevance to the current project activity. This helps the designer work with much less data and visual detail at any particular moment in time.

At the same time, the ESL tools need to address software as a part of the design, as well as the capability to perform architectural exploration and hardware/software profiling to optimize the overall system. Power consumption, a growing concern in all systems, is related to both the hardware architecture and the way that the software is coded. The tools, therefore, need to identify those areas that consume the most energy in performing their functions. At the ESL, designers will need to check both the compiler and architecture to evaluate the effects of the number of processor and co-processors to fit the market requirements.

The lack of appropriate models may be one of the key roadblocks, after designer inertia, to more widespread use of ESL tools. Clearly, ESL is definitely going to require access to models with more views. Today, those models don’t really exist, so designers have to create their own, appropriate views, or resort to starting their designs from scratch. At the same time, designer should be looking for an executable model. The block functions and the interactions are the primary areas of concern at this level, so the tools have to serve as a bridge between the system architect and the circuit designers. On top of that, the tools also need to provide capabilities for platform verification in the desired configuration.

ESL needs high quality IP. That quality is a function of the number of different types of designs that can use the design block. Historically, the lack of a standard library for C++ has meant that there was no common denominator for EDA companies to work to. SystemC solves many of the C++ library issues by defining a set of class libraries. This set of class libraries is necessary, but not sufficient for ESL adoption. Design kits for classes of applications would include more high-level models to be a partial bridge between ESL and RTL

IP needs to have views that encompass system and block levels as well as the current RTL and physical views. As mentioned earlier, design trends are towards more visual elements such as block diagrams. One problem with this approach, however, is that designers spend too much time trying to make the pictures pretty. Still, their ability to describe a hierarchy is far greater working in a visual mode than in other modes. A black-box view of a function is all that’s really necessary at the system level. Object-oriented flows allow the analysis of performance, and also provides a deep sub-micron perspective. The multitude of multi-clock paths requires a good floorplan at the block level to address physical implementation issues at the design level.

Dealing with change

Marco Roodzant, vice president of marketing, ACE Associated Compiler Experts bv (Amsterdam, the Netherlands) says architectural generation languages are coming. These languages will combine hardware and software attributes. They’ll run C on processors and measure performance for system functions, not just the hardware specifications. Roodzant says this change will open the need for compiler generators at the exploration stage of the architecture, so the system architect can evaluate not only hardware partitioning, but also hardware and software partitions.

Kevin Kranen, director of strategic programs at Synopsys, Inc. (Mountain View, CA) proposes that at the ESL, the focus is on getting the algorithms and architectures working. At this level, the risk of failure is very low, according to Kranen, since no one will get to sign-off from an ESL design file. At levels closer to the implementation, the designers have much higher risk of failure, if their conversion flow doesn’t converge on a design.

Meanwhile, CoWare’s Milligan suggests that ESL enables and requires IP reuse. Increased IP use is supposed to help in system comprehension, he says. However, the notion of IP reuse at the ESL requires a fundamental shift in focus. The verification processes need to change to address the ultimate goal, which is to have the software running on custom hardware. He adds that current methodologies are too focused on the gates and timing issues, to the detriment of the total system performance.

The change to ESL creates new design gaps, due to the specialized nature of the final systems. Uniformity enables increased automation.

For example, when companies changed their design paradigm from transistors to gates, but didn’t define structural limits on the gates, the designers just went back to the transistor-level design and made modifications accordingly. The EDA companies couldn’t handle the lack of homogeneity. However, when companies restricted gate configurations, the EDA companies provided commercial tools for design implementation. Similarly, test is not improved by simply adding scan to the design. For improved testing, designers have to follow scan-based testing design rules.

To make ESL more viable, EDA companies have to create application-specific tools. Traditional tools like Spice and Design Compiler, or any of the RTL flows, are application agnostic. All design types can use the same tools.

At the ESL, tools have to be application specific to be of any value. This situation creates an ROI challenge, since any single application-specific target market is probably too small for sufficient tool volume at this juncture to justify the R&D costs. And too, the general fragmentation of design areas means that few, if any, applications are large enough or have enough common elements to justify new tools.

Automation and platforms

Finally, there’s the ultimate showstopper. Higher levels of abstraction don’t address the growing verification problems. Without a complete change in methodologies and technologies for verification, the design-to-verification effort ratio will grow to something in the neighborhood of 1:50. In addition, the verification cycle will grow to exceed man-centuries of time. This is not an acceptable situation in anybody’s book.

If higher levels of abstraction also imply a higher level of automation for design, then the tool sets must automatically generate many of the inter-block interfaces and optimize the areas of the design that affect the system throughput the most. Since communications between blocks is the primary function of design at the ESL, communication optimization is one more critical function that must be included with the tools.

In addition, the higher level of automation can address other areas such as test and layout congestion by preventing the implementation of functions that are inherently hard to test, or hard to use in a physical design.

By using automatically optimized communication structures and well-characterized and well-modeled IP blocks, the designer reduces the amount of design and, assuming the interfaces are correct by design and construction, reduces the amount of verification as well. Taken together - abstraction at the design-entry level and acceptance of functionally correct interfaces optimized for the communications latency and bandwidth needed for full system performance - these features should improve much of the “back-end� processes. If the interface generator also outputs synthesis scripts and layout constraints, then the tool itself will be the bridge between ESL and the RTL implementation flows.

The new generation of structured ASICs and platform-based ICs fit well into this model of higher levels of verification abstraction and communication interface optimization. At the highly integrated end, platforms include one or more processors, some memory, and a selection of peripherals directed towards specific applications. At the lower end, the structured ASICs provide a sea of function primitives, larger than gates and registers, which constitute building blocks used to create higher-level functions. Certainly, the high-end ICs map well into the ESL, while the primitives are at the lowest level of visualization desired.

Another language war?

Importantly, the concept of ESL as a design methodology fails to address the specifics of language for entry. Some would propose one of the many variants of C to handle the task, where others think that a domain-specific language and tool set are required. As noted earlier, the markets are already fragmenting and the application-specific nature of systems are requiring at least some application-specific tools. So far, most of the application-specific tools are focused on communications systems.

The candidates for design entry include such non-EDA tools such as Matlab from Mathworks (Natick, MA), which uses a base-calculating engine and application-specific toolset. This approach allows application-specific functions to be isolated from the rest of the tool, and allows third-party developers the opportunity to sell products with domain-specific characteristics for a smaller design niche.

Although it’s important for the entry language to interface easily with C and the C variants that software developers are using today, the entry language also needs to address the transformation into silicon. So far, however, no complete flow from entry to manufacturing exists.

Clearly in the short term, the gap in layers of abstraction to the existing RTL has to be bridged, whether it be through a manual or an automated translation processes. The manual methods are error prone and subject to personal interpretation, while the tools are not yet considered robust enough for production work. When you consider the wide range of possible input languages, the task of creating a universal input to RTL translator is a Sisyphean task.

The story of the move to ESL is still unfolding. Many chapters remain to be written before we can look back and say, “Those were the right choices. Those were the wrong ones.� A lot discussion and evaluation - and a plethora of technical initiatives - will have to come and go before today’s observers can be anointed as the true prophets of tomorrow.

Company	Location	Design style	Design Language	Capabilities	URL
ACE Associated Compiler Experts bv	Amsterdam, The Netherlands	Embedded	C/C++	Compiler generators & testing tools for compilers	www.ace.nl
Aldec, Inc.	Henderson, NV	SoC	C/C++, Handel-C, Verilog, VHDL	ASIC & high-density FPGA verification environment	www.aldec.com
Alternative System Concepts, Inc.	Windham, NH	Embedded	XML, Verilog, VHDL	Behavioral synthesis software tool to reduce power consumption	www.ascinc.com
Altera Corp.	San Jose, CA	Embedded	C, MATLAB, proprietary	Automates adding, parameterizing, & linking embedded processors, co-processors, peripherals, memories, user-defined logic for system-on-a-programmable-chip	www.altera.com
Ansoft Corp.	Pittsburgh, PA	Component	VHDL-AMS	Mixed-technology designs prevalent in automotive industry	www.ansoft.com
Axis Systems Corp. (now part of Verisity Design, Inc.)	Mountain View, CA	Co-verification	C, Verilog, VHDL	In-circuit emulation, hardware/software co-verification	www.axiscorp.com
AXYS Design Automation, Inc.	Irvine, CA	SoC	C/C++	Modeling and verification of multi-core SoC, libraries, software generation tools	www.axysdesign.com
Cadence Design Systems, Inc.	San Jose, CA	Behavioral		Transaction-level model development & verification, algorithm development	www.cadence.com
Company	Location	Design Style	Design Language	Capabilities	URl
CARDtools Systems	San Jose, CA	SoC, embedded	C/C++	Modeling hardware, software, & systems at different levels of abstraction	www.cardtools.com
Celoxica, Inc.	Oxfordshire, U.K.	Embedded	C/C++	Software-compiled system design, co-design and co-verification tool for systems development, partitioning, & simulation	www.celoxica.com
CoFluent Design	Nantes Cedex, France	SoC, embedded	C++	Requirements definition, system specification, functional design, architectural design, prototyping	www.cofluentdesign.com
CoWare Inc.	San Jose, CA	SoC, embedded	SystemC, C	Design, verification, embedded processor design, signal processing, models	www.coware.com
CriticalBlue	Edinburgh, U.K.	Embedded	C/C++	Co-processor synthesis tool for accelerating software in embedded microprocessors	www.criticalblue.com
eASIC Corp.	San Jose, CA	SoC	C/C++	Hardware/software interface generation, multi-protocol verification testbench environment	www.easic.com
EDAptive Computing, Inc.	Dayton, OH	Behavioral	VHDL, Rosetta	Specification, implementation acceleration, verification, & design team collaboration	www.edaptive.com
Esterel Technologies	Mountain View, CA	SoC	Proprietary	Hardware & software, automated test & verification capabilities, formal verification at specification level, automatically generates full state coverage test suites	www.esterel-technologies.com
Expressive Systems Inc.	Bucks, U.K.	SoC	Verilog, VHDL	Graphical hierarchy browser	www.expressivesystems.com
Forte Design Systems	San Jose, CA	SoC	C++	Architectural exploration, models & verifies functionality, verifies candidate RTL with testbench used to validate high-level model	www.forteds.com
Future Design Automation Corp.	Tokyo, Japan	SoC, FPGA	C/C++	Hardware & system compiler, architectural synthesis	www.future-da.com
Giga Scale IC, Inc.	Cupertino, CA	SoC	Verilog, VHDL, proprietary	Virtual prototype tool for estimation of chip size, power, timing, cost, yield	www.gigaic.com
Mathworks, Inc.	Natick, MA	Behavioral	C/C++, proprietary	Data analysis, visualization, application development, simulation, design, code generation.	www.mathworks.com
Mentor Graphics Corp.	Wilsonville, OR	Embedded	Spice, VHDL-AMS, C, IBIS	Math-based computer-aided prototyping, uses industry standard models	www.mentor.com
MLDesign Technologies, Inc.	Palo Alto, CA	Behavioral	C++, proprietary	Models and analyzes architecture, function & performance of high-level system designs	www.mldesigner.com
Novas Software, Inc.	San Jose, CA	SoC	Verilog, VHDL, SystemVerilog	Transforms and automates debug process	www.novas.com
Novilit Inc.	Marlborough, MA	DSL	Proprietary	Automatically generates portable protocol stack and delivers output code in various languages	www.novilit.com
Poseidon Design Systems, Inc.	Atlanta, GA	SoC, embedded	SystemC, proprietary	Analyzes performance of embedded system, software & hardware performance	www.poseidon-systems.com
Sonics, Inc.	Mountain View, CA	SoC	Open Core Protocol (OCP)	Graphical and command-line based tools, utilities to assemble, configure, generate netlists in SoC	www.sonicsinc.com
Spiratech, Ltd.	Manchester, U.K.	Embedded	SystemC, C++	Captures and visualizes activity at transaction level, relates activity to individual wires/signals in RTL environment	www.spiratech.com
Summit Design, Inc.	Burlington, MA	Behavioral	C/C++, SystemC, Verilog, VHDL	Design, creation, analysis, verification, and management of complex electronic systems & IP	www.sd.com
Synfora, Inc.	Mountain View, CA	SoC	C/C++	Automatically generates architectures & synthesizable RTL from ANSI C algorithms	www.synfora.com
Synopsys, Inc.	Mountain View, CA	SoC	SystemC, MATLAB	Data-flow simulator with finite state machine modeling & SystemC compliant engine for transaction level modeling	www.synopsys.com
Target Compiler Technologies n.v.	Leuven, Belgium	Embedded	C/C++	Tools accelerate development, programming, & verification of IP cores	www.retarget.com
TNI-Valiosys	Chicago, IL	Embedded	Smalltalk, Java, C/C++	Tools build system-level models & facilitate implementation in real-time apps	www.tni-valiosys.com
VaST Systems Technology Corp.	Sunnyvale, CA	Embedded	C/C++, Verilog, VHDL	Specify, architect, design virtual prototypes for hw/sw systems in SoC, ASIC, PCB designs	www.vastsystems.com
Verisity, Inc.	Mountain View, CA	All	e, Verilog, VHDL	Identifies flaws in design with automation technology, analyses, libraries	www.verisity.com
Wind River Systems, Inc.	Alameda, CA	Embedded	OS (DSP specific)	Muticore embedded systems with combinations of RISCs/CISCs, DSPs, FPGAs	www.windriver.com