‹header›

‹date/time›

Click to edit Master text styles

Second level

Third level

Fourth level

Fifth level

‹footer›

‹#›

Getting back to this next level of abstraction, a large portion of the embedded market will go up to the next level of abstraction, that of designing with IP and programmable cores. In fact, they already have, and will continue to do so.

Let’s go through an example of designing an embedded system using programmable and non-programmable IPs. Here is a typical embedded application, that of engine control for an automobile to achieve low emission and fuel efficiency. The operation of the engine controller can be partitioned into three different processes. The first process computes air flow from throttle position, engine speed, air temperature, and air pressure. The second process takes the air flow and the engine temperature, go through some table look-up to arrive at the injection time. The third process compute the pulse width modulation signal from the injection time and actually control the fuel injection.

We can implement this application with an architecture consists of a 32 bit microprocessor.

We will need to implement all three processes on this 32 bit CPU. It is probably pretty easy to do, hence better time to market. But it may or may not meet timing constraints.

Alternatively, we can also consider an architecture consists of an FPGA, or an ASIC that will do some of the more timing critical stuff.

Specifically, actuation of the injector can be mapped onto an FPGA for faster processing time. Since the CPU has less to do, now we can use a smaller CPU, say a 16 bit CPU which may do the job.

Lastly, we can consider an architecture that consists of an additional Digital Signal Processor

And have the initial data processing done by this digital signal processor. We can then choose an even smaller CPU, since it is now only used to compute injection time. The actuation is still relegate to the FPGA for timing constraint satisfaction.

For this simple case, we can have least the three different architectures, all trying to implement the same application, that of controlling an engine. The central question to ask is: “If I change my architecture, will I still have a correct implementation?” In fact, what is the precise notion of correctness? The notion of correctness, though extremely important, is not formal in general and not even clear for embedded systems implemented on heterogeneous architectures like these ones. Furthermore, even if we have a notion of correctness, we have to answer the question of “How do we check for this correctness?” Do we have to check exhaustively? Is it possible to accomplish this efficiently?

A designer designing in Polis will first capture the behavior they want.

Independently, the architecture is constructed and characterized.

The designer then go in and mapped behavior onto architecture and only at this time can he verified the performance. If he likes the performance he sees, he can go down to automatic synthesis, and then the synthesis result can be back annotated for further analysis.

So, let’s get to work!

Thank you.