Even if not all engineers will admit it, debugging an embedded system prototype is a lot of fun, so long as it’s going the way we planned. And while we cross our fingers hoping our board passes the first article inspection, it’s inevitable that some bugs will find their way into a design of any complexity.
The debug phase in an embedded design can be one of the most challenging tasks for an engineer, as we juggle identifying issues with a project deadline that was almost always due yesterday. And like any good bug, they’re unpredictable, with some taking 10 minutes to solve, and others months. So what can be done to minimize the time spent on the debug phase of your embedded design without bugging out?
The Problem with Complexity in Embedded Design
Solving problems that arise in your embedded design isn’t getting any easier, especially as board space requirements shrink, design complexity continues to increase, and integrated circuits become more sensitive than ever to jitter, crosstalk, and electromagnetic interferences as their size goes into single digit nanometers.
With engineers mostly interested in the design phase and the functional tests that meet design requirements, the debug phase is usually one of the most ignored parts of a design workflow. The problem with this strategy is, the PCB is where all early decisions converge together, and also where most of unforeseen problems originate. Because of this, careful planning is required at this stage in your design flow to prevent a nasty debug session later down the road. Here’s two methodologies to do just that:
Design for Testing (DFT)
We all expect our manufacturers to deliver a board that meets our specifications, but how can they ever do so without complete visibility into your design intent? You can’t get by assuming that fabrication will be a flawless process so long as a manufacturer just focuses on the functional aspects of your board, they need more details, and this is where DFT comes in.
Without providing a test engineer with access to test points on your board, it can be almost impossible to ensure the reliability and functionality of your board. The solution to this is simple - make it a habit to incorporate contact points for flying probes on your board to test all of your circuitry.
There are instances where you can’t avoid missing critical test points with high-frequency designs. In these situations, matching impedances sometimes forces you to make small component pads, such the 0201, even smaller than they are, leaving no extra real estate for a test point. For these situations, there are some adjustments you can make to open up the area for test probes, including:
Leaving a strip of solder mask at the end of the component pad
Not covering the entire via pad with solder mask
Using just the exposed copper portion left open as a point for a test probe
This process can take a few steps to get done right, but with the right ECAD tool you’ll be able to easily communicate this requirement to your fab house. And with the right DFT functionality in your PCB tool, you’ll be able to easily define test points for any level of design complexity without becoming another statistic.
|PCBs that don't give manufacturing critical access points risk resulting in very low test coverage (30% or less) and miss much needed critical testing. Adequate test probing coverage should be at least 70% accessible.|
Design of Experiment (DOE)
As we push PCB design and manufacturing techniques further, it’s becoming more important than ever to be able to test and validate these new techniques for the next generation of embedded systems. Experiment designs, or Design of Experiment (DOE), is a method that can help you during the prototype stage to experiment with how well a new design will work in reality.
These experiments run on an either a fully controlled or partially controlled simulation and involves changing one variable while everything else remains the same. During this objective experiment, data is collected as the manufacturer goes through the different test varieties until the desired outcome is achieved. The experiment can range from changing solder powder to modifying the chemical formulation of your flux.
As an engineer, it’s important to be aware how limitations in physical manufacturing can limit or hinder your brilliant ideas. Design of Experiments makes this translation process easy by allowing you to weed out any potential limitations that might involve special processes, manufacturing constraints, or even the law of physics coming into play.
When might you find yourself needing to use DOE? Take for example your board being so dense that there is simply no room for thieving (ground pouring). You might even have a package-on-package arrangement on your design (since the board real estate is maxed out), and with no copper overlay to dissipate heat, it becomes a real challenge for you as a designer to resolve these kinds of issues. By incorporating a Design of Experiment into your board process in this example, you can understand early on what kind of manufacturing challenges you might encounter well before your deadline approaches.
Stop Bugging Out
No matter what embedded design you’re working on, it’s inevitable that bugs will make their way into them, and it’s your challenge to resolve them while still meeting your project deadline. Of course, the above methods are not the only strategies out there that can help with early planning to reduce the risks of a lengthy debug phase, but they do provide a good starting point. There are always tradeoffs for whichever methodology you choose, whether it’s cost or the complexity required to implement it, but having a strategy will save you a lot headaches, and a lot of money down the road.
Want some more strategies on how to design a board that gets manufactured right the first time and will help you mitigate the risks of your debug phase? Sign up to listen to a recording of our Design for Manufacturing webinar - Maximizing Your PCB Production Yield.
 Faisal Ahmed. "Overlooking Design-for-test Can Lead to Costly PCB Design Rework." N.p., 02 June 2014. Web. 20 Sept. 2016. http://www.embedded.com/design/debug-and-optimization/4430502/Overlookin....
About the AuthorMore Content by David Marrakchi