DVCon Panel: Trying to Define the ESL Shapeshifter

In last week’s post on The Breker Trekker we summarized activities at the Design and Verification Conference and Exhibition (DVCon) in San Jose, including a brief mention of the “Redefining ESL” panel on Wednesday morning. I attended this session and took detailed notes in anticipation of blogging about it, but in the process gave some thought to my own opinions about the electronic system-level (ESL) domain and how they intersect with those of the panel participants.

The panel was organized by Dave Kelf of OneSpin Solutions and PR guru Nanette Collins, and moderated by Brian Bailey of SemiconductorEngineering. Brian is a long-time observer of the ESL market so I expected him to ask some tough questions. He opened by remarking that the term is generally credited to the late EDA analyst Gary Smith. Many of us who knew Gary sometimes teased him a bit on his regular pronouncements that “this will be the year of ESL.”

Brian asked the panelists to present a brief opening statement, and they were off and running. It was clear from the outset that there was no consensus on how ESL is defined today, let alone how it might be redefined. No one actually said “shapeshifter” although this occurred to me as an appropriate image for a term whose meaning changes constantly depending upon which magic incantations EDA vendors use on it. Perhaps it even changes of its own accord.

Simon Davidmann from Imperas Software acknowledged the difficulty of talking about ESL if one can’t define it. He called it a “misnomer” and an “umbrella term” then followed with the provocative statement that EDA vendors should move away from trying to sell tools to solving the “real hardware/software problem.” Simon focused on ESL as a solution for software developers, especially those writing code that is “close to the hardware” as in the embedded systems world.

Cadence’s Dave Pursley agreed with Simon’s comments but noted that users “don’t have to boil the ocean to get started” with ESL. Adoption of individual technologies under the ESL umbrella can be incremental. He also commented that one real value of moving to a higher level of abstraction is separating the design from the RTL implementation, eliminating RTL typos while finding “different types of bugs” in the more abstract model.

Bryan Bowyer of Mentor Graphics agreed but remarked that “people still make typos in C code.” He noted that ESL is often used to encompass both high-level synthesis (HLS) and the use of virtual platforms, remarking that HLS “is not necessarily ESL.” He asked what links exist between HLS and virtual platforms today and what links should exist in the future. Brian closed by noting that ESL verification must be self-checking; “the reference model doesn’t go away.”

Patrick Sheridan from Synopsys focused on the use of virtual prototypes for software development, software-hardware co-development, and architectural design prior to RTL. He said that a chip architect “starts with a spreadsheet and moves down” to models, which must be register-accurate for a consistent software view. He also noted that the virtual platform/prototype part of ESL is somewhat disconnected from the rest of the chip development process.

Breker’s own Adnan Hamid talked about the relationship between ESL and the portable verification approach being standardized by the Accellera Portable Stimulus Working Group (PSWG). Since the Accellera vision spans multiple levels of abstraction, Adnan pointed out that a common model could generate tests for virtual platforms, RTL models, and beyond to silicon. Thus, better verification methodology can help bring ESL more closely into the development mainstream.

OneSpin’s Raik Brinkmann also addressed verification, saying that with ESL you can “do what you used to do and more” by finding both implementation bugs and higher-level design errors. He stressed that ESL must address the system problem regardless of whether hardware or software is being verified. On the HLS front, he described a recent demo he saw of a tool that takes a system model and generates both the hardware and software portions of the implementation.

So ESL indeed seemed to be shapeshifting before our eyes as the moderator and audience asked questions while the panelists presented their points of view. As I thought back over the panel, it seemed to me that ESL is most often used to envelope one, two, or all three of the following technologies:

• Virtual platforms/prototypes/models for architectural modeling and performance analysis
• Virtual platforms/prototypes/models for early software development and testing
• High-level synthesis from a model more abstract than RTL

The first two items on this list may be related, although a fast processor model may suffice for some forms of software development whereas architectural work generally requires a more complete model of the system. However, HLS is not obviously related to either of the other two items. I believe that we so often see these ideas linked under the same banner primarily because all three often use some combination of C/C++/SystemC.

This leads to the question I wanted to ask the panel but there were too many people already in line: is there any hope of defining a common abstract representation or model, possibly in C/C++/SystemC, that can satisfy all three aspects of ESL? It seems to me that there was an early assumption that this would be the case, with the architect’s model being used by the programmers to run their software and by the hardware engineers for HLS. This is not the case today and it is not clear whether we will get there.

In the meantime, portable stimulus can and will help to tie ESL into mainstream chip development. Some of our customers already use our tools to automatically generate tests for both high-level models and RTL (and beyond). Reuse of stimulus, results checking, and coverage from virtual prototypes to silicon, in either direction, is both part of the Accellera vision and a capability we deliver today. What else can we do to help you with your ESL needs?

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: Accellera, application, Breker, bring-up lab, Cadence, dvcon, emulation, ESL, FPGA, functional verification, graph, high-level synthesis, HLS, Imperas, mentor, node coverage, OneSpin, portable stimulus, prototyping, PSWG, realistic use case, scenario model, simulation, SoC validation, SoC verification, Synopsys, system-on-chip, test case generator, test cases, Universal Verification Methodology, use-case coverage, uvm, virtual platform, virtual prototype

This entry was posted on Wednesday, March 9th, 2016 at 4:06 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.