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.

Want to stay up to date on news from Siemens Digital Industries Software? Click here to choose content that's right for you

Comments

0 thoughts about “Selecting a CPU
  • 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??

  • 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!).

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.sw.siemens.com/embedded-software/2014/03/17/selecting-a-cpu/