Since Einstein, we’ve come to realize that more and more things depend on relativity. This is true not just in physics, but also in more human arenas like marketing and sales. Our perception of something like – FPGA tool prices, for example – might depend on whether we’re coming from an EDA background – which says that high-quality design tools cost tens- to hundreds-of-thousands of dollars for a license, or from a mass-market software background – which says that software goes for tens to hundreds of dollars a pop.

Both of these are valid perspectives. EDA companies have to charge what they do to fund the enormous engineering effort required to develop highly-sophisticated tools for a relatively small audience. Developing a good EDA tool is a much more complex undertaking than, say, the latest version of Angry Birds, and the cost of that complexity is amortized over an audience thousands of times smaller. The result – one piece of software might cost $5 and one might cost $500,000.

If we switch our relative view to the companies providing this software, the effect can be jarring. What if, for example, you’re MathWorks? You have made your fortune selling mass-market software to the target demographic of “people who do math.” You have the sales and support channels to handle lower-price, large-volume software transactions and customer support. Then, you discover the FPGA (or more broadly, the electronic system design) market – people who really need the advanced capabilities of your software and who can derive enormous value from its use. If you’re smart, (and these MathWorks folks certainly are), you find a way to extract more value from this new market than by simply flooding it with your commodity-priced basic software tool. You add market-specific capabilities and features and even develop new, higher-priced tools and IP that more specifically serve the needs of this high-value area. 

It’s like discovering a gold mine!

If we switch our view to that of a typical large EDA company – we have our highly-compensated sales account managers who spend all of their time and energy on a single large account. Their main goal in life is to make the next 3-year renewal be a few million dollars more than the previous 3-year renewal. Their secondary goal in life is to play lots of golf. In third place, and in support of goal #2, is to have the fewest possible users of their software at the current revenue level (so their AEs are not swamped doing actual customer support and they can concentrate more on their golf swing).

In this model, EDA companies are primarily selling very expensive licenses to a small number of actual users in a few very large companies.  They are not set up well for large numbers of small-budget transactions. They are not well-equipped to support thousands of end users directly. When they see that FPGA tools are low-priced (even free, sometimes) and require huge amounts of support for often under-trained users, they’re not too happy. They’re trying to sail a battleship up a creek. There’s just not enough room to maneuver.

It’s like accidentally wandering into a slum. 

Somewhere in the middle of the gold-mine/slum continuum, of course, is the truth about the FPGA tools market. But the relativistic effect is that MathWorks sees the opportunity and mainstream EDA sees the challenges. As a result, MathWorks continues to make bank on selling tools to FPGA designers – with the full cooperation of the FPGA companies themselves, and even of big EDA. Everybody wants to support a design flow that starts in MATLAB or Simulink. Model-based design? We’re all for it. Here are our nice interfaces. 

Now, MathWorks is elevating their game even more. First, they established MATLAB as the go-to tool for doing math – and specifically in the FPGA space, for doing things like development of DSP algorithms. Next, they introduced Simulink and a plethora of interfaces to facilitate model-based design of a wide variety of electronic systems and modules. Now, they’re expanding their portfolio of IP and raising the level of abstraction with domain-specific offerings that solve highly-complex problems right out of the box.

Last year, the company upgraded both of their flagship offerings for electronic system design – MATLAB and Simulink. Simulink got a facelift with a new look-and-feel aimed at enabling model-based design. MATLAB got a rework as well – with features aimed at allowing us to customize our environment around plug-ins and frequently-used features. Thus, the general-purpose “I wanna do some math” user can have a distinctly different user experience than the “I’m doing high-performance DSP on FPGAs” user. 

The interesting thing about MathWorks solutions is that they manage to stay in the users’ system domains rather than connecting too closely with specific implementation technologies. You can start a design in their tools and experiment before deciding whether the target technology should be software on a conventional DSP processor, an FPGA, or a GPU. Those design decisions can be delayed until you have a better understanding of the properties of your algorithm and the type of acceleration and flexibility your application will require.

As an example: recently, MathWorks announced upgrades to their “Phased-Array Toolbox” and their “SimRF” to “help wireless communications and radar system designers to model increasingly complex scenarios with greater accuracy and performance.” These tools allow wireless designers to get right down to business, modeling complex systems and thinking about antenna beam patterns rather than esoteric details of design and modeling tools.

MathWorks’ conquest of system-level engineering represents a stealthy takeover of one of the most critical parts of the electronic design automation market. As the back-end of the design flow becomes ever-more automated, users will spend an increasing amount of their design time and attention interacting with tools at the system level – making tradeoffs and compromises above the level of technology-specificity where most mainstream EDA tools kick in. In the FPGA design flow in particular, the gap between that level and the level of the design tools provided by the FPGA vendors themselves has dropped to nil, squeezing out much of the territory previously occupied by commercial EDA companies.