Was Brian Bailey right?

3/5/2013 2:05 PM EST

Where do I start? I think we have to go back about 15 years to a time when Gary Smith started to get interested in tools that we now call high-level synthesis (HLS) and was the reason why he coined the term Electronic System Level (ESL). He would talk to me about a new tool and fairly quickly I would give it the thumbs down. After doing this for a few years, he asked me why I so readily dismissed them without ever having even played with them. My answer was that the verification of those input models was almost impossible and that there was no way to verify that what the tool produced matched the original intent or requirements. Gary thought on this and then published an industry paper in which he declared “Brian Bailey was right”. He has mentioned this in several presentations and conferences. Just a few years ago he basically stated that the Brian Bailey requirement was now being met and this was why HLS was taking off in the market.

While Gary may have been right, I was not feeling comfortable about that determination but I didn’t really know why. I believe I now know the reason. The definition of ESL was wrong. HSL is just a minor incremental capability that extends the RTL design paradigm for a subset of designs into an elevated abstraction. It is not the next level of abstraction for the system. A system today is composed of many blocks, most of them obtained as IP, and will contain one or more processors. We can easily consider a chip that has no custom content and thus no need for HLS at all. While many may say that such a chip has no differentiation and thus is nothing but a commodity product, there are many systems today that provide all of the differentiation in software.

The Cadence 360 manifesto correctly identified that tools are required to assist with the stitching together of IP blocks. However, it has understated the importance as this is rapidly becoming a significant problem in the industry with almost no tool support. There are some point tools emerging that will, for example, formally prove that the blocks are connected correctly, but that is just one of the low-level requirements for integration and system verification. Other companies such as Breker and Mentor have announcing tools that enable system-level verification. They do this by running software on the embedded processors rather than attempting to generate random transactions that are fed into bus functional models. In fact, I would decree that this is the real ESL, not the abstraction used for HLS. In this domain we are beginning to understand the end-user requirements, finding a vocabulary to describe the problem, and offering a few scattered tools. These tools are not extensions of the existing tools and those who attempt to do this will likely fail. The IP integration and verification space requires new and unique tools that are very different than those that have been developed in the past.

They say that history never repeats itself. In this instance they may be right. When it was clear that a new abstraction was needed, everyone assumed that the new leader would be the one who controlled synthesis, just as Synopsys had done for RTL. They are wrong. The new leaders will be the ones who master IP integration and verification and most of this is about verification. It may be a decade or more until we work out how automation can help on the design side.

Let this be the time when ESL has been properly defined.