Math is beautiful.

It is likely that mathematics is the closest thing we have to Pure Truth.  Math has no moods, no bias, no political leanings, and no religious convictions.  Math is a wonderful set of self-consistent rules that pays homage to nobody and expects nothing in return. 

Math is also a cold, hard arbiter – with neither soul nor compassion.  Math has no friends, lovers, allies, or enemies.  Math is distant and dispassionate.  Math has no morals and Math owes no debts.

Math goes wrong, however, when we try to bend it to our whim.  We can create something wonderful in pure math but reap the cataclysmic consequences of pure evil when we represent that thing in an imperfect approximation – like software.

For many of us, our engineering solution begins in pure Math.  We use a tool like MATLAB to model our system, abstract our solution, and see the expected results.  We trim, tweak, and tune until we behold perfection.  Our algorithm solves the problem.  Now we just need to implement it.

At this point, many mathematicians throw the equations and graphs over the wall to a programmer, who tries to capture the intent of the Math in software.  The programmer has some decidedly imperfect tools with which to work, however.  Will a 16-bit approximation work for this value?  Can it be fixed-point?  Does iterating a hundred times approximate infinity?  How about a thousand?  A million?  How much precision must our constants have?  How forgiving our rounding and truncation?  When our processor divides this infinity by that one, will it know which one was larger?  Does interpolation get us close enough?

When we go from algorithm in a tool like MATLAB to implementation in software, many designs face difficulty.  The intent of the equations isn’t always clear.  Many errors are made in translation.  Since different individuals are often involved in the two steps, confirming that the desired results are achieved can be tricky. 

Wouldn’t it be cool if we could automatically generate code from our MATLAB models so we could verify the implementation directly?  Then, when we go back later and change our mind in MATLAB, wouldn’t it be awesome if those changes were propagated straight through to the code?

MathWorks apparently also thought it would be very cool, so they are announcing a new set of capabilities called MATLAB Coder that automatically generates C and C++ code directly from the MATLAB language. 

Hey, haven’t we heard about this capability before?

No, you’re thinking of the code generation in Simulink.  This is different – it goes straight from MATLAB.  With this announcement, however, the Simulink code generation products are being consolidated as well.

MathWorks has been working for a while to solve a problem.  That problem is that Math is useful in a wide range of situations – from very low-value situations like Johnny’s differential equations term paper to very high-value situations like creating signal processing algorithms for next-generation mobile communications equipment.  With a general-purpose tool like MATLAB, Johnny derives a value of about ten dollars, whereas the communications company might see a value of millions.  The problem, then, is how do you price a tool that will do what Johnny needs for a reasonable price and still extract some tiny fraction of the value it brings to the communications company?  

MathWorks does this by high-value add-ons like Coder – and also like Simulink, for that matter.  When you’re doing industrial-strength Math, you almost always end up having to implement it in some physical apparatus.  MathWorks can give you tools that will make that job much easier, but it’s going to cost you a bit. 

In signal and image processing, communications, and other algorithm-intensive applications, system-level engineers have long used MATLAB as their design and modeling tool.  Automation of the process to convert those algorithms into C or C++ for the next stage of development can potentially save a bunch of development time.  The iterations between algorithm and implementation can be time-consuming and error-prone.  Removing the need to manually re-code those changes in C++ tightens that iteration loop considerably and eliminates many of the potential sources of error. 

Using Coder, the design engineer maintains one master source copy of the design – in MATLAB.  The C or C++ versions are derived from that automatically – according to a set of configurable rules set up by the design team.  As you might expect, coder builds not just the code but also all the required accessories – libraries, executables, etc.

Coder supports a broad set of MATLAB language features – although not absolutely the entire set.  MATLAB’s language is rich and abstract, and not everything translates reasonably to conventional C code.  

The temptation and hazard with this process is the attempt to edit or tweak the resulting auto-generated C or C++ manually.  That would be bad.  The integrity of the iteration process is assured only if the golden source of the project remains the MATLAB copy, and the derived C code is treated almost as an executable.  When you want to make changes or fix bugs – go back and do it in MATLAB.

For many embedded designs, the trickiest part is the heavy-lifting algorithms.  Having a rich environment like MATLAB where we can directly analyze the source code – and then automatically generate matching device-level software without the requirement of manual translation and interpretation – could dramatically simplify the design process, and improve the results. 

MathWorks says that Coder is not specifically designed to generate code that can be taken through C-to-hardware design flows for designs where the algorithm requires hardware acceleration.  While this flow might work in some cases, you’re on your own at this point if you want to try it.  The difficulty would most likely be coding style – C-to-hardware tools like high-level synthesis tools typically expect their source code to be written with a particular coding style, and that style can have a dramatic impact on the results.  With auto-generated code, you lose the ability to manipulate the subtleties of the style of C, and the chances are your generated hardware would not live up to your expectations. 

For embedded software, or software targeting DSP processors, however, Coder could be just the ticket we’ve been looking for.  Now we don’t have to use Simulink if we want automatic code generation. 

If we are using Simulink, however, MathWorks has just improved our situation a bit as well.  The company is combining Real-Time Workshop and Stateflow Coder into a new product called Simulink Coder.  For embedded design, they are combining Real-Time Workshop Embedded Coder, Embedded IDE Link, and the Target Support Package – all into a new product called Embedded Coder.  

There doesn’t look to be a lot of new technology in all this, and that’s good news.  MathWorks code generation from Simulink has been working well for a wide range of customers for years now.  That means those of us adopting these capabilities won’t be test pilots.  However, the ability to generate code from MATLAB as well as the more sensible packaging of the code-gen capabilities in Simulink will be a welcome change for many design teams.