Why bother with ESL?

I’m in southern California today at the EDA Tech Form. I’ve been thinking about a conversation I had recently with a colleague. He’s been doing system-level modeling for a few years and has been an advocate for transaction-level modeling and ESL in his company. He has had tremendous success in identifying and fixing system-architecture issues before implementation, as well as saving his company from pursuing business that they would not have been able to satisfy based on their current product architecture. Yet he still has trouble convincing project groups to invest in the up-front ESL modeling and analysis that has delivered his success.

I’ve been struggling to understand the perspective of the project groups he is dealing with. As I was driving through the unpredictable SoCal traffic this morning, which stopped occasionally for no apparent reason, I was struck by an analogy that applies to this RTL implementation-focused perspective. My thinking was this: If I think of the highways as corresponding to the hardware in an electronic system, the cars to the data and the decisions made by all the drivers as the software, then look at this from a road-centric view, then I might gain some insight into the RTL focused perspective. As a public works professional if I analyze the use of the highways through a functional point to point perspective, analyzing the ability of a car to get from point A to point B and how long that takes in isolation, I may find that the highways are completely adequate. However this does not exercise the system in the way it will actually be used. It does not take into account the chaotic interaction of the millions of cars and drivers over time that occasionally bring traffic to a complete standstill.

As a hardware designer focused on the hardware implementation, I may prove that the hardware works exactly as it is designed to work, but at this RTL implementation level we cannot run real software interacting with real data without building the actual system or implementing a prototype of the system. This is one of the reasons to bother with ESL design. At the transaction level of abstraction I can create a system on which I can run actual software processing real data sequences that quantify what will happen in the system under much more realistic situations than I can explore in RTL. Not that this is a perfect representation of the end system, but it is much closer to the ultimate use case than we can get at the lower level.

If we think of the hardware in isolation you can easily come to the conclusion that you can adequately test and verify the hardware at the implementation level (RTL), but if you try to get closer to reality you need to work at a more abstract level to handle the workload scenarios needed to get effective information. Ultimately ESL allows us to get closer the old aerospace adage, “Fly as you test, test as you fly.” That’s why we’re bothering to invest in ESL design and analysis in the first place.

—Jon McDonald, technical marketing engineer, Mentor Graphics