When developing a complex, space-constrained board, a best practice is to first build and test a development board that won’t fit the final product (aka “non-form factor”). Only after that is working do you then reduce the board design to the intended size and shape for the end product (“form factor”).
Unfortunately, when the schedule gets tight, it can become tempting to skip that development board and go directly to the final form factor. The intent is to pull a round of “build and test” out of the schedule. But it rarely plays out that way if your board is moderately complex and has any significant size or shape constraints. In fact, it can end up taking longer and being more expensive. We call this “running with scissors” because it may seem faster on paper, but end up painful!
Reasons for this include:
- It takes longer to build your first board. It simply takes more time to work out the constrained component locations and traces. This in turn delays when you can start bring-up (getting the new board design up and running); a critical step in de-risking the design.
- It can also make that initial bring-up much more difficult, which equates to a longer and more expensive bring-up effort. In contrast, a non-form factor board can have space for additional test points or alternative components that won’t be necessary in the final design. It can also have space for hand-soldered rework, which can be especially helpful in early development.
- The delays in getting those first boards up and running also delay when your firmware team can begin running code on the target hardware. Given how much innovation can happen at the firmware level, this delays one of your critical teams.
- No matter how thorough your initial board design is, you will learn a lot during the bring-up of that first board, and you are likely going to want to make improvements for the final product. So you are generally better off getting your first board fabricated as early as possible by not going straight to form factor, and then having an opportunity to implement those learnings as you reduce the design to form factor.
It’s worth acknowledging a couple caveats to these points:
- These issues mainly arise if your board is complex and faces size or shape constraints. The more significant those constraints, the more the issues above are likely to trip you up. On the other hand, if your board is very simple or has no significant size and shape constraints, then there isn’t much difference between a form factor and non-form factor board.
- Following best practice and first creating a non-form factor development board improves your odds, but does not guarantee a smooth reduction to form factor later. There are risks at each stage of development, and a sound development process strives to address the right risks at each stage.
Early development should focus on major unknowns that can upend your product architecture. As development progresses, you should be addressing smaller risks with less serious ramifications. In the case of the development board, we want to ensure that all of the components are working well together, the underlying design is functional and to give the firmware engineers working hardware for development. Then as we shrink the size to form factor, the focus is on space efficiency and production scalability.
Going straight to form factor slows down that first step and carries too much risk into that first build. We have seen a few clients do this even on complex designs and more often than not, the “running with scissors” analogy has held true.