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 the following properties that an ESL methodology should have
Having defined the requirements of an ESL Methodology let us try to understand the details of our definition
The Digital design Industry has been going through a series of abstraction stages since its inception these abstractions are enumerated as below
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.
So what is the next level of abstraction that we need to go to? What are the new heights that we need to scale?
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….
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 e used etc. etc. etc. Such a tool in true sense will be the next ESL tool
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
| Company | Tool | Language | USP | Documentation |
|---|---|---|---|---|
| Bluespec | Bluespec compiler, Simulator | Bluespec System Verilog | Syntax similar to verilog/System Verilog, Correct by construction, atomic actions, Rich IP Library, Functional programming concepts, Free for academic | |
| Mentor | Catapult C Synthesis | ANSI C++ | Automated Systemc testbench generation, Based on C++, supports both control and data path, 200+ ASIC Tapeouts |
- Forte Cynthesizer
After the advent of VHDL, Verilog and its synthesizable subset, there has been multiple efforts to either improve on the synthesizable subset or introduce a new language which works at an higher level of abstraction. This section lists a few of them.
| Vendor | Methodology | USP | Results |
|---|---|---|---|
| Synopsys | Behavioral Compiler | Synopsys's markating muscle resulted in everyone who was someone evaluating it at some time or the other. But Users were not willing to sacrifice QOR for faster implementation compared to handcoded RTL 1) | |
| Superlog | Based on Verilog | ||
| SpecC |