Academic frustration
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.
- Tags:
Comments
It feels strange to me how
It feels strange to me how you phrase the academic frustration as I have also heard very similar arguments to express some form of "indutry frustration". Typically, academics have always looked at problems in a broader sense and with a farther look into the future whereas industry does not have time to dwell on such issues and has to produce products that can be sold in a reasonable amount of time and with, usually, a low amount of risk. Hence, the point tool solution that you describe (for specific applications only etc.) is what I would expect more in an industrial environment whereas academics would not bring this to the market but write papers on how a certain application domain was used for the first tests of a very general solution but and how future work will expand the possibilities. In other words, academics try to see the bigger picture and think two steps ahead. In that respect, the question is of course where a research institute such as IMEC fits in. Probably somewhere in between academic research and industrial R&D.
In conclusion: I don't think it is only an apples to oranges comparison, but mainly a matter of how you like to look at things. In that respect, I wonder if you are not missing out on an academic career... Just a thought.
I agree with your analysis of
I agree with your analysis of academics versus industry. Actually, I think my story is a good illustration.
Cathedral was certainly an attempt to think "two steps ahead". In fact, it's only recently since the type of ideas and techniques that were being developed seem to find their way into viable commercial tools.
By contrast, around 1990 the fundamental research behind multilevel logic synthesis had basically been done, and it was ready for prime time. However, this doesn't mean that it was a done deal. We still needed innovative companies to create the tools, methodologies and support structures to bring about the revolution. It was still necessary to think "one step ahead".
Both academic research and industrial innovation are essential for major paradigm shifts like this. Likewise, different types of talent and personalities are required, and it is important that they are deployed effectively. For me personally, I believe that corresponds to the second type of environment.
Another interesting point you mention is the specific case of IMEC. There can be little doubt that we were doing "academic research" at the time: the management structure was mostly based on university professors and assistants, most of my collegues were doing PhDs, and the output was academic papers in the first place. However, what was probably uncommon is that all research was done in the context of one big umbrella project. Whether that is the best way to structure academic research is an interesting (but separate) question.