Bridging the Flows

The Mathworks’ co-founder and president talks about the future of chip development and why architects may be working side-by-side with design engineers.

Jack Little, president and co-founder of The Mathworks, sat down with DACeZine to talk about changes in chip design and how disparate workflows can be merged to improve efficiency.  What follows are excerpts of that conversation.

By Ed Sperling

Q: Looking at the market from The Mathworks perspective, where is the next big opportunity?
Little: In the EDA area, the algorithms that underlie chip design have been conceived individually, and therefore there are gaps in the flow. That can be improved upon. There is also a problem, and thus an opportunity, in the embedded market.

Q: So how do you solve it? By raising the level of abstraction?
Little: The level of abstraction we are at now has been in use for years by people working on models and working at the algorithmic and mathematical levels. But the workflow hasn’t been well connected. We need to connect that workflow better, automate it, connect the tools better.

Q: One of the other speakers at DAC, Intel CTO Justin Rattner, said the analog and digital worlds will merge if everything is looked at computationally. Is that true?
Little: I agree with that, but I would broaden it even further. The terminology we use is that everything is a model. A model can take many forms. Certainly mathematics is part of it, but a model also can take the form of a diagram. It can be a discrete event model. It can be a signal-processing model. It can be a hydraulic system model. There are many disciplines, and each has its own set of mathematics that is important to them. That’s typically represented in domain-specific models. Sometimes, they don’t always feel mathematical, though.

Q: Is there a way we can use the same terminology across disciplines?
Little: There are common elements of state models that are used across different areas. The notion of differential equations appears in many disciplines. But typically each of these areas has a set of models that is important to it. Our approach has been to create an environment where things all work together, so you can build an integrated model of a system that includes whatever domains you need to simulate the whole system. But the different disciplines have different ways that they want to think about things in order to describe a particular problem. I don’t think there is one piece of mathematics or an equation that would work for everyone. There are also practical issues of efficiency, because ultimately you need to simulate the system. It is a big benefit when you can simulate a design and use it both for verification and validation. Another element of breaking a system into separate models is efficiency. You need to run tens of thousands of test cases.

Q: In the total EDA flow, where does The Mathworks fit?
Little: We are the onramp to the workflow. Our goal is to connect the various disciplines at the algorithmic level—the DSP engineer, the image processing engineer, even the mechanical engineer who knows very little about EDA tools but who can integrate a chip into a design. Our job is to connect this diverse group, regardless of whether they have experience, with a flow that is familiar to them all. This is what we have done in the embedded systems area. We enable a control engineer to create and move into production a system based on the underlying algorithms. They can focus on the equations and the models that are known in their discipline, but they also can efficiently go down in the abstraction level to embedded code and real-time systems.

Q: Are you looking to take that into the SoC world?
Little: By generating appropriate HDL code, we’re trying to integrate our tools with existing EDA tools in all possible areas.

Q: Algorithms seem to be increasingly important in the software world. What effect is that having?
Little: It’s a little hard for us to see that. The people who are using multi-domain methods have always been our bread and butter. But with the availability of bigger and more powerful hardware, as well as more sophisticated embedded systems design, people are getting increasingly ambitious about the sophistication of the algorithm they’re willing to implement. In the embedded world, as an example, the software coming out on cars to keep a vehicle within lane markers requires a lot of mathematics and image processing.

Q: So it sounds like The Mathworks is looking to go mainstream in EDA with its tools.
Little: We think there can be more utilization of our tools in the EDA industry. But we must insure that we offer a solution that is also more cost-effective, so you don’t have to create an algorithm in MATLAB code and then have someone else hand code it into an HDL system.  Automating those steps will make our tools more useful. We certainly hope to open up the algorithms to EDA developers in ways they have never seen before.

Q: Much of the expertise being sought by hardware companies these days is in software. Are the software engineers working with your tools in school?
Little: Yes, and this can open some doors for us.

Q: Does that vary from one region to the next around the globe?
Little: We have always sold our products around the world. The research community has always been international. Our tools have grown up with a worldwide focus.

Q: Each one of these regions is doing something different, though, so the need may be different by region.
Little: For us, it is an opportunity to connect the tools together. There are opportunities everywhere to improve efficiency in the system—design process, regardless of the specific domain being addressed.

Q: But the other piece of this equation is that the cost of developing chips is still too high, and a good portion of the change under way is in software. Where does your company fit in?
Little: Failure to meet requirements is very often the cause of missed schedules.  The implementation may be fine, but the error may be at the top level.  For example, it may be that all the elements weren’t designed in the right way. Frequently, designers implement the wrong algorithm. That’s where you need model-based design tools. They allow you to generate design alternatives early. You work out lots of different models, and then you simulate them. You also model your environment. You don’t just model what you are working on. You must model what it interfaces with, whether it’s the external environment or another electronic system it’s connected to, or even something mechanical. You perform early validation before you implement the design in hardware. It’s really valuable to explore the design alternatives early.

Q: It also allows you to optimize what you’re doing with the given hardware, too, doesn’t it?
Little: Absolutely. In fact, as you proceed on the implementation path, our tools allow designers to begin modifying the model with implementation details. Then they can continue to use the models to validate against the test cases. Developers get to reuse the validation approaches and the test vectors. A lot of what companies are trying to do to be more successful in designing their systems is to move the design work earlier in the cycle. That way they can have a more complete design earlier, and continue with the polishing and the validation. If you get your requirements right, you’re not trying to solve your requirements during the detailed implementation.

Q: Doesn’t that open the door for derivatives of a design, as well, so the hardware can be re-used with different software scenarios?
Little: We call that the "Gold Model." It’s an executable specification. It’s the specification for your design, but you can run it and simulate it and use it through all phases of the development process.

Q: But that still leaves the verification problem. Can you pinpoint the errors more quickly?
Little: You have the option of looking for errors in all the processes and figuring out if it’s an algorithmic error or if it’s an implementation error at the hardware level, which you can simulate. It does give you the ability to figure out where the problem is.

Q: What happens if the error is in the algorithm? Does that make it easier to find?
Little: It depends on the type of error. It’s always better to catch an error early, but whether that’s possible depends on the type of error.

Q: There are a bunch of simulators going at once on these development projects. Does information flow back and forth among them?
Little: We have a family of link products for Cadence Insight, Mentor ModelSim and Synopsys' Discovery. You can write MATLAB scripts to drive one of those simulators and compare results, or you compare Simulink results, or you can co-simulate using Simulink together with an EDA simulator.  The link products allow engineers to compare results at any stage of implementation with your original Gold Model or with results after the design is implemented in HDL and running on a popular EDA simulator.

Q: How far up the device hierarchy does this work? Is it a full cell phone, the chip, or a subsystem?
Little: A lot of the work is at the component level. People focus on one component at a time, instead of simulating every part of the system. The full system may come downstream, but most companies are structured by components. They work on their piece, with enough of the pieces around them that affect their project, but they don’t need to simulate the entire system.  They only simulate how their part behaves within the system.

Q: Will The Mathworks eventually bridge some of these other different pieces?
Little: Eventually, that will happen. We are working to close these flows now. We want to allow increasingly large and complex models to be put together.

Q: Does this need to run on a parallel system?
Little: It depends what you are trying to do. If you are trying to model an airplane, you don’t model it at the level of the electrons. And you may not need the air conditioning system as part of your model. A good system design breaks it down into pieces that you can work with. If you try to model an airplane at the electron level, you’re not going to have the computational ability to solve that. You must use the level of abstraction that fits your goal.  People frequently do have to use simplified models to deal with performance issues. We have been working heavily on parallel, distributed computers to allow people to run computations in parallel. Very often, with multiple test cases, you need to run them in parallel.

Q: But if you are designing a system, you now need to consider everything from what application will be running, how much leakage can you live with and what is your power budget. These are much different decisions than in the past, and these things have to run synchronously.
Little: In a given design, designers are often concerned with different domains. That’s what makes the task so complex.

Q: In addition, there are the physics issues such as how close can you put wires together and what is the effect on signal integrity. In simulating all of this, can you do it modularly to include all this?
Little: We have an integrated simulation environment in Simulink that ties together all of these domains, including a whole physical modeling family. They can work together under the Simulink environment. But in areas like signal integrity, we are not at the point where we can do everything yet. But we certainly have customers that are exploring how to do that kind of work using our tools.

Q: From your vantage point, looking out several years, how does the job of designing a chip change?
Little: Hopefully there will be more work done earlier in the design, so there is more time spent on designing and less time spent on implementing. One element to try to speed up the implementation is automatic code generation from the model and the algorithms. In our embedded markets, customers have completely embraced the concept of automatic code generation, and they can’t imagine working any other way. They don’t have time to write 50,000 lines of C code. In entering the EDA market, we initially introduced tools for the automatic generation of hardware description language. Looking out a couple years, we hope to see people writing less code and doing more work at the conceptual level. Of course, any new thing will take time to get adopted.  We also see the need for model-based-design, design with simulation, with continuous test and verification.

Q: Does this mean merging the design with the architecture?
Little: We are looking at that for the future. One example of that is the division of an algorithm between hardware and embedded code.

Q: Does that add programmability into the chip?
Little: The portability to different targets, whether the target is software or hardware, is an important element. You typically end up elaborating your model with target-specific information.

Q: Define target.
Little: I’m talking about a particular processor or hardware description language.

Q: Can that include time, as well? For example, if you design a cell phone now, you pretty much know at some point there will be a GPS component, right?
Little: You can certainly add parameters and come up with a set of variants.

Q: If I’m designing a chip today, what sorts of problems am I likely to encounter that I need to work out differently?
Little: A designer today wants to bridge gaps between different disciplines, such as signal processing engineering, image processing engineering, or the algorithmic portion. Tool developers need to collaborate with them in a way that produces more rapid design cycles and faster prototypes. There’s another segment of people who are familiar with The Mathworks tools and want to design an FPGA. This can provide an onramp to get them comfortable using EDA tools.

Q: Because of the enormous cost of producing an SoC, there’s a lot of hesitation on the part of developers to tape out chips until they have a buyer. Can some of this work be done up to a point, and then be ready to go quickly?
Little: Yes, and we see that happening already on the software side; I think it is easy to see the extension to the hardware design flow.

Q: This also lowers the barrier to entry for small companies, right?
Little: Innovation comes from all kinds of places. This is certainly lowering the cost of entry for someone to come in and say they have a great idea for a chip. If you need to get Venture Capital (VC) money to take a concept all the way to a fab to prove that it works, that’s a very different proposition than saying you have a model and it works.