Selecting a CPU

You might question why, in a blog that is supposed to be about embedded software, I am considering the selection of an embedded CPU, which is clearly a hardware matter. It would be a fair question, except that, in embedded system design, the development of hardware and software are inextricably entwined, each having an influence on the other.

So, how do software considerations affect the selection of a CPU? …

There is an incredible number of embedded CPUs on the market today, so selecting the right one for a given project is a challenge. Here are some of the more obvious selection criteria:

  1. Computing power
  2. Power consumption
  3. On-chip facilities
  4. Price and availability

These are largely hardware oriented, except for computing power, because the amount of power needed will depend on the software being run.

There are some other criteria which may seem less obvious:

  1. Is the software team familiar with the CPU architecture?
  2. Do they have development tools for it [or are they readily available and good quality?]?
  3. Are simulation models available?
  4. Is the chip supported by the chosen operating system? [And any other software IP.]
  5. Are there low power modes available [critical if needed, but an overhead if not - only the software designers can say]?

This brief review seems to suggest that there are more software oriented factors in the selection of a CPU than hardware criteria. Although I would stop short of suggesting that the software guys should get to choose the device, I do think that a somewhat revised approach might make sense.

As the software development for most embedded systems is a bigger undertaking than the hardware design, it is obvious that work on the code should start first in order to meet time to market. That is easy enough. However, the further the software development has advanced, the more well defined the needs for CPU specification will be. For example, it may turn out that a design might benefit from the CPU having low power modes. However, this may not be apparent until a large amount of software design and analysis of use cases has taken place.

In other words, I am suggesting that the hardware design team hold off from the selection of the CPU until the last possible moment. That will give the software guys a chance to assess how much computing power [and memory] they will need and also what power management capabilities [like low power modes, DVFS etc.] will be needed to meet their design goals.

I have a feeling that this assertion may be controversial, but I would like to hear the arguments against it – email or comment are good.

Post Author

Posted March 17th, 2014, by

Post Tags

,

Post Comments

4 Comments

About The Colin Walls Blog

This blog is a discussion of embedded software matters - news, comment, technical issues and ideas, along with other passing thoughts about anything that happens to be on my mind. The Colin Walls Blog

Comments

4 comments on this post | ↓ Add Your Own

Commented on 19 March 2014 at 12:24
By Mariano Tisera

i feel that RTOS choose is the key for SOM (system on module) selection (i think, you can´t think in uC or uP you must think in SOM for the complexity of systems today) you can´t buy an RTOS or OS without BSP (board support package).
So you must choose a RTOS-SOM all at the same time, am i right??

Commented on 20 March 2014 at 10:19
By Colin Walls

I would agree Mariano.

Commented on 20 March 2014 at 17:35
By andrea battistella

Simulation models availability should be one of first aspects! In today environments THESE should be(/are in some cases) the means SW guys should use to evaluate different CPUs before taking a decision (and cherry on the cake pre-developing and pre-verifying SW developments reduce product development time and mitigate risks!).

Commented on 21 March 2014 at 09:34
By Colin Walls

Very good point Andrea. Fortunately models are available for the majority of embedded CPUs.

Add Your Comment

You must be logged in to post a comment.

Archives