Part of the  

Chip Design Magazine


About  |  Contact

Keeping the “E” in ESL

I was in Boston last week and I met with a few customers who shared information about their activities around ESL.  I’m always pleased to meet with customers who are already down the path of ESL. However, I’m often surprised to hear what constitutes ESL for them. In this case, the customer was creating very high level, conceptual models of a system, also known as model based design, to represent a wide range of engineering disciplines across the system (HW, SW, Thermal, Optical). I noted that the models had no representation of actual hardware, just functions in concept which may or may not ever be in actual hardware.

The next night, I was in Philadelphia, at a renowned cheesesteak sub shop, where I watched the Phillies clobber the Dodgers, all the while raising my cholesterol with a great sub. Earlier in the day, I met with another customer who said they were interested in applying ESL and were planning to start by creating UML models. In less than 24 hours, I had met with two customers with completely different concepts of ESL.  Interestingly, neither concept–the model-based design or the UML modeling activity–really fit within my definition of ESL. Specifically, both methodologies neglected the “E” in ESL.  The E in ESL implies electronic hardware and some representation of that implementation. 

While ESL is certainly a design representation above RTL, that doesn’t mean it encompasses every abstraction above RTL. ESL starts and stops within the abstraction of TLM (transaction level modeling), which includes some representation of hardware architecture.  While there are certainly benefits and good reasons to also do conceptual modeling, above ESL, lumping those methodologies into the  ESL bucket dilutes the space and risks confusion in the market.   ESL is a major step in hardware design methodology above RTL and a logical progression in hardware design methodology.  Given the long history of ESL, as we watch it come of age, it seems like a good idea to maintain clarity as to what is and is not within this design methodology.

24 Responses to “Keeping the “E” in ESL”

  1. Grant Martin Says:

    Glenn, this is an interesting point, but far too narrow a view of ESL. You should read the book I wrote with Brian Bailey and Andrew Piziali: ESL Design and Verification, Elsevier Morgan-Kaufmann 2007, (see URL for a wider view of ESL. While E in ESL means “Electronic”, the key is “ES” which means “Electronic System” – but this means a system incorporating significant design with and/or of electronic components – so a software based system with a lot of hardware-software tradeoffs, even if using all off the shelf components, still requires lots of “ESL” design and verification. Your definition of ESL as starting and stopping with TLM, and concentrating on hardware only, is one of the narrower definitions of ESL I have seen, and is not correct in light of ESL history nor the real focuses of real designers. In this case, your two customers were bang on in including model based design and UML as ESL related activities (see our book for good explanations of some of this wider scope). What Mentor is doing, for example, includes ESL synthesis and ESL platform modelling, but this is not the whole scope of ESL. For more on this, have a look at and

  2. Brian Bailey Says:

    Unsurprisingly, I concur with what Grant said. I would add a few more things. As we start to see multi-core be the norm for many systems, there are huge tradeoffs that have to be made in how functionality is distributed across a hardware platform. To make those tradeoffs, the tools have to have deep knowledge of the hardware, but are not about the design of the hardware themselves. Of course in other cases, they may also be trying to tune the parameters of a hardware platform for a particular type of software application. We can no longer think about hardware as a separate entity – it is part of the system, and we have to model the whole system in order to understand the dynamics of it. No longer can spreadsheets be used for this.
    The second point I would like to make regards verification. This has become a critical aspects of the design of systems. In order to accomplish this, we must have models that can run at high enough performance levels to verify the entire system – not just the hardware. This requires that many of the aspects of the hardware are abstracted away – and these are the same models that will probably be used to estimate the system performance, make the partitioning choices etc. Those early models – that are somewhat hardware agnostic are an essential element in an ESL flow. Without them, we are just doing bigger hardware design – and that is not the future – that is clinging on to the past.

  3. Walter Borntrager Says:

    And I always thought ESL meant equivalent series inductance…:)

  4. Simon Davidmann Says:

    And I always thought that ESL was about C based hardware deisgn and verification…

  5. Glenn Perry Says:

    Thanks very much for the feedback on my view of ESL boundaries. While there may be a valid debate as to whether or not TLM is an absolute boundary for ESL, I definitely don’t mean to suggest that ESL is HW *only* or that simulation performance can be neglected. ESL is about hardware and software; and TLM provides a clear level of abstraction for modeling above RTL, not unlike what RTL is to Gate. TLM enables designers to put ESL systems together, while leveraging best in class design approaches for the building blocks. To be clear, in my opinion, an ESL design representation must reflect the HW architecture in some form and provide the ability to “host” the SW. Indeed, the “system” is the combination. Without an architectural concept, there is no ability to perform the types of tradeoff or system level verification that are mentioned as key objectives in your comments. Higher level models that describe function without a concept of implementation (HW or SW), have an important role in the design flow, especially as a means of capturing the design intent or requirements. I just believe that this level of modeling is above the boundary of ESL. Without boundaries, everything above RTL becomes a candidate for being in the ESL bucket, which ultimately leads to such a broad range of methods in the bucket that no one really know what ESL means.

  6. RK Says:

    Interesting perspectives. I come from Embedded software domain and with a bit of exposure to the chip deign. As pointed out in above comments system is incomplete without software. The challenge now is to put a boundary to that software as to what constitutes system level software. Typically a hardware abstraction layer (HAL), and to be a bit more liberal, driver software can be classified as system level software. For the last two years as a company ( we have been trying to promote this concept. If one were to see the evolution of IP-XACT specifications specialised generators will be able to generate/automate activities involved in IC design, verification and software development. We already see that register map generation, document generation, verification test case generation and HAL generation are accomplished tasks by many companies. The next level challenge is to extend the specification concepts to other realm of system design.

    So limiting ESL with boundaries might defeat the purpose of raising design abstractions.

  7. Shashi Says:

    I think it would be good to distinguish between System Level Design (SLD ???) and Electronic System Level (ESL) Design. If we want to identify ESL to be all-encompassing term for different possbile abstractions and flows in an electronic system design then (I agree with Glenn that) we need to come up with a better terminology for addressing the space where UML, C/C++, MATLAB algorithmic modeling lie versus where SystemC/TLM like languages play. Any (Turing complete) language can be made to play a role at any abstraction level. We need to identify a clear distinction as to why Verilog/VHDL are associated with RTL/gate-level, why SystemC is associated with TLM/ESL and what is the purpose of MATLAB/UML/C/C++. One can write a TLM model for a DMA block along with an ARM and other peripherals in a SoC using SystemC assuming a certain bus architecture and one might write a C/C++/MATLAB architectural representation that has no knowledge of the bus it will reside on. They might be two different abstractions in ESL but the end customer has hard time to relate to what is meant by ESL.

    May be TLM is the term we are looking for that space right above RTL to depict transaction-based hardware/firmware and ESL has larger definition.

    There is another piece to this puzzle which is simulation domains – discrete-event (DE to represent digital hardware), cycle-based (synchronous DE), continuous time (used for analog), synchronous/asynchronous dataflow (which is effectively what happens when we use DE to do TLM). This has been discussed and addressed quite a bit in the context of heterogenous system modeling tools such as Ptolemy or Ptolemy II (UC Berkeley), Advanced Design System (Agilent Ptolemy), Simulink (Matlab), COSSAP SPW, etc.. I think ESL can span all of these simulation domains. I think Glenn wants to refocus ESL to address DE/TLM space for digital hardware. Good from the point of view of getting traction with customers and bad from academic scope point of view.

  8. Grant Martin Says:

    Shashi and RK raise several excellent points – in my view, and that of my co-authors and based on (perhaps too!) many years working in system level design (SLD) and ESL related areas, ESL has a broad scope rather than a narrow one, and the line to be drawn between it and SLD is still rather fuzzy. That is why my definition of ESL includes 5 major categories of activity:
    * Algorithmic design
    * Architectural design space exploration
    * Virtual prototypes for embedded software development/validation
    * Behavioural/high-level synthesis
    * Processor/Multi-processor-centric design
    and SLD includes more. I think the DE/TLM space that Shashi summarises maps into both the Architectural DSE and Virtual prototypes (aka Virtual platforms, etc. …… TLAs are both the bane of our existence and a shorthand to prevent us from being completely long winded!). SLD includes the wider scope of systems requirements capture, the capture and analysis of completely unpartitioned-unmapped functionality, system modelling aspects using tools such as Shashi mentions, etc …. but most of the SLD activities will bleed or blend across into ESL activities, across the fuzzy boundaries that separate them.
    For example, a communications algorithm and system environment model captured in Matlab may eventually become hardened target specific C code running on a configured processor and HW-SW system modelled using a virtual platform approach with a combination of automatic code generation and manual design methods, along with ESL synthesis for some bits of the algorithm that needs pure HW implementation. All of this might co-simulate with the original Matlab model! In this case, there are several “SLD” activities, and several “ESL” activities, but finding a hard and fast boundary line between all of them is rather difficult with our current state of development.

    By the way, this is shaping up to be a very interesting discussion. Thanks to Glenn for kicking it off!

  9. Taken for Granted » The debate over the definition of ESL continues Says:

    [...] debate and discussion going on at Glenn Perry’s blog on the definition of ESL – see “Keeping the “E” in ESL”.   I won’t try to hijack the debate here (a violation of “blogiquette” in my [...]

  10. JR on ESL, TLM and Register Map Modelling Says:

    I would argue that both UML and model-based design can and do fit within the scope of Electronic System Level design, which need not be constrained to a definition that “starts and stops within the abstraction of TLM”

    Consider this case: I want to design an electronic system for a well defined purpose; however, I am uncertain about the architecture and algorithm side of things and I want to make sure I get that right before writing any RTL or firmware. First, I do some object oriented analysis of the system and decompose it into classes and objects and their relationships. Some of these classes may model transactions but that’s just part of the equation. Before writing any C++ or SystemC code I use UML to formalize and communicate my model to others so they can critique and understand it. Then I pass the UML off to some modellers who will write the SystemC/C++ so we can simulate, analyze and optimize the system algorithm and architecture at an abstract level to make important decisions. Then, once i’m happy with the results of the model of the design we dive in and actually create the RTL and firmware to implement the system. Have I not just used UML and Model driven design to create an electronic system without sticking within the bounds of TLM? Is this not ESL? Maybe I take ESL too literally.

    For those who claim that object oriented, model based design and RTL don’t mix, I beg to differ. With the PDTi SpectaReg register management tool, developers specify register maps in terms of classes of addressable objects from which all other deliverables are auto-generated (RTL, firmware, documentation, verification). The UI abstracts the fact that it’s OO design and even model based design.

    Someone at a large FPGA company was convinced that SpectaReg, as I have just described, is not classified as ESL because it used a GUI rather than a language. [Well actually there is a language under the hood and you could use python and SPIRIT IP-XACT XML to specify rather than the GUI, but the GUI is easier.] “Our definition of ESL is that it has to be a language that is higher level than RTL…,” he said. To me a GUI is even more abstract than language…

    The E in ESL is for electronic so if you’re modeling any electronic system doing it at a higher level of abstraction than RTL, to me that is ESL. If ESL must be TLM, then why even call it ESL at all, why not just call it TLM?

  11. Jakob Engblom Says:

    > May be TLM is the term we are looking for that space right above RTL to depict transaction-based hardware/firmware and ESL has larger definition.

    Note that “TLM” is a huge span in and of itself.

    Some “TLM” systems are cycle-level detailed and accurate, and sometimes even cycle-driven (but using transactions to move data, such as the typical “cycle-accurate” simulations used in computer architecture research).

    At the other end of hte scale are completely untimed TLM models that are really just zero-time event-firing simulations.

    Then we have things like the classic software-oriented simulators like Simics, Qemu, CECsim, and various work reaching back to g88sim and even to the mid-1960s (… all of which have a strong system time concept but a pretty simplified view of component times. There things are some 10000x to 100000x faster than the cycle-accurate models…

    And then the dig-down-deep but not cycle-level SystemC stuff like TLM-2.0 AT which is pretty close to cycle-accurate in most ways, maybe a bit less precise and maybe an order of magnitude faster. I guess this is the “just above RTL” idea… but it is sometimes not clear that this is much ore than the hardware structure redescribed in C/C++.

  12. Jakob Engblom Says:

    Another aspect of ESL vs TLM and VP is the fundamental purpose:

    ESL is by name about system design — i.e., creating new systems, and working on them as early as possible with the most insight when there is maximum freedom to change things.

    TLM modeling and Virtual platforms are really about modeling — there is nothing here that says that you have to model NEW things… it is just as valuable many times to model existing hardware or even hardware that is decrepit and old.

    So maybe one important part defining ESL is that is about the work involved in creating new hardware-based system, and typically relating to the internals of a new chip. Grant Martin and others with a more academic inclination also wants to include the composition of systems from preexisting chips, but most of the EDA tools seem to focus on the insides of a single chip. But you could make a reasonable definition play that UML diagrams used to decompose a large system function into different software components that will run on different existing boards in a rack is ESL. The system functionality is certainly being defined, and it is definitely electronic. Even if all the hardware components are fixed and unchanging.


  13. Brian Bailey Says:

    Hi Jakob,
    You make some good points, but then you go and say:

    Grant Martin and others with a more academic inclination also wants to include the composition of systems from preexisting chips, but most of the EDA tools seem to focus on the insides of a single chip.

    I would argue that the EDA industries love affair with the chip is what is causing many of their current problems. This is just one of the major problems that ESL has to address. Look at the issues going on in the software industry related to making SW run on multi-processors. They have it easy in comparison because they are primarily homogeneous systems. What about a cell phone? Large numbers of heterogeneous processors with lots of different memory and bus systems connecting them. ESL is about getting these aspects of a system right as well as the functionality of each block. Where will you have congestion, what about synchronization across the systems? In the past with just a few highly isolated processors we could work these things out on a napkin and for the difficult ones a spreadsheet. These no longer work and dynamic execution of realistic workloads are necessary to ensure the “system” works.

  14. Bernard Murphy Says:

    To compound confusion, where does platform-assembly/IP-XACT, focused on implementation, fit into this picture? IP-XACT 1.4 is consistent with the TLM and register views above and is consistent with SystemC for modeling, but neither requires nor precludes SystemC for implementation. And yet this is certainly not RTL design. Indeed considering the proliferation of generators for bus, IO and other fabrics, platform assembly is arguably moving closer to (chip) specification-level design. Perhaps a SystemC purist would say this is not ESL, but then I would agree ESL is far to broad a title for only one component (modeling) of Electronic System Level Design.

  15. Grant Martin Says:

    I would argue that user of IP-XACT to support platform assembly is part of “architectural design space exploration” since it can be used as part of a flow that will both help in generation models of a platform and in generating downstream implementation of an assembly of chosen platform components. Indeed, since IP-XACT (SPIRIT was a much better name in my opinion ….) was driven in large part by Mentor’s Platform Express, which is counted by Mentor as an ESL tool (look at the Mentor Electronic System Level Product web pages under Platform-based design), this is certainly part of the ESL spectrum. Maybe architectural DSE is too limiting a term, but this is certainly one of the aims of Platform Express. Bernard’s suggestion of the term “specification-level design” is an interesting one, albeit apt on a TLA basis to be confused with the more general SLD=System-Level Design.

  16. Jakob Engblom Says:

    To Brian Bailey: we seem to agree that one problem is that EDA tools look at chip insides, but not at composiing boards from many different chips, and systems from networks of boards. Right?

    The sizing of interconnects on heterogeneous multicore chips to me sounds like classic inside-the-chip EDA. So I cannot quite follow the point being made here. It is clear that in principle there is a need for larger-scale design something, but in practice tools today are focused on bringing out new chip designs.

  17. Jon McDonald Says:

    This discussion raises some interesting points and I believe highlights the confusion we see in the industry. Between the domains of System Level Design (SLD) and Electronic System Level (ESL) we need to clearly define what falls into both domains, keeping this line fuzzy only serves to continue the confusion in the industry and with engineers trying to apply tools and methodologies to solve their problems in implementing systems. The definition Glenn puts forward that ESL must include some representation of the hardware I believe maps well onto what people are trying to accomplish and serves to clearly identify one of the critical attributes of working at the ESL level. Some representation of the hardware and the beginnings of understanding how the multiple concurrent hardware blocks interact with one another and with software is critical in making the tradeoffs to determine what architecture should be implemented in RTL. The point of ESL analysis is to explore the implementation space and select the correct architecture to implement before investing the effort in writing RTL.
    I believe there can be a very clean line between the SLD and ESL application areas. I agree with Shashi’s comments and I think he begins to draw this line between the domains. I believe System Level Design focuses on the questions of function, can we functionally implement the target system. This is independent of HW or SW and is really allowing us to identify the algorithms and functional manipulations that are required to satisfy the target application. Matlab/UML/C/C++ mainly fall into this space. Yes it is possible to model hardware in these languages, but in general modeling the hardware implementation is not the focus of these languages.
    ESL then is characterized by beginning to include representations of the concurrent blocks and tying these blocks together to understand potential target architectures. Transaction Level Modeling (TLM), is an attribute of this level of representation. If ESL is defined to include some concurrent representation of concurrent elements, then TLM is just the description of the way in which these concurrent elements communicate. TLM does not define the space it is a definition of a method of communication between the elements of the system.
    By separating the SLD and ESL spaces I believe we will enable engineers to more clearly understand how and where specific tools and methodologies can be applied in their system implementation flows. This does not preclude tools from spanning the SLD and ESL spaces, but it does allow us to clearly articulate what kinds of problems are being solved in the different spaces.

  18. Grant Martin Says:

    “There are more things in heaven and earth, Horatio,
    Than are dreamt of in your philosophy.”

    * Hamlet, Act I, scene v

    I think ultimately the users of SLD and ESL tools and methods will end up defining them “with their feet”, and will define the level of fuzz in the terms vs. the level of precise clarity. However, here are a couple of examples of fuzz that indicate, in my book, how hard it is to state definitively that ESL MUST have hardware, and SLD MUST be all about function. (even if “hardware implementation is not the focus of these languages”).
    1. UML: UML is not a language, but a “meta-notation” that through profiling, allows the creation of domain-specific notations or languages. Although driven from software roots, UML profiles for SystemC (for hardware definition) have been created by several groups including a consortium of companies in Japan, by STMicroelectronics, and several academic research groups. Is UML in this use model an SLD tool, an ESL tool, or does it cross the fuzzy line?
    2. SPW (was Comdisco, then Cadence Alta, then Cadence mainstream, and now CoWare). SPW allows you to describe algorithms in floating point, then refine them into fixed point, and then, if you want, using the HDS (hardware development system – although I may not be up on the current names CoWare is using) you can further refine the algorithm into an RTL implementation by substituting hardware/RTL blocks for algorithmic ones. Is SPW in this use case an SLD tool, an ESL tool or does it cross the fuzzy line.
    3. Matlab and Simulink are also crossing the similar line into HW implementation, and although they are primarily algorithm oriented (and thus SLD by the definition), they may do more on HW in the future.

    There may be a case, as Jon says, to try to clearly label the use models and define them more precisely, to reduce confusion. But I think the ESL and SLD terms are probably likely to remain somewhat loose in definition and application.

    But as always, designers can change the game by their actions here.

  19. Steve Leibson Says:

    “When I use a word,” Humpty Dumpty said, in a rather scornful tone, “it means just what I choose it to mean, neither more nor less.” – Through The Looking Glass by Lewis Carroll.

    In other words, I don’t think any one company or spokesperson gets to define what ESL is or isn’t. I have seen a lot of interesting experiments with tools that help designers create designs at the “electronic system level” and I am loathe to anoint just one of these as the one true path. At this moment, maintaining “clarity” as to the “true” meaning of ESL is far, far less important to me than finding design methods that let mere mortals successfully design systems containing hundreds of millions of gates.

  20. Gene Bushuyev Says:

    What is typically regarded as ESL, from software point of view, is a subset of Event-Driven Architecture (EDA again :-) . This architecture is nothing new or specific to SLD, just happened to be very natural for TLM as well as higher system level abstractions, that don’t even have any “E” in them, but simply rely on event-driven mechanism.
    Regarding UML, it’s a completely different software model, and in interests of clarity it shouldn’t be equated or considered part of ESL.

  21. Grant Martin Says:

    Gene, I have to disagree with you on UML, since as a collection of modelling notations with the addition of profiles involving specific stereotypes, it can be used for building many different models, and has been. In particular, there has been considerable work on using for modelling both hardware and software aspects of real time systems, and for SoC design including as a specification mechanism for SystemC. With UML, given the generality of notations and the ability to define specific semantics on it, it is the use models that count, not the fact that it originated in the specification of software systems – one can argue it has been expanded greatly out of its original scope. You should look at the ROOM methodology that started out at BNR, then ObjecTime, then Rational (ROSE-RT), then IBM – as written up in the book Real-Time Object-Oriented Modeling by Bran Selic , Garth Gullekson , Paul T. Ward (Wiley, 1994) for a thread that influenced UML 2.0 and went beyond just the software domain, and at more recent works such as UML for Real by Lavagno, Martin (that’s me) and Selic (Springer, 2003), Executable UML by Stephen Mellor and Marc Balcer (Addison-Wesley, 2002) and UML for SoC design (Mueller and Martin (that’s me again), Springer, 2005) for modelling approaches that can indeed spill into the ESL domain.

  22. Perry Alexander Says:

    This is a fascinating discussion. As someone who has been working in system-level design since the late 80s and now chairs the Rosetta standards committee, I would posit that SLD should subsume ESL. I am not diminishing its importance by saying that. But, when a radio is put in an airplane, dealing with ESL becomes a domain within system-level design. A bit too simplistic, but I’m hoping the point is not too controversial. If you’re not dealing with system-level concerns – energy, cost, weight, security, heterogeneity, etc – you’re not doing system-level design regardless of acronym, notation or tool.

    What is exciting about TLM is the abstraction of data and communication. One of my own frustrations with using traditional HDLs for system-level modeling is that once an interface is defined, it is almost impossible to refine data representation or communication mechanism. TLM gives me the ability to model data communication without committing too early to a particular implementation. It also provides a common abstraction for communication among heterogeneous components that is not biased.

  23. Shashi Says:

    SystemC entering into AMS domain will further expand the definition of ESL further beyond just the digital design abstraction layers – RTL/TLM. See the link:

  24. ESL and HDL Design » Blog Archive » ESL: The Power Savior? Says:

    [...] Contact Us « Keeping the “E” in ESL [...]

Leave a Reply