ESL: Reality, Or A Pigment Of Your Fig Neuton?

Or alternatively, who’s doing what to whom?


By Clive “Max” Maxfield

One of the questions I am often asked is: “Who’s really using ESL tools such as modeling and are there any hiccups in the flow?” Another common question is: “What actually is ESL?” Perhaps we should address the latter question first.

To some folks, ESL (electronic system level) means designing at a very high level of abstraction prior to making any hardware-software portioning decisions. By comparison, other folks would say that ESL refers to hardware/software co-design. Still others would say that ESL refers to anything that’s at a higher level of abstraction than register transfer level (RTL) representations. And, of course, we should note that ESL does not necessarily imply a design tool, because some verification applications might fall into the ESL domain.

One very useful book I have on my shelves is ESL Design and Verification (ISBN: 0-12-373551-3) by Brian Bailey, Grant Martin, and Andrew Piziali. Chapter 2 presents a Model Taxonomy (Temporal Axis, Data Axis, Functionality Axis, Structural Axis) and an ESL Taxonomy (Concurrency, Communication, Configurability). Personally, I found this chapter to be worth the price of the book alone, but we digress.

As Justice Potter Stewart wrote in Jacobellis v. Ohio (1964): “I can’t define pornography, but I know it when I see it.” This is the way I tend to approach ESL. On this basis, let’s ponder some of the different flavors of ESL that are out there.

In some cases ESL is not new. In fact, in some domains it’s a saturated market. For example, digital signal processing (DSP) tools have long been available to allow you to describe what you wish to do algorithmically and to then generate C code to be run on a processor. A newer segment of this is what is now being referred to as High Level Synthesis (HLS). Tools that fall into this category are CatapultC from Mentor, AutoPilot from Auto ESL, C-to-Silicon Compiler from Cadence, Cynthesizer from Forte, CoDeveloper from Impulse Accelerated Technologies, and PICO from Synfora.

Most of HSL tools of this class use C/C++/SystemC as a starting point, but we should also include Bluespec in this category, because although they go about things in a completely different way, at the end of the day they are still taking a high-level description and using it to generate implementation-level RTL. (Actually, C-to-Silicon from Cadence can synthesize a gate-level netlist, but let’s not wander off into the weeds.)

The great thing about ESL is its diversity. A classic example of this would be the folks at Tensilica with their Xtensa Customizable Processors, which may be considered a completely different ball game. In this case, we’re talking about a tool that analyzes your C code and then presents you with a selection of custom processor architectures that are extremely efficient with regard to executing a certain algorithm or class of algorithms. Once you’ve selected the architecture that best meets your requirements, Xtensa generates the RTL for the processor along with a corresponding tool chain.

Another ESL “arena” involves chips that feature arrays of processors. In this case I’m thinking of such beasts at the Arrix family of Field Programmable Object Arrays (FPOAs) from MathStar or the Massively Parallel Processor Array (MPPA) from Ambric. Both of these companies are sadly no more, but I think we’re certain to see more things like this appearing on the market in the not-so-distant future, such as the Elemental Computing Arrays (ECAs) from Element CXI. The reason I believe these components fall into the ESL domain is when we come to consider the tools used to map applications onto these platforms.

And then we have the concept of the Virtual Platforms (VPs) that are used for architectural exploration and design verification. We immediately have to split these into two distinct groups. First we have VPs that are intended primarily for software development and verification. These are very, very fast and are functionally accurate, but they have little if any timing accuracy. They also have limited visibility into what’s “happening inside” (for example, you may be able to access cache statistics but not bus statistics). Some example of this class are Innovator from Synopsys, Virtual Platform from CoWare, and Simics from Virtutech.

Another class of VPs are targeted toward architectural analysis. These are somewhat slower than “pure” VPs but provide a higher level of hardware timing fidelity (we might class these as “functional accurate / timing approximate”). In this case we have better visibility into the hardware in terms of what’s happening on the busses and arbitration and so forth. Examples of this class are Vista Architect from Mentor, the CHIPit Automated Rapid Prototyping System from Synopsys and Platform Architect from CoWare

But what about the various flavors of Formal Verification? Do they fall into the ESL domain? Actually, I would tend to say no. This is because one definition of ESL would be a representation in which clocks don’t exist. To put this another way, clocks are a manifestation of an implementation, and when you’ve reached an implementation you are no longer in the ESL domain. Of course there’s always an exception to every rule and, in this case, I would class the SLEC Sequential Analysis Technology from Calypto as being an ESL tool.

As one industry expert said to me just a few days ago as I pen these words: “ESL is like a game of Connect-the-Dots – the problem is that although these days we have multitude of ‘dots’ in the form of valuable and rapidly maturing tools, we don’t have a lot of the required connections between them.”

Which, in closing, leads me to ponder MATLAB and Simulink from The Mathworks. These are amazingly useful tools when it comes to high-level algorithmic evaluations and what-if analysis. But they sort of live in their own little “bubble” because the C code they generate is not the C that you would want to put into an HLS flow and it typically is not efficient enough to be directly run on a DSP. Thus, these tools might be considered to be “dots” that are anxiously waiting for the appropriate connections. As fate would have it, this is something that might change in the not-so-distant future, but for the moment I am bound to secrecy…

Leave a Reply

(Note: This name will be displayed publicly)