PCB Engineer: Top 6 PCB Design Mistakes

Let's face it. We all make mistakes, and PCB designers are no exception. And contrary to popular belief, making mistakes is ok, as long as we learn from them. Here is a quick summary of some common PCB mistakes. 

Choose the wrong PCB design software

Confucius said, “A man who does not plan long ahead will find trouble at his door.” This applies to PCB design too. One of the first steps to successful PCB design is to choose the right tools. There are many powerful and easy-to-use electronic design automation (EDA) software packages available for PCB designers today. Each one has its own unique capabilities, advantages and limitations. You should also be mindful that no software is infallible, so issues such as component footprint mismatch can and do occur. Although there may not be a single tool that meets all of your needs, you should do your homework to find the best fit for your requirements. In my previous post, I did a research about which PCB design software is better, there are many different answers, but you can take them as reference.

Poor communication with designer and/or manufacturer

Even though out-sourcing of PCB design is becoming more common, and is often more cost-effective, it might not be the ideal solution for highly complex PCB designs where performance and reliability are key. As the complexity of designs increase, the face-to-face time between the engineer and PCB designer to ensure precise component placement and routing in real-time becomes very important and can help to eliminate costly rework later. 

It is equally important to engage the PCB board manufacturer early on in the design process. They can provide initial feedback on your design to maximize efficiencies based upon their processes and procedures that will save you time and money in the long run. By making them aware of your design objectives and involving them in the early stages of PCB layout, you can avoid any potential problems long before going into production and shorten time-to-market.

Failure to test early prototypes

Prototype boards allow you to prove that your design works according to your original specifications. Prototype testing allows you to validate the functionality and quality of the PCB and its performance before it is mass-produced. Successful prototype testing requires a good deal of time and experience, but by starting with a robust test plan and a clear set of objectives evaluation time can be decreased, and the likelihood of production-related mistakes reduced. If any issues are found during prototype testing, a second iteration of tests on a reconfigured board will need to be performed. By including high-risk elements early in the design process, you will be able to benefit from multiple iterations of testing and identify any potential issues early on, reducing risks and ensuring project deadlines are met.

Using inefficient layout techniques or incorrect components

The demand for smaller and faster devices requires PCB designers to layout complex designs in significantly reduced footprints using smaller components that must be placed closer together. Making use of technologies such as embedded discrete devices on inner PCB layers or smaller pin pitch ball grid array (BGA) packages will help to reduce the board size, improve performance and leave room for rework when issues are encountered. When working with components that have higher pin count and smaller pitch, it is important to select the right board layout technique in the design stage to avoid problems later on and minimize fabrication costs.  

Also be sure to carefully study the range value and performance characteristics of any substitute components that you plan to use, even those that are labeled as drop-in replacements. A slight variation in the characteristics of the substitute component may be enough to throw off the performance of your entire design.

Forgetting to back up your work

Back up your important data. Need I say more? At a minimum, you should backup your most important work and other files that would be difficult to replace. Even though most companies perform daily backups of all corporate data, this might not be the case in some smaller companies or if you do work from home. With backing up to The Cloud so easily accessible and cheap these days, there is no excuse not to backup your data where it is safe from theft, fire, and other local disasters.

Becoming a one man island

In my early days as a programmer, I remember thinking that we spent way too much time in code design reviews. But I have to admit that looking back now they really were a very important part of the process, just as they are with PCB designs. While you may think your design is flawless, and that making mistakes is simply not your style, often times your peers will find something in your design that you overlooked. Sometimes, even though you know the intricate details of the design, someone less intimate with it can be more impartial and provide valuable insight. Holding regular design reviews with your peers can help detect unforeseen issues and keep your project on track and within budget. 

How about you? Have you made some PCB design mistakes in the past that have made you a better designer today? Feel free to comment and provide a few more mistakes of your own so that others can learn from them too.

Baggio WANG FAN

SHENZHEN JAAPSON TECHNOLOGY CO LTD

baggio@jaapson-pcb.com  

www.jaapsonpcb.com

skype: baggiowang0214

JAAPSON, Expert in HDI Multi-layer PCB Manufacturing

Debug approaches and technology development

Although embedded software developers would like to think that they spend the bulk of their time designing software and coding it, that is not the case. Almost everyone actually spends more time getting the code to function correctly - a process that we call "debugging". Different people have different ideas about what debugging actually entails and, with the advent of multicore designs, new challenges are presented. This article reviews debug approaches and technology and considers what is likely in the future.

What do you do?
If you met someone in a bar, say, and you got talking, they are likely to ask what you do. You will probably reply that you are an embedded software developer. If they carry on talking with you, they might ask you what that job entails and you would probably answer with something about designing software and writing C/C++ code. Of course, that is not really the case. Most embedded software developers spend the bulk of their time debugging.

This does beg the question: what does debugging actually mean? The answer is less simple than you might expect.


Debugging by hand: debug in the past

Many years ago, when computers were big and expensive, there were no debugging tools that we would recognize today. Frankly, programmers made fewer errors. One reason for this was that time on the computer was precious, so the programmer would write the code down on paper first, thinking it through very thoroughly. They would very carefully proof read to avoid syntax errors, as just one slip could waste a computer run. Then they would think through the operation of the code, dry running it on paper to check the logic. Eventually, this carefully scrutinized code would be submitted to the computer. After the run, the results would be studied and, if an error was detected, the code would be modified to include extra printf() (or equivalent) lines to show how values were changing. By using conditional compilation, "debug" and "production" versions of code could be compiled.

So, why not take this approach when writing embedded software today? The first part - writing the code on paper and thinking a lot - might be a very good practice. However, the ready access to computers that cost almost nothing has moved us away from such an approach. The practice of adding printf() calls to log values is still amazingly common, despite it being quite problematic for embedded applications. 

There are five key issues:

1. Most implementations of printf() are quite large. The function needs to address a very wide range of formatting situations and that takes a lot of code. This does not matter in a desktop software context, but memory is rarely in abundance in an embedded system.

2. There is the question of where the output of printf() actually goes. Many embedded systems have nothing that looks like a "console" and directing output back to a host computer can be challenging.

3. In a multi-threading context - i.e. when using an RTOS - reentrancy is a concern. If two threads try to use printf() at the same time, confusion can result.

4. Every time you want to change the variables you are looking at, a complete rebuild and download of the code is required.

5. Lastly, of course, formatting and sending the output (somewhere) takes time. If it is a real time application, this overhead can introduce problems.

A real debugger: Debug today

So, for most systems, using printf() as a debug tool is not viable and the use of a “real” debugger makes more sense. Debuggers are available from a wide variety of suppliers of embedded software development tools and can take a number of different forms, largely characterized by how/where the code gets to execute:

Simulation – It can be useful to start debugging before target hardware is available. One approach to achieving that is to use some form of simulation. This term covers a broad spectrum of technologies, which may include native execution of code on the host computer and instruction set simulation.

Virtual prototype – A step on from simulation is the use of a virtual prototype. A number of vendors offer tools whereby code may be executed and interact with a detailed simulation of the real target hardware at a number of possible levels of abstraction.

Network connection – If a target system is networked, this may be a good way to interface a debugger. However, it does demand fully working target hardware, functional network driver software and some kind of target “debug agent” software.

JTAG – Many embedded CPUs support the provision of a JTAG port and its inclusion has a minimal impact on system design. Debuggers that support a JTAG connection are widely available.

For many developers, the simplest solution is the last one listed – attach a debugger to a target system or an evaluation board using JTAG. This can give ready access to all the target data and addresses the five problems with printf()debugging thus:

1. There is no extra code on the target.

2. Data is displayed on the host computer without effort.

3. The debugger needs to be task-aware, but that is well understood.

4. Code only needs to be rebuilt to fix bugs.

5. A JTAG connection is slightly intrusive in the time domain, but the impact is typically quite small.

Debugging in the future – multicore and beyond

Debugging has always been challenging, as the manifestation of bugs can be very subtle. This became harder with the widespread use of multi-threaded code, but debugger suppliers responded well to the needs of developers. Many tools allow task-specific breakpoints and feature the option to stop the entire system or just the task of interest. However, this “stop and stare” approach becomes almost non-viable with a multicore system, which may also feature multiple operating systems and CPU architectures.

Going forward, it is likely that sophisticated tracing and analysis tools (such as Sourcery Analyzer from Mentor Graphics) will address the needs of developers of multicore systems, particularly with AMP (Asymmetric Multi-Processing) architectures. Although a tiny amount of code instrumentation is required, this has minimal impact. The large volumes of logged data can be analyzed to yield a clear picture of a system’s state and behavior in the lead up to an observed bug.

Baggio WANG FAN

SHENZHEN JAAPSON TECHNOLOGY CO LTD

baggio@jaapson-pcb.com  

www.jaapsonpcb.com

skype: baggiowang0214

JAAPSON, Expert in HDI Multi-layer PCB Manufacturing