What ESL Is Really About

There has been an almost constant disagreement between the generally held view about what ESL is and my own views on the subject. It is not completely surprising, given that I have spent most of my time as a verification specialist working within the EDA industry. EDA has been driven by design, and all of the largest EDA companies grew out of advances on the design side.

Verification engineers have only been seen as first-class engineers in quite modern history. Before then the adage went that if you were not good enough for design you did verification. But that has changed, and I believe it will continue to change because verification will become the leader and will be the driver of ESL methodologies.

A couple of decades ago, Gary Smith and I had a running discussion about this. He would tell me about companies that had a great new (HLS) tool that could take C and produce hardware in a fraction of the time that it took hardware designers. I would scoff at him a little and tell him it would not succeed. This continued for several years, and every time he brought a new company to me I told him the same thing. Eventually he asked me why I dismissed them so quickly, often before he had even finished explaining them to me. The answer was simple: none of them had addressed the verification challenge.

While Gary eventually agreed with me, the rest of the market didn’t. They all believed the migration to ESL would be triggered by the right synthesis tool, and that it would be identical to the migration to RTL. Every company wanted to be the Synopsys of ESL. But nobody addressed the verification side of things, and this is part of the reason why adoption was slow.

Even after the HLS vendors realized the importance of verification and put some things in place, they did not fully understand the challenges. Some HLS tool vendors even reported that companies were adopting HLS because of the gains they got in verification productivity. That should have been the tip-off right there, but even to this day nobody has yet managed to define what an ESL verification flow looks like.

We are beginning to get closer. Graph-based solutions are defining scenarios that can be used to generate testcases for the hardware. These tests also can be used on several abstractions of the design ranging from virtual prototypes through and simulation down to actual silicon. It is a start.

What we need is an executable requirement document that may be described using graphs or other representation. This needs a whole bunch of tools surrounding it. It needs tools to analyze its completeness, and that includes the definition of coverage for the system-level. It needs to be able to synthesize tests, and this piece is beginning to happen. It needs to be partitionable so that use-cases can be extracted for the sub-pieces of a design. In short it needs to be the one document that drives the whole verification process from start to finish and can accommodate bottom-up insertion of IP.

Verification is not just about functionality, it is about performance, power and possibly other factors such as security. Dealing with these issues takes a different way of thinking than has been used in the past. These things are statistical in nature and are not going to be answered by a single run.

It is only when these exist that ESL stands a chance of being adopted en masse. But even this may not be enough. It may have been adequate 10 years ago, but today any verification solution that does not include software is only tackling a part of the problem. There are ways in which drivers can be inserted into this type of flow, but higher levels of software may create more challenges. In addition to ESL verification flows, we also need to start looking at system-level verification flows.