Wed Jun 12 13:46:55 EDT 2013

Industry integration: validated, bottom-up design

I'd like to be able to integrate what I've learned up to now (the
knowledge that lead to RAI) and steer it more into a direction that is
usable in an industrial setting.

At this point it is usable for designing music DSP software on PCs or
mobile devices, but not yet so usable for machine mapping as would be
encountered in a typical embedded development settings, i.e. the
projects that pay the bills.

One important element is target dependency.  It might make more sense
to construct a tool that helps manual machine mapping of an existing
algorithm, than to attempt to work top-down as I'm doing for the synth

At least for code running on a quirky DSP chip there is going to be a
significant amount of squeezing involved to map to a particular
target.  It doesn't seem that the trend of quirky hardware is not
going to change much in the near future, as power consumption and
device cost constraints will keep much of the manual design approach

For the big guys, there are plenty of expensive tools available.  Have
a look at the MathWorks product range.  More, bigger tools can be
found in the ASIC industry.  For the small guys doing one-off jobs,
these tools just too expensive.  What I've been wondering for 10 years
is how far can one get with open tools to make the lone wolf embedded
developer more productive?

I want to stress this: none of the ideas here are new.
What is new is to keep it simple, small and malleable.

A large constraint in reality is the introduction of exotic tool
chains.  My conclusion is that people hate it: it's too big a risk to
use yet another quirky code generator whenever a new person joins the
team.  A big constraint for designing tools is to make sure they can
get out of the way, i.e. that you can switch them OFF and drop down to
writing straight ASM or C code.

In a nutshell: VALIDATION of a low-level implementation is more
important than GENERATION from high to low level.

In practice, in the RAI framework, this would boil down to finding a
set of primitives, probably based on the machine's primitive, AND a
set of machine constraints and resource management annotations.

This is not a simple problem.  To keep it simple, a most
straightforward approach is to start with a reduced assembler
language, and see how to put a functional semantics on top of that.

So what about this for future direction:

  - Aiming at validation, use the abstract interpretation trick to
    approximate the semantics of a real device.

  - Pick a target to test this: dsPIC or ARM DSP / Cortex M4