Bottom Up or Top Down?

By Colin Walls

Embedded Software Technologist

June 16, 2020


There are, broadly speaking, two distinct approaches to the design of software: bottom-up or top-down.

There are, broadly speaking, two distinct approaches to the design of software: bottom-up or top-down. It is most common to approach it top-down. Design, say, the user interface first and the underlying functionality afterwards. The implementation of the design – the actual coding of the software – is another matter.

There is some logic to doing the implementation top-down – following the logic of the design. This would involve creating the high-level functions first (like the user interface) and leave the lower-level functions as “stubs,” initially. When developing desktop software, I have always liked this approach, because initial progress seems rapid; the software “comes alive” and does something visual early on. There are clear psychological benefits here.

With an embedded software application, this is less likely to be possible for two reasons:

1)The lower-level software (start-up code, operating system, middleware, drivers etc.) needs to be in place before anything can really run.

2)All embedded systems have limited resources.

It is the second reason that really drives a bottom-up implementation. There is normally a fixed amount of memory, a specific amount of CPU power and a power-consumption (energy) budget. If the software is developed top-down, as resource limit may be hit at a late stage in development, when there is little opportunity to address it.

Developing the software bottom-up entails the creation of a series of increasingly complex components. The resource utilization of each component can be measured and optimized straight away, which mitigates the possibilities for surprises at a later stage. The measurements need the right skills and tools:

  • Memory footprint is normally easy to read from the linker map. This is a zero-cost option, that simply requires the engineer to be aware of the requirement.
  • Measuring the performance (speed) of software is more challenging. An instrument like an oscilloscope was traditional but is a rather frightening option for many modern developers. Using CPU tick timers or instruction-accurate simulation tools are other options.
  • Power consumption is an increasingly important facet of embedded software development. Power measurement tools should be available to enable developers to optimize the power profile (CPU voltage/frequency, peripheral shut-down and standby/hibernate usage, for example) to be fine-tuned.

I am sure that there are other perspectives and arguments against my proscription ...

My work in the electronics industry spans nearly 40 years, almost exclusively with embedded software. I began developing software and managing teams of developers.Then, I moved to customer roles, including pre-and-post sales technical support, sales management and marketing. I have presented at numerous conferences, including Design West, Design East, Embedded World, ARM TechCon, and my work frequently appears on

More from Colin