The tool category known as “Kitchen Appliances” covers a wide gamut of capabilities. Kitchen appliances range from general-purpose, universally useful tools such as heat sources, to highly specialized, perhaps less-than-indispensable technologies like “in-the-egg scramblers”. If someone tells you that his or her tool is a kitchen appliance, you haven’t really gained any useful information about its utility for your particular application.
The design tool category known as “ESL” has similar characteristics. When someone tries to sell you an ESL tool, it’s never quite clear what you’re getting. Will this thing revolutionize my design process, fix me coffee in the morning, or drag like dirty weighted chains across the deck of my design team’s ship until we figure out that we were more productive the old-fashioned way and throw it overboard?
For over a decade, ESL has been the leftover, catch-all category for electronic design automation (EDA). Even the abbreviation itself is malformed – “Electronic System Level” …electronic-system-level what? It’s a dangling modifier with no object. Peel away the party hat and plastic Groucho Marx glasses and we find our tattered and tarnished old friend “ESDA” (Electronic System Design Automation – at least it was a complete acronym). About ten years ago, ESDA got a bad reputation for being ambiguous and useless, so marketing mavens deep inside the EDA dungeons dressed it up, slipped on a cheap disguise, and “ESL” was born.
Before we can agree on a definition of “system-level design” we need to agree on what we mean by “system.” A colleague of mine used to say, “A system is the thing one level more complicated than what we can understand.” If this is true, and if most hardware engineers understand design at the register transfer level (RTL), then ESL must be anything that works above the register transfer level of abstraction. Unfortunately, as we go farther from gates and closer to the behavior of our application itself, our tool requirements become paradoxically both more general and more specific. In our kitchen appliance analogy – at the cooking level, almost everyone needs a device that will heat their food, but the pastry chef requires a completely different arsenal of specialized preparation devices than, say, a master meat roaster.
On the general-purpose side, probably the most widely used ESL tools today are things like Matlab, Microsoft Excel, Visual Studio, and the ubiquitous back of a napkin. If we look at the more specialized side of the equation, we get everything from state machine bubble editors to HDL configuration management, to sophisticated high-level (don’t dare say “behavioral”) synthesis tools. Any electronic design tool that isn’t in one of the accepted universal design flows, from RTL simulation and synthesis through place-and-route and layout verification, or schematic capture and signal integrity analysis through board layout and computer-aided manufacturing, gets tossed mercilessly into the ESL ocean to sink or swim on its own ill-defined merits.
For companies marketing ESL tools, the problem goes far deeper than ambiguity. In the ASIC world, as a tool gets farther from silicon implementation, the chance that it can either cause or prevent the dreaded re-spin drops dramatically. Since the value of ASIC tools is traditionally driven by designer re-spinophobia (fear of career-limiting ASIC re-spins,) anything you can’t connect to a re-spin automatically takes a two-order-of-magnitude price drop. Combine this with the fact that most electronics companies have a large number of “engineers” but only a handful of “system designers” and you end up trying to sell a low-priced tool to a tiny audience. It’s not an easy audience, either. System designers aren’t as practical and task-oriented as normal engineers. They sit in their ivory cubicles, wearing their long, flowing robes, and meditate for days before modifying the single Matlab coefficient that moves the burden of base-station equalization between boxes on a wireless tower.
In an effort to win us over on the wonders of their wares, ESL marketers unfortunately resort to the usual tired, dogmatic doctrines of EDA marketing: “Today’s more complex designs have pushed methodologies to the breaking point. In order to complete your [insert this year’s number of gates] design on frightening [insert this year’s process node] technology, you’re going to require [insert the name of our new ESL tool] to succeed!” This MadLib marketing method has been dusted off and recycled every time EDA has introduced a new product for the past twenty years.
So, what does the average design team need to know about ESL? Because of the breadth and ambiguity of the category, you can’t get much information from the classification itself. Like any other type of tool, you really just need to know what your team needs to suit their design style. For example, if your team is just designing FPGAs or ASICs, and your methodology is to manually write hardware description language (HDL) descriptions at the register-transfer level, your design style actually most resembles a software development process. A number of “ESL” tools are available that can help you visualize your HDL code as block-diagrams, state transition diagrams, truth tables, etc. These tools also either provide or interface with configuration management facilities for check-in, check-out and associated team-engineering functions. Even if your team is made up of die-hard vi addicts, the visualization capabilities can help decode foreign IP and legacy code, and it also facilitates documentation.
Another category of ESL tools is designed to help the “system designer” at the very early stages of the design of embedded systems. At this point, functionality is being partitioned between hardware and software, and ESL tools help evaluate the efficacy of that partitioning. The most effective tools in this space are possibly FPGAs themselves, as they offer the opportunity for repeated, iterative evaluation of various partitioning options. Drop an embedded processor in (or next to) an FPGA, and you can reasonably try out various partitioning options without having to pull the trigger on an ASIC spin.
Celoxica has pre-packaged this complete process with development tools and matched prototyping boards. Their C synthesis tools are designed to speed up the C-software to the hardware accelerator phase of the process, and their tight integration with their development boards minimizes the ramp-up time for a team on a schedule. Celoxica’s environment comes both in their traditional “Handel-C” flavor as well as a newer “SystemC” variety that appears well suited for ASIC teams using SystemC for mixed-level, transaction-based simulation and verification.
Also competing in the embedded HW/SW space is newcomer Poseidon Design Systems with their Triton Builder and Tuner products for analysis, synthesis, and co-simulation of C-based designs targeting embedded processors with hardware acceleration. Impulse Accelerated Technologies takes a similar approach with their Impluse-C products, which are targeted at design teams looking for a low-cost solution for C-algorithm acceleration in hardware.
Also counted in the ESL space are high-level synthesis tools targeting DSP algorithms such as AccelChip’s AccelChip DSP Synthesis. AccelChip’s synthesis tool takes Mathworks’s M language direct from MatLab and synthesizes directly to hardware implementations for FPGA or ASIC.
Mentor Graphics’s Catapult C spans a number of these categories with direct synthesis of ANSI-C combined with System C integration for system-level verification. Unique to Mentor’s tool is its interface synthesis capability, which automates the creation of hardware interfaces to synthesized modules and verifies that the architecture created matches the bandwidth capabilities of the interface design.
While many of these tools are doing some form of synthesis from a high-level language (like C) to RTL or gate-level hardware, there are striking differences in the target user and design style for each tool. If you think your team may benefit from one, look at other early adopters of the technology you’re considering and see if their design style is similar to yours. High-level synthesis (also called algorithmic synthesis, behavioral synthesis, and architectural synthesis) is still an evolving technology. While researchers have been doing projects and papers for years, and the first commercial products were introduced more than a decade ago, widespread commercial adoption is just beginning now.
If ESL has a lucrative future, it is probably in these high-level tools. While they’re clearly still in the early-adopter part of their lifecycle, high-level tools promise significant productivity improvement for the design of complex systems. If you want to keep your own personal scorecard on high-level design, think in two axes – productivity and performance. If you’re taking a piece of software and hoping to synthesize it to hardware for acceleration, you’d like the productivity you realize using the tool to be better than manually designing the hardware implementation from scratch.
Instead of a scale from one to ten, I rank productivity on a scale from “hardware” to “software.” A ranking of “hardware” would be the worst, meaning that the tool gave no productivity advantage over full-manual hardware design. A ranking of “software” would be the best, meaning the tool gave productivity equivalent to compilation of the pure software implementation.
Conversely, performance can be ranked from “software” to “hardware.” A “software” rating would be the worst, meaning the hardware implementation generated by the tool gave no performance advantage over a software implementation, and a “hardware” rating would be the best, indicating that the generated hardware performed as well as a custom-designed, optimized hardware module.
What we want, then, is a tool set that can give us hardware performance with software productivity – something that will allow a hardware designer to accomplish their design objectives with the ease of software programming, or allow a software programmer to create custom hardware as easily as compiling a program. Once that goal is approached, hardware design as we know it will change forever, much as software development changed with the advent of high-level languages, or hardware development with the introduction of HDL synthesis.
When that day arrives, will we still call these tools ESL? Probably not. Even today, high-level synthesis tools predominantly help us with design at the module level. The domain of the “system” remains unaddressed. Once it becomes mature and accepted, algorithmic synthesis will rate a category of its own, and ESL will remain the unfulfilled dream of the EDA industry – mythological marvel-ware ready to create complete working systems from nothing more than a hand-written list of features. We engineers will be able to rattle off some snazzy combination of capabilities before our morning coffee breaks, hit our big green “ESL” buttons, and be done with our work in time for a round of golf after lunch. Until then, we can only dream.
