ESL Defination

What is ESL? The term ESL is an abbreviation of Electronic System Level. Gartner Dataquest defines the term as the utilization of appropriate abstractions in order to increase comprehension about a system, and to enhance the probability of a successful implementation of functionality in a cost-effective manner. This indicates that an ESL methodology should have the following properties:

• The methodology should abstract away the finer details of the design and provide a system level view of the design
• The methodology should enhance the probability of successful implementation of the design
• The methodology should be cost effective.

Having defined the requirements of an ESL Methodology let us try to understand the details of our definition

Levels of abstraction

The Digital design Industry has been going through a series of abstraction stages since its inception these abstractions are enumerated as below

• Design using individual silicon layers
• Transistor level design
• Gate level design
• Schematic level design
• Component level design
• RTL Design
• SOC's (Another form of component level design where each component is a mega component)

Each level of abstraction has reduced the design representation by 10X to 100X

To understand the Abstractions better consider the implementation of an N tap filter.

• Initially we had a full custom implementation of the design. This was done by individually designing each mask layer extracting the spice model simulating it to ensure proper behavior.
• The first level of abstraction was to move to standard gates both for the implementation and the design of the circuit. Here the design stage involved selecting the individual gates to form the respective adders and multipliers and connecting them. This activity could be either through a schematic capture tool or using an HDL to instantiate and connect the corresponding gates. Here a simple instantiation of an and gate abstracted away the design of 10-20 mask layers for that gate
• The next level of abstraction abstracted the individual adders and multipliers. Now the designer selected and instantiated the required adders and multipliers from a standard library. So now instead of instantiating tens of gates to build our adder we instantiate a single component which is our adder.
• This was followed by the RTL phase where we now write y=a*x+b*y and depend on the backend flow to ensure that this translates to the correct set of gates.
• The next stage of progression is to have a parametrizable set of functions (e.g. filters, arbiters, DMA's etc.) and build the design using these set of components. We already do this today with a varying amount of success in our SOC flows where we instantiate and connect standard components.

So what is the next level of abstraction that we need to go to? What are the new heights that we need to scale?

The next level of abstraction in SOC design

To get an indication of what can be our next level of abstraction Let us start with our Product requirement document. For an SOC that will go in your mobile phone this document can specify something as follows:

• The device shall support GSM, WIFi, Bluetooth and GPS.
• The device shall not consume more than X amount of power.
• The four functions above will operate in the following modes

Can we now have a tool which will determine the internal data bus width, Hierarchy of each of these modules, The interconnect system to be used, Which implementation of the above functions should be used etc. etc. etc. Such a tool in true sense will be the next ESL tool

How does the arrival of the next level affect the current level of design?

Traditionally the arrival of the next level has not affected the previous level much.

Even today we have large teams of engineers who are designing the standard cells for the next technology node. The difference that has come into picture is that instead of each company employing a team of engineers to design the basic gates we have a set of foundries invested in this task where as the newcommers have decided to go fabless.

Similarly we will have a set of companies which are pure IP players these companies will design and maintain a huge library of parametrizable custom IP's. Thes libraries will have variations of the IP for different operating frequencies, Different power performance ratios etc. On the other hand we would have the IPless companies which will license the libraries and integrate the required components in their SOC's and then hand them over to the foundries for manufacturing.

Considering our example in the previous section, There are numerous implementations for 802.11? protocol set. These implementations will not have a standard interface. e.g. some may be slave only devices depending on an external DMA to feed in and remove data from its buffers, some will have different protocols at the bus interface etc. If a tool needs to select between all the options having different area, power and performance parameters then these implementations should conform to a standard set of guidelines. Similar to what we have with standard ASIC cells today

What are the ESL Tools currently available

• Synfora PICO Express and Extreme
• ChipVision PowerOpt
• NEC CyberWorkBench
• AutoESL AutoPilot
• Xilinx AccelDSP and SystemGenerator
• Esterel EDA Technologies Esterel Studio
• Synopsys
• Synplicity Synplify DSP
• Cadence C-to-Silicon (C2S) compiler
• Mentor Handel-C synthesis (formerly Agility Design Solutions)
• Simulink, Mathworks
• Bluespec System Verilog
• Mentor Catapult C