Jan on HDL Design

It has been quiet around this corner for some time, but on the broader Sigasi front, a lot has happened. A few days after my previous post, Sigasi released their VHDL IDE as an Eclipse plugin. Previously it was only available as a standalone product, which somewhat hided its Eclipse foundation. Following this important release, Philippe Faes (Sigasi's CEO) published two whitepapers explaining the ideas and the vision behind the product: "Why Hardware Designers should switch to Eclipse" and "How to sell EDA tools in Liechtenstein". The latter was actually an invited (and winning) entry to Xuropa's "Do More with Less" contest.

With all these events, one would swear that those Sigasi guys had heard me :-) Joking aside, it is clear why I am happy to be part of the Sigasi team. I think that we have a credible offering to help change EDA along the lines that I described in my previous post. There definitely is some great technology behind Sigasi HDT. However, I believe the most interesting and innovative aspect is the model used to develop, package, sell and support the product. Let me elaborate on this a little further.

Sigasi received a lot of positive responses on their latest publications, as well as several interesting negative ones. Some people thought that we were basically arguing about using IDEs for hardware design. One person responded that we should stop talking about this IDE stuff, so that the good old vi versus emacs wars could continue! I fear that he was only half-joking.

To Philippe and Hendrik, Sigasi's founders, the eventual move to IDEs is self-evident. What they were really arguing about is how IDEs should be done: not as a closed system but as a system on top of Eclipse, an industry-standard open platform that enables massive and systematic reuse.

Reuse: there is a crucial word. To Philippe and Hendrik, reuse is in their blood, almost an obsession. They are constantly looking out for shoulders to stand on, and not only from giants. Conceptually, reuse sounds like an obvious idea, but in my experience, it is quite hard to apply it systematically in practice. They do it with remarkable ease.

Then there is the role of the internet. When I saw Philippe and Hendrik using it, I felt for the first time in my professional life that I belong to an aging generation. My generation comes from an internet-less world and has witnessed its history, with all the models and applications that were tried out, the failures as well as the unexpected successes that later seemed obvious. But for them, the internet is their natural habitat. Their internet is obviously about the interaction between people about interesting content. Web 2.0 is the normal state of things, as they simply skipped the 1.0 part.

When Philippe introduced me to twitter, I initially discarded it as an nonsensical proposition, as many of my generation still do. In the hands of certain users, it actually is - some Belgian politicians come to mind. But in practice, Sigasi's twitter presence has lead to some very valuable business contacts. Even better, it has clearly been the catalyst for a number of sales. With arguments like that, there's no need to convince me further.

So there you have it: an EDA product developed on top of an open platform using modern agile software techniques, and sold, distributed and supported over the internet. The result is a very powerful and sophisticated product with a price point that makes it accessible to all. This is the EDA that I like.

Sigasi is not alone. Other companies are emerging with similar ideas and models. So I believe that EDA 2.0 is on its way. And as with other innovations it will all seem obvious in hindsight.

In my previous blog post, I concluded that RTL synthesis was the latest of the all-time most important EDA innovations. Although it is more than 20 years old, nothing with a similar impact has happened since.

It's not that there was a lack of candidates. In the early nineties, several ideas and technologies seemed to have great potential. Personally, I was eager to repeat my great experience with RTL synthesis. Moreover, my company was basically selling design methodology, so we had a vested interest to stay at the forefront of innovation. Consequently, we were continuously watching out for the next big thing. But it didn't come. So here is my personal anti-list: the biggest EDA innovations that did not happen.

First on my list is Asynchronous Design Synthesis. Asynchronous design refers to design techniques without a global clock. It promises advantages with regard to performance, power consumption and design security, but it is inherently more complicated than synchronous design.

Then comes Formal Verification. Formal verification refers to the use of mathematical proof to verify the correctness of a design. When it works, it is superior to simulation, because it provides a 100% guarantee.

Last but not least we have Behavioral Synthesis. This is a technique whereby one starts from an algorithmic description, and where a synthesis tool allocates hardware resources and assigns operations to clock cycles.

Let me be clear about my position. I certainly don't want to suggest that there hasn't been any progress in the listed domains. Quite the contrary. There are now EDA tools that support a systematic methodology for asynchronous design. Formal verification tools are being employed successfully for certain well-defined tasks in the design flow. And behavioral synthesis is moving into the spotlight with the new wave of C-based high level synthesis tools.

What I am saying is that these tools have not fundamentally changed the way in which the majority of design engineers work. The mainstream paradigm for digital circuitry and EDA is still synchronous design. To verify the functionality of complex designs, we are still using good old simulation, not formal verification. And behavioral synthesis hasn't replaced RTL synthesis as the principal synthesis technique in mainstream design flows.

In summary, none of these tools has revolutionized the industry in the way RTL synthesis did.

In my previous blog post, I told you that back in 1990 I got pretty excited about my first experiments with Synopsys Design Compiler.

To understand my excitement better, let me explain where I was coming from. After I graduated in 1985, I had worked for 2.5 years at the brand new IMEC institute in Leuven, Belgium. I was part of a team that did research on behavioral synthesis, in a project called the Cathedral silicon compiler. I remember well how we thought about the state of the field. Logic synthesis was considered a solved problem. The next big thing was "obviously" going to be behavioral synthesis. However, this is a very complex problem. Therefore (so the argument went) you have to choose a particular application domain to make it tractable. In our case, the application domain was DSP.

There were several clever people in the team doing clever things. But I remember that I often got a feeling of dissatisfaction. The choice of an application domain seemed artificial and arbitrary. Moreover, our behavioral synthesis tool needed a lot of manual steering through so-called "pragma's". As a result, it often seemed that the tool was not just restricted to an application domain, but to a single example.

Synopsys Design Compiler was a totally different kind of tool. It didn't need to know about the application domain: you could use it for just about any kind of digital design. Moreover, it came up with a good solution by default: pragma's and settings were only required to further optimize an already good solution. I felt relieved: this was silicon compilation according to my taste!

I can hear the critique already. What's the point in comparing a research project on behavioral synthesis to a commercial tool that surely works at a much lower level? Isn't this comparing apples to oranges? Well, I have a lot more to say about that, but I'll leave it for future posts. But in some sense the critique is definitely valid. As a result, my main conclusion out of this experience was that I'm probably not suited for an academic career. I didn't realize it at the time, but what I missed was a direct link to industry and customers.

I guess I always felt more at ease in the bazaar than in the cathedral.