JAAPSON PCB TESTING

PCB design considerations

不可忽视的电路设计的八个盲点

盲点一：对于设计要求不高的板子用细线自动分布

自动布线必然要占用更大的PCB面积，同时产生比手动布线多好多倍的过孔，在批量很大的产品中，PCB厂家降价所考虑的因素除了商务因素外，就是线宽和过孔数量，它们分别影响到PCB的成品率和钻头的消耗数量，节约了供应商的成本，也就给降价找到了理由。

盲点二：总线信号都用电阻拉一下

信号需要上下拉的原因很多，但也不是个个都要拉。上下拉电阻拉一个单纯的输入信号，电流也就几十微安以下，但拉一个被驱动了的信号，其电流将达毫安级，现在的系统常常是地址数据各32位，可能还有244/245隔离后的总线及其它信号，都上拉的话，几瓦的功耗就耗在这些电阻上了。

盲点三：CPU和FPGA的这些不用的I/O口让它先空着

不用的I/O口如果悬空的话，受外界的一点点干扰就可能成为反复振荡的输入信号了，而MOS器件的功耗基本取决于门电路的翻转次数。如果把它上拉的话，每个引脚也会有微安级的电流，所以最好的办法是设成输出(当然外面不能接其它有驱动的信号)

盲点四：FPGA还剩这么多门用不完，可尽情发挥

FGPA的功耗与被使用的触发器数量及其翻转次数成正比，所以同一型号的FPGA在不同电路不同时刻的功耗可能相差100倍。尽量减少高速翻转的触发器数量是降低FPGA功耗的根本方法。

盲点五：小芯片的功耗都很低不用考虑

对于内部不太复杂的芯片功耗是很难确定的，它主要由引脚上的电流确定，一个ABT16244，没有负载的话耗电大概不到1毫安，但它的指标是每个脚可驱动60毫安的负载(如匹配几十欧姆的电阻)，即满负荷的功耗最大可达60*16=960mA，当然只是电源电流这么大，热量都落到负载身上了。

盲点六：存储器多控制信号，板子只需要用OE和WE信号就可以，片选接地，这样读操作时数据出来得快多了

大部分存储器的功耗在片选有效时(不论OE和WE如何)将比片选无效时大100倍以上，所以应尽可能使用CS来控制芯片，并且在满足其它要求的情况下尽可能缩短片选脉冲的宽度。

盲点七：信号过冲只要匹配好就可以消除

除了少数特定信号外(如100BASE-T、CML)，都是有过冲的，只要不是很大，并不一定都需要匹配，即使匹配也并非要匹配得最好。象 TTL的输出阻抗不到50欧姆，有的甚至20欧姆，如果也用这么大的匹配电阻的话，那电流就非常大了，功耗是无法接受的，另外信号幅度也将小得不能用，再说一般信号在输出高电平和输出低电平时的输出阻抗并不相同，也没办法做到完全匹配。所以对TTL、LVDS、422等信号的匹配只要做到过冲可以接受即可。

盲点八：降低功耗都是硬件人员的事，与软件没关系

硬件只是搭个舞台，唱戏的却是软件，总线上几乎每一个芯片的访问、每一个信号的翻转差不多都由软件控制的，如果软件能减少外存的访问次数、及时响应中断及其它争对具体单板的特定措施，都将对降低功耗作出很大的贡献。

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

High Frequency PCB Design Techniques

High frequency design is where you really need to consider the effects of parasitic inductance, capacitance and impedance of your PCB layout. If your signal is too fast, and your track is too long, then the track can take on the properties of a transmission line. If you don’t use proper transmission line techniques in these situations then you can start to get reflections and other signal integrity problems.

A “critical length” track is one in which the propagation time of the signal starts to get close to the length of the track. On standard FR4 copper boards, a signal will travel roughly 6 inches every nano second. A rule of thumb states that you need to get really concerned when your track length approaches half of this figure. But in reality it can actually be much less than this. Remember that digital square wave signals have a harmonic content, so a 100MHz square wave can actually have signal components extending into the GHz region.

In high speed design, the ground plane is fundamental to preserving the integrity of your signals, and also reducing EMI emissions. It allows you to create “controlled impedance” traces, which match your electrical source and load. It also allows you to keep signals coupled “tight” to their return path (ground).

There are many ways to create controlled impedance “transmission” lines on a PCB. But the two most basic and popular ways are called Microstrip and Stripline.

A Microstrip is simply a trace on the top layer, with a ground plane below. The calculation involved to find the characteristic impedance of a Microstrip is relatively complex. It is based on the width and thickness of the trace, the height above the ground plane, and the relative permittivity of the PCB material. This is why it is important to keep the ground plane as close as possible to (usually) the top layer.

A Stripline is similar to the Microstrip, but it has an additional ground plane on top of the trace. So in this case, the trace would have to be on one of the inner layers. The advantage of stripline over microstrip is that most of the EMI radiation will be contained within the ground planes.

There are many free programs and spreadsheets available that will calculate all the variations of Microstrip and Stripline for you.

Some useful information and rules of thumb for high frequency design are:

1) Keep your high frequency signal tracks as short as possible.

2) Avoid running critical high frequency signal tracks over any cutout in your ground plane. This causes discontinuity in the signal return path, and can lead to EMI problems. Avoid cutouts in your ground plane wherever possible. A cutout is different to a split plane, which is fine, provided you keep your high frequency signal tracks over the relevant continuous plane.

3) Have one decoupling capacitor per power pin.

4) If possible, track the IC power pin to the bypass capacitor first, and then to the power plane. This will reduce switching noise on your power plane. For very high frequency designs, taking your power pin directly to the power plane provides lower inductance, which may be more beneficial than lower noise on your plane.

5) Be aware that vias will cause discontinuities in the characteristic impedance of a transmission line.

6) To minimize crosstalk between two traces above a ground plane, minimize the distance between the plane and trace, and maximize the distance between traces. The coefficient of coupling between two traces is given by 1/(1+(Distance between traces / height from plane)^2))

7) Smaller diameter vias have lower parasitic inductance, and are thus preferred the higher in frequency you go.

8) Do not connect your main power input connector directly to your power planes, take it via your main filter capacitor(s).

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

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