Posted by frank schirrmeister on October 29, 2009
Some of the recent coverage on our recent high-level synthesis (HLS) announcement is missing an important aspect. Fundamentally the discussion on entry languages is misleading. HLS is not about languages. Sorry, no war here. It is about the amount of information explicitly defined compared the amount of information left open and guided by constraints. While there is no language which does it all, pretty much all languages can express multiple levels of detail.
For example, Bryon Moyer over at TechFocus Media provided an interesting perspective giving the different languages personalities in his article “Living With Ambiguity: The Other HLS”. Bryon makes good points but the different personalities are in my mind really not competing, they are mostly complementing each other but also have some overlap.
Let’s try an analogy. How has your boss been treating you lately? Bosses fall into different categories, as we all know. Some bosses tell you “get this partnership done” and then leave all the details up to you. They may set constraints together with you regarding what the main objectives for the partnership should be, but you have freedom to go about it and implement it as you see fit. At the other end of the spectrum you find bosses who are with you every step of the way. They participate in decisions on detailed tactics. The key difference lies in the amount of freedom to “make things up”, or to “pull things out of thin air” given the basic constraints set by the objectives.
Well, in HLS we face exactly the same situation. In the press pitch we used the picture on the left to explain the relationship between the different levels to express detail. A flaw in the description is that we used languages. We really meant abstraction levels. While the 3 lines of M code just define a function, the 20 lines of C code are much more precise about which types to use. The 200 lines of RTL code are very specific, down to the bit. All the loops are unrolled and specific resource usage is defined.
If you allow a tool to “make more things up”, i.e. create more of your implementation automatically based on constraints, ultimately you will gain key benefits. Not only will it will be simpler and easier to create a working algorithm, you will also work on significantly smaller code and you will likely introduce less bugs into the flow. Everything comes at a price though. You have less actual influence on how loops get unrolled and which specific resources are used etc. You give up that freedom in exchange for the benefits mentioned above.
When it comes to languages, they really do not directly compete too much. Starting with M you define the algorithm and you set constraints on frequency, power and area and then you let the tool do the rest. Similar things can be done in C. We have seen that with a couple of hundred lines of C code you can easily implement FFTs and IDCTs from C as well with little overhead. However, if you need more specific control, i.e. want to be a more influential “boss to your tool”, then you have to add specific information to your C or SystemC code to specify how to unroll loops and which resources to use. You are essentially doing hardware design in C. From a language perspective you can express a lot of this level of detail and detailed constrains in other languages as well – SystemVerilog for example.
In closing, let’s see which implementation choice my daughter will choose now that I told her to clean up her room. She can put everything way properly, could pile it and hide it in drawers or even just push everything into the “papa-taboo” area under her bunk bed. Let me get over there and be more specific with my constraints … 🙂
Patrick Sheridan is responsible for Synopsys' system-level solution for virtual prototyping. In addition to his responsibilities at Synopsys, from 2005 through 2011 he served as the Executive Director of the Open SystemC Initiative (now part of the Accellera Systems Initiative). Mr. Sheridan has 30 years of experience in the marketing and business development of high technology hardware and software products for Silicon Valley companies.
Malte Doerper is responsible for driving the software oriented virtual prototyping business at Synopsys. Today he is based in Mountain View, California. Malte also spent over 7 years in Tokyo, Japan, where he led the customer facing program management practice for the Synopsys system-level products. Malte has over 12 years’ experiences in all aspects of system-level design ranging from research, engineering, product management and business development. Malte joined Synopsys through the CoWare acquisition, before CoWare he worked as researcher at the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany.
Tom De Schutter
Tom De Schutter is responsible for driving the physical prototyping business at Synopsys. He joined Synopsys through the acquisition of CoWare where he was the product marketing manager for transaction-level models. Tom has over 10 years of experience in system-level design through different marketing and engineering roles. Before joining the marketing team he led the transaction-level modeling team at CoWare.