feature article
Subscribe Now

From Concept to Code

Mathworks Bridges a Critical Gap

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.

One thought on “From Concept to Code”

  1. @jordanDSP: thanks for the comments & questions. I’m the Product Manager for MATLAB Coder with MathWorks; let me see if I can answer your questions.

    MATLAB Coder does not rely on templates for code generation. It performs a semantic analysis of your MATLAB code to determine C types for all of your data and operations – hence, it can perform non-syntactic operations, like fusing adjacent loops, converting multiplies in a loop into additions (strength reduction), inline function calls, and eliminate unreachable code to name just a few.

    In a typical system development workflow, most of the constant code tweaking (after an initial version of code is completed) is due to changing algorithm/system requirements and trying to achieve numerical equivalence with the golden reference algorithm design. By staying within MATLAB, and working with your MATLAB code to improve the generated C, you keep all the visualization & verification benefits of MATLAB. Once your designs are relatively finalized and you want to introduce code optimization that just couldn’t be obtained through code generation, then there may be value in manually modifying the generated code – the downside, however, is that the linkage between the generated code and original MATLAB designs are now broken.

Leave a Reply

featured blogs
Oct 15, 2018
The talk of the town in the DRAM market (well, apart from its growth in the last couple of years) is DDR5. You might assume from the talk that JEDEC has finalized the standard, but it is actually technically still in development. I believe that the final standard is still exp...
Oct 14, 2018
  The deep learning revolution is the most interesting thing happening in the electronics industry today, said Chris Rowen during his keynote speech at the Electronic Design Process Symposium (EDPS), held last month at the Milpitas headquarters of SEMI, the industry asso...
Oct 12, 2018
In September, we spent some time focusing on our checkout process, continued to improve our industry standards experience, and released a few new content pages. We also rolled out the first version of our new Samtec Cares website. More on these and the rest of the major updat...
Oct 8, 2018
Augmented technology has broken into the mainstream, with popular apps such as Pokemon Go, Snapchat and Instagram face filters available to anyone with a smartphone. The next step in the wave of AR...