In my last blog, I talked about model-based design and Ken Karnofsky commented on it. Ken is the senior strategist for signal processing algorithms at MathWorks. He said that I got it somewhat wrong and so I was eager to find out more from him. He basically told me that considering model-based design as only being an abstraction method misses some important aspects of it. He also said that both graphical and textual representation can be important. For example, MathWorks has several different languages such as Simulink, Stateflow and MATLAB. The first two are graphical languages, the latter is textual. In many cases, users do not restrict themselves to just a single language, they use whichever is best for the task at hand and they are free to mix them in just about any way they please.
Putting that into perspective for hardware design, we do tend to restrict ourselves to one language, and for most people that is SystemC. While you can throw in some C and C++, it really doesn’t add anything new or different. Others prefer Bluespec which they claim is better at describing abstract hardware because you don’t have to try and extract whatever possible parallelism happens to exist in a serial language. Ken made a similar point in our conversation.
I then brought up the subject of hardware synthesis – what we generally call behavioral synthesis. I was told that they really just consider it more as code generation and you can use most of Simulink, Stateflow and a subset of MATLAB to get to an RTL description. He told me that they are seeing substantial growth in this area. I asked him how much MathWorks charges for this. While he was reluctant to provide an actual figure, I got enough information out of him to ascertain that it is an order of magnitude cheaper that what traditional EDA charges for behavioral synthesis. So, immediately this says to me that either their product is much simpler, the EDA companies are charging way too much, or there is something else going on. I will come back to this point shortly.
So, in my previous blog I talked about how in the hardware world interfaces are quite central to the refinement process and Ken accepted. He said that typically they just treat this as a modeling problem as well. They approach design flows by considering a particular application and the type of people who will need that kind of solution and then prepackage the models and interfaces necessary to make it work for that group of people. That very much resonated with me. At DAC 2010, I gave a keynote address to a system-design workshop where I said that the people who were most likely to be successful with an ESL flow were those who restricted the problem in ways that it became soluble. I talked about how the platform developers could create tools that only had to deal with their specific platform, and FPGA vendors who had certain constraints on the problem space that meant that they didn’t have to solve everyone’s problems at the same time, and then it dawned on me that I had never considered MathWorks in this category. They are not making the restrictions because of the possible market they are going after, they are making choices that enable them to create solutions for targeted groups of people in a very economic manner.
And here, I think is the key. MathWorks is attacking the market in a way that means that while they cannot solve everyone’s problem, for defined groups of people, they can fully provide a totally adequate solution. They are not trying to do it all at once and some of their customers are not the ones attempting to create the biggest or most far reaching SoCs. At the same time, many of their customers are dealing with very complex systems, including the environments in which they operate, which may need to be modeled as well. In short, they attempt to understand and address the issues of specific classes of customers rather than trying to create a completely generic solution. Over time, as more groups of customers are included, full solutions may emerge. This basically means that they take a much more pragmatic approach to their development. Ken mentioned how he believes the typical EDA notion of a virtual prototype is overly complex for many design problems and yet at the same time they do not address the growing need to have analog represented at this level. He talked about the difficulty of really assessing a design without including things such as high-speed wireless or RF which are part of the tradeoff space.
Another difference between the MathWorks approach to the synthesis problem and traditional EDA is that EDA still lacks much knowledge about the embedded space. EDA always thinks about taking software and mapping it into hardware, but when you start with abstract descriptions of the complete problem, targeting software is equally valid and this also requires code generation. Again, by focusing on specific customer problems and the environment that is being targeted, they can deal with this and thus have hardware/software co-generation capabilities where everyone else still thinks they are not possible.
Simplify the problem until you know how to solve it and then charge a reasonable price for the people you are attempting to target. This seems to be the MathWorks philosophy.
Brian Bailey – keeping you covered
P.S. I also learned that they are no longer The MathWorks. They have dropped “The” from their name.