On September 18th MathWorks introduced Simulink HDL Coder, which automatically generates synthesizable HDL code from models created in the company's widely-used Simulink and Stateflow software. The product produces target-independent Verilog and VHDL code and test benches for implementing and verifying ASICs and FPGAs.
The company is well known in EDA circles. However the size ($350 million) of the company may be a bit surprising.
I had an opportunity before the announcement to talk with Ken Karnosfky, Director of Signal Processing and Communication at MathWorks.
Would you give us a brief bio?
I have been at MathWorks for a little over 12 years. In college it was a combination of systems engineering and liberal arts. I have always kind of straddled the technology world and the world of English literature. I went to work for a couple of companies. The first company was in the area of signal processing and speech recognition. After that I joined a company that did data analysis software product. Initially it was an R&D type of world. Then I was in application engineering and customer consulting, moving gradually into product management and product marketing.
You are Director of marketing for Signal Processing and Communications. What application areas does that cover?
A variety of industries. It tends to be communication, audio, video, radar and tracking, and defense. The automotive industry is looking at techniques for active safety systems and entertainment. There is a lot of medical electronic imaging equipment as well. In terms of frequency and commonality, it is communication, multimedia: audio and video.
Would this include consumer products?
Absolutely both chips and final products like multimedia players. The best example would be PC with surround sound and multimedia. We also have customers making portable types of consumer products and companies well known for audio and home theater equipment.
What is the annual revenue for MathWorks?
Last year it was about $350 million. There are 1,400 employees.
How much of that was in Signal Processing and Communication?
It is a little bit fuzzy for a variety of reasons. I can't say exactly but it is somewhere between 25% and 30%. It is probably a bit higher. The reason I hesitate is that there are people who use signal processing techniques in other applications. There are engineers who are collecting data of some sort, filtering it and doing data reduction and correlation which are contained in our signal processing tool box product but they are not really doing DSP design.
What was the motivation, the backdrop, for developing Simulink HDL Coder?
In the product development process there are two sets of engineers. First there are people who do system design and modeling and algorithmic development. Simulink and MATLAB are the leading tools for doing that. Then there are the engineers who are responsible for the implementation of hardware and embedded software, primarily relying on hardware description languages and C code. Bridging those two world is increasing seen as necessary to accelerate the development processes so that you can deal with the complexity in hardware/software systems. We are hearing from our customers about the need to automatically generate hardware and software implementation from these models and to verify implementation of systems and components against those models.
Simulink and MATLAB are well established for designing, simulating and validating the system model. We have mature technology that is widely adopted for the automatic code generation on the embedded software side through our Real-Time Workshop products and extensions that target specific microprocessors and DSPs as well as what we call linked products that provide verification and debugging interfaces to downstream tools that work with those processors. On the hardware side our initial entry into the hardware design and verification flow is a product called Link for ModelSim which is a co-simulation interface between Mentor Graphics' ModelSim HDL simulator and our MATLAB/Simulink product. It is used to verify hardware component implementation within the context of an overall system model and being able to reuse those models to verify the hardware.
Model based design is not the exclusive province of MathWorks. There are many companies that are participating in providing a path from system level models and algorithms into implementation and testing. These include FPGA, processor and DSP vendors, vendors of downstream tools for EDA and ESL, board vendors who provide prototyping and development solutions and testing, verification and software and hardware companies. If one Goggles MATLAB OR Simulink AND (HDL OR RTL OR Verilog), one gets a million hits. This result indicates a high level of interest in the design community of combining these two worlds of MATLAB and the hardware implementation and verification.
There are current options for hardware implementation from Simulink models with model based design. However, they tend to be very specialized. For example Xlinx and Altera have created add-ons to Simulink, essentially a way to provide a Simulink front end to help development with their IP cores. You can model these in the Simulink environment, specify parameters for implementation and then automatically generate the implementation. Those have been very well accepted and are quite popular and valuable. However, there are some limitations. The first is that they require specific block libraries. If you think of the engineering process going from the initial specification and exploration which might be a floating point model, refine that down to a fixed point model. Once you are satisfied with the results, having to replace that model with something specialized to a specific hardware implementation has a couple of ramifications. One is that you have to maintain two sets of models. Testing and keeping them in synch is more difficult. There is opportunity for more bugs to creep in as a result. The additional problem is that these tools are not well integrated with the software design flow at least not for software for embedded processors. Large proportion of designs involving FPGAs involve hardware and software, whether the embedded processor is on the FPGA or co-processing with a DSP or general purpose processor. They are also target specific. The design is really locked into a particular implementation architecture. If you want to migrate to a different chip from the same vendor or from a different vendor, then you have to start from scratch. If you want to go from an FPGA prototype to an ASIC, you encounter a similar type of problem. Finally, these tools don't leverage the full range of model based design capabilities that MathWorks offers in terms of verification, validation and other aspects of multi engineering simulation. That's the backdrop.
What does Simulink HDL Coder do?
This product generates synthesizable VHDL and Verilog directly from the Simulink models using standard blocks in Simulink as well as finite state machines that are modeled by our Stateflow product. Stateflow is an optional add-on to Simulink. This represents finite state machines and control logic. Stateflow models or diagrams can be represented as blocks within a Simulink model. So you can have both data path and control logic within the same model. With this product you can generate HDL code for both the data path and control logic elements of the chip. The code is target independent and portable IEEE standard VHDL or Verilog. That means that the design is in a sense future proof. You can develop IP and maintain it at this level of abstraction, not tied to a specific target architecture. Then retarget it to something new on you next design project. This requires no modification of software or any kind of specialized blocks. You have the ability to maintain one reference design or one truth. So there is no question about what the design intent is. When you later test the implementation, you still have that one reference design that relates all the way back to the original specification and requirements. The output, the generated HDL code, is correct by construction. The Simulink model is bit exact and cycle accurate with respect to the generated code.
The impact we see from this product comes from the fact that now engineers can generate hardware and software from the same Simulink model. There is a large base of algorithmic IP that has been developed in the Simulink environment. Sometimes it is already been used in a software environment but customers are looking for a way to implement that on an FPGS or hardware accelerator or an ASIC environment. This allows them to do that. They can migrate the hardware and leverage what they have already done. The code is direct generation of the hardware description language from the Simulink executable specification. There has been a lot of talk over the last couple of years about moving up in the level of abstraction and providing ways to start at a high level and looking for ways to do executable specifications and then produce the design that does exactly that but it does not introduce a radical shift in terms of the type of tools that people use. We are simply connecting the standard and most widely used tools for system and algorithmic design with standard language for hardware implementation. No intermediate steps. No intermediate languages; C code for processors and HDL code for hardware. We see this as dramatically accelerating the development process both the design and verification. One of the reasons it does that is that it bridges this abstraction barrier between the system and algorithm designers who tend to think more in mathematical models and the hardware designers who think in hardware description language and logic gates and the like. It allows the handoff for designs from one stage of the project to be much more productive and unambiguous.