Turning software into hardware

Clive Maxfield
(03/02/2005 1:42 PM EST)

  I'm not quite sure what's happening, but 2005 seems set to be a bumper year for incredibly cool ideas. For example, I was recently chatting with the folks from CriticalBlue about their Cascade product, which synthesizes hardware from embedded software. <P> Now we've got to be very careful not to get confused at this point, because there are a variety of different techniques for translating software code into hardware. For example, a number of EDA companies have behavioral synthesis offerings that can synthesize representations created in SystemC or different flavors of C/C++ into RTL, or directly into gate-level or FPGA-level netlists.

But that's not what we are talking about here!

In order to understand just what it is that CriticalBlue does, we first need to take a step back. Let's assume that we are part of a team designing an SoC containing one or more ARM processor cores. In this case, while the hardware guys and gals are scampering around performing their magic, the software folks are slaving away in their cubicles capturing their jolly cunning embedded applications. <P> Once the software folks have created an application in C, C++, or the language of their choice, they compile it down into the raw machine code that will be executed by the ARM processor(s). As part of this process, they will use a profiler tool to see how fast the software will run and where the program is spending the bulk of its time.

When the profiler identifies specific functions that simply can't be made to run fast enough in software, then these functions have to be deleted from the software tree and implemented in hardware. In the case of a conventional design flow, someone has to write specifications for the design engineers to use in creating what are typically fixed-function hardware implementations of these functions. <P> Creating these specifications can be a real pain, because the hardware and software folks tend to think about things in completely different ways. And then there's the problem of interfacing these hardware functions with the rest of the software application. Be afraid, be very afraid.

CriticalBlue to the rescue

This is where CriticalBlue leaps onto center stage with Cascade. First of all, Cascade is non-intrusive in the design flow. We use the same compiler, debugger, and profiler applications that we always do. However, Cascade augments the environment as follows: <P> Imagine, if you will, a really simple interface. Cascade reads in the compiled machine-code version of the embedded application along with all of the information from the profiler. On the left of the interface we have a list showing the names of all of the functions forming the embedded application. <P> Based on the results from the profiling run, we know that functions "> If we wish, we can also use the interface to specify constraints, such as the maximum number of logic gates or the maximum number of clock cycles we wish to use (alternatively, we can simply leave these nitty-gritty details up to Cascade).

At this point, we need to leap a little bit ahead of ourselves. What Cascade is eventually going to do for us is to take the embedded software functions we've selected and generate two main outputs: the RTL to implement a custom co-processor, and the microcode to run on this co-processor (Figure 1).

But before we get to that point, Cascade presents us with a selection of candidate architectures. We can pick an architecture that looks interesting and analyze it in more detail, such as seeing exactly how many clock cycles will be required for each of the off-loaded functions. If we wish, we can play with the constraints, off-load additional functions, examine different candidate architectures, and so forth.

Figure 1 — Cascade generates the RTL for the co-processor and the microcode to run on the co-processor (plus testbenches and synthesis scripts).

Once we've made our decision, we press the "Go" button and out pops the RTL for our custom co-processor and the microcode to run on that processor (all of the interfacing between the two processors is automatically handled by Cascade). But wait, there's more. Let's suppose that we actually fabricate our SoC, and — just as we get the first devices in our hands — someone comes running in saying "Oh no! I just heard that the software algorithms have been changed!"

And of course, we just know that one of the "Tom", "Dick", and "Harry" functions we off-loaded is going to be one of the affected functions. Well, fear not my braves, because we can instruct Cascade to keep using an existing co-processor implementation, and to simply generate new microcode to run on that co-processor (I told you it was cool!)

A few more points to ponder

In fact, the more you think about this stuff the cooler it gets. Let's consider the world from the perspective of the embedded software developers. Their standard development environment tells them everything about how their code performs in glorious Technicolor, including the functions that are going to cause problems.

Using conventional design flows, the software folks have no way to tell if the hardware guys and gals can actually build these functions in such a way that they will run fast enough. Now, with Cascade, even if the software guys don't know anything about the hardware, they can use the tool to see if the hardware can be constructed. And they can also play "what-if" games by moving different functions back and forth between the software and hardware domains.

Meanwhile, the hardware folks now have a real easy way to create hardware implementations of software functions without requiring any deep understanding as to what these functions actually do. Having said this, the hardware folks can use Cascade to evaluate different design tradeoffs, such as playing with cache sizes and experimenting with different candidate architectures.

I don't know about you, but I'm impressed. This is one of those ideas that — when you see it — you think "Well, that's obvious isn't it," but you also kick yourself for not thinking of it yourself. The software content of embedded systems is increasing at a ferocious rate, so it seems to me that this technology is in absolutely the right place at the right time, and I am delighted to present it with an official "Cool Beans" award. Until next time, have a good one!