Section 1.4 Top-Down Design and Bottom-Up Implementation
In embedded system projects, it is important to design before writing code or wiring up hardware. Rather than diving in head first by wiring and writing code, it is important to first understand the problem. Break down the project into as many modules or parts as you can think of and consider how they interconnect or interrelate. This is called top-down design (as if you are looking at the project from above and looking at each individual part). Once each module or part has been defined, then design and implement each one individually, rather than trying to tackle the entire project at once. This is called bottom-up implementation.
The top-down design process is described below.
-
STOP - do not write any code yet!
-
Understand the problem completely
-
Specify requirements
-
Think about possible errors
-
Think about the “what,” not the “how”
-
Don’t get caught up in minutiae
-
Break the problem into parts, then break those parts into even more parts
-
Draw a block diagram of all parts and how they interrelate
-
Refine details as necessary
When implementing the design in a bottom-up processes, implement one subsystem at a time. Start with the simplest subsystems first. Ensure that each individual subsystem operates as expected before connecting them together.
At every step, it is important to keep detailed documentation of the project. Engineers keep notebooks in order to record ideas, thoughts, requirements, things that don’t work, and things that do work. [16.22]
The benefits of this design strategy is that it helps to clarify the problem. You can’t design something if you’re not completely sure what it should do. In addition, as parts get broken down into smaller pieces, they become less complicated. You may realize that parts of the solution may be reusable (e.g. a module built for one component may have code that can be used elsewhere in the design). Finally, when breaking a system down into parts, more than one person can work on the solution.
