No, in the parlance of the design-engineering community, ESL does not mean “English as a second language.” Rather, it refers to design activity at the electronic-system level, a way of defining SoC system architecture at a relatively high level of abstraction.
There are as many working definitions of the electronic-system level of abstraction as there are practitioners of the art. Most engineers would agree that what constitutes working at the ES level means any level of abstraction above the register-transfer level, or RTL. At RTL, which is typically expressed in hardware-description languages such as Verilog, SystemVerilog, or VHDL, system timing is rigidly specified. But the point of working at the ES level is to refrain from explicitly stating system timing.
So why work at the ES level if it’s so abstract? Because it’s the best level at which to create a behavioral description of the system and play “what-if” games with system partitioning (which parts will ultimately be implemented in hardware and which in software). At ESL, the relative absence of implementation detail enables simulations to run significantly faster than they would at RTL, enabling the design team to quickly evaluate a large number of implementation possibilities.
ESL frameworks center on transaction-level models (TLMs), which are typically written in the C/C++ language or, more recently, in SystemC. Under the SystemC TLM-2.0 standard completed by the Open SystemC Initiative in 2008, there are two broad classes of TLM interfaces: loosely-timed (LT) and approximately-timed (AT). The TLM-2.0 standard is what facilitates real-world interoperability between transaction-level models regardless of their origins. It’s aimed primarily at modeling of systems based on memory-mapped busses and on-chip communication networks.
Further, the ES level can, and should, be the realm in which software/hardware co-verification takes place. This is accomplished using virtual platforms, built up to the block, multi-block, or full-chip level. The virtual platform, comprised of some number of TLMs, is used by software development teams to verify the functional correctness of its OS, drivers, and communications protocols without having to wait for silicon prototypes of the final chip.
