Hardware and software no longer matter. What counts is functionality. This new reality demands new thinking and a new design flow.
The typical DSP design process has three basic elements: Algorithm design, hardware design, and software design. Similarly, most DSP engineers think of themselves as belonging to one of three groups: Algorithm designers, hardware designers, or software designers.
This division of labor causes problems. For one thing, it creates a "thought gap" between the engineering groups: Algorithm designers rarely understand how the hardware works, the hardware designers rarely understand how software development works, and so on. In addition, each group tends to limit its thinking to its own area of specialization. For example, software designers don't want to worry about hardware design; they just want a hardware platform that works. This narrow thinking hinders the groups from aiding each other. Perhaps worst of all, each group uses different tools, languages, etc. As a result, miscommunication between the groups is common.
To solve these problems, we must stop thinking in terms of hardware and software, and instead think in terms of functionality. The key to doing this is to start by building a functional model if our systems. ASIC design has been moving down this path for several years. The electronic system level (ESL) approach starts with a functional model specified a high-level language (typically SystemC), and uses this model to generate hardware and software. (Note that ESL means different things to different people.) The FPGA design process has also started to move in this direction.
Those of us who don't work on ASICs or FPGAs—which is most of us—don't need to worry about generating hardware. However, there are still great benefits to generating software from a functional model. Happily, it is now possible to do so. For example, it is possible to convert a SimuLink model into DSP code. The trouble with approaches like these is that they tend to overlook the constraints of the hardware. For example, the functional models have no notions of cache misses, DRAM access latencies, system bus contentions, etc. (This is not the case with ESL, which models both hardware and software.)
Given this problem, I am intrigued by the work being done at Mirablis. This company's tools let you model memory systems, buses, and many other components. This is a company to watch closely. They understand the importance of thinking in terms of functionality, which is not something I can say for every tool vendor.