DesignCon 2009

Switching Voltage Regulator Noise Coupling Analysis for Printed Circuit Board Systems Amy Luoh, Intel Corp. Gene Garrison, Intel Corp. Jon Powell, Intel Corp.

Abstract Our commercial server mainboard designs have experienced increasing instances of switching voltage regulator (SVR) noise coupling into sensitive signals. We have seen noise couple from SVR fills to separate area fills and eventually into signals. This leads to system hangs and unreliable booting, requiring huge debug time and effort to address. This problem is becoming more prevalent as electronic designs go “Green” and SVRs increase switching speeds to become more and more efficient. We describe a method we have developed, deployed, and verified through measurement for a Signal Integrity or Power Engineer to efficiently simulate this noise coupling before building boards. Author(s) Biography Amy Luoh received the B.S. and M.S. degree in electrical and computer engineering from Oregon State University. She has been working as a signal integrity engineer in server board design group at Intel for more than three years. She performs routing reviews, including simulations and measurements for the server board designs. She has been especially involved in power noise coupling analysis into signals. Gene Garrison received a BSET degree from DeVry Institute of Technology and an MSCE from Florida Atlantic University. With a background in analog design and signal integrity, Gene is currently the manager of PCB Layout and Signal Integrity for the Enterprise Products and Services Division of Intel Corporation. Jon Powell received his BSEC and MSEC degrees from Massachusetts Institute of Technology. As a Principal Architect at Quad Design, Jon was a key architect of the IBIS modeling standard. He has been a frequent speaker at DesignCon and PCB West and a frequent author for PC Design magazine. Jon is currently a Staff Signal Integrity engineer at Intel Corporation.

Introduction As the world becomes more conscious of environmental considerations, designing a “green” product becomes a key differentiator. A major factor is energy efficiency so more SVRs are desired and these SVRs must become even more efficient. A byproduct of a more efficient SVR design is faster FET switching and faster switching edges. Combine this with always increasing board densities for both servers and desktop, and we can expect to see increasing instances of SVR switching noise disrupting the operation of normal board signaling. In a previous generation of our server board products, we experienced system hangs, unreliable booting, and generally “flakey” behavior on many board designs. A large number of these issues were ultimately root-caused to SVR noise coupling into adjacent power fills and from there into the signals referencing the power fills. As with most such problems, the failures tended to be intermittent and sensitive to component and environmental changes. Root-cause efforts typically took weeks of project schedule and tended to be encountered late in the schedule when business impact to a schedule slip was most severe. In response, we have developed a methodology for accurately simulating SVR switching noise coupling across an entire board using an industry available simulation engine. We believe this methodology can be broadly applied by board designers, both in computer and more generic designs, to understand the complexities of SVR noise couplings and to successfully prevent issues from these switching noises. In our paper we will first review SVR noise issues found in our CPU PCB designs with the objective of establishing relevance to a general board design audience. We will then discuss the methodology in detail and its integration into our product design flow. Lastly, we will review our correlation of analysis results to measurements for recent product family generations. Early SVR problems In the last few years we have seen a new problem in our board designs; functional failures caused by SVR noise. We are going to present two of the original problems to illustrate the difficulties involved in locating and fixing an SVR noise issue. The circuitous nature of the coupling also gives an indication of the complexity of the simulation that could be involved as well as the necessity for said simulation. Define an SVR Let’s define some terms about the SVR’s we are going to be discussing. In Figure 1 you can see a typical Buck regulator that uses 2 FET’s to generate a lower voltage from a 12 volt source. Both the input and the output (typically) have filter inductors to isolate the extreme noise that is resident in the switching nodes. The FETs are controlled by non-overlapping square waves.

Figure 1: Simple Buck Switching Voltage Regulator

PrevGen1 The design we’ll call PrevGen1 is a 2 CPU Socket rack-mount server system designed circa 2005. The initial problem investigated was a “3 strikes counter” failure. The 3 strikes counter indicates that something bad has happened at least 3 times. It isn’t very specific. This problem only occurred on one or two systems and took up to a week to record a failure. After much top level probing it was found that one of the system clock chips was disabled. More investigation showed that it was becoming disabled at sometime during normal operation. Investigation now centered on the I2C buss that could bring in a disable command to the clock chip. With bios changes the I2C buss traffic was increased such that failures occurred on an hourly basis, confirming I2C as the source of the clocking problem. Probing of the I2C buss showed noise spikes on the data buss. The repetition rate of these spikes indicated a SVR switching node as the source. By probing the I2C and various SVR switching nodes at the same time the problem was traced back to a 1.5V SVR (see Figure 2).

Figure 2: Phase noise couples onto 12V then onto I2C

But how was the noise getting from the 1.5V SVR to the I2C? Further tracking showed that the 1.5V switching node was coupling to the 12V fill, and that plane was a reference plane for several inches of the I2C in question (see Figure 3). We found that the decoupling capacitors were placed only at the far end of the 12V fill but none in the region that I2C signal was referencing. Therefore when 1.5V SVR switches, the current and voltage transitions in and around the switching nodes induces the current and voltage changes into this non-decoupled 12V fill (one layer above 1.5V SVR) through magnetic and electrostatic coupling, and therefore into I2C signal (that referenced to it). So there was the root cause. This issue can be considered as both a signal integrity and a power integrity problem since we know that data signals always use either power or GND for their reference and cannot be considered separately. Later on, we found the abnormal behavior on the Fan_Tach4 signal, which is also the same root cause (See Figure 2 and Figure 3). In this case, the path of the noise coupling was not obvious, even when the source and ultimate destination were known. Clearly this indirect kind of problem is not only difficult to find, but also difficult to predict.

Figure 3: SVR coupling path for PrevGen1

PrevGen2 PrevGen2 was a 2 CPU Socket pedestal server system designed circa 2006. Blue Screen or system lockup was exhibited at low temperature on a late fab of the design. Earlier fabs had not had this problem. The fact that this problem took hours to days to reproduce and the fact that it could only be seen in the temperature chamber made this debug very lengthy. The debug team went back and checked all changes that had been made and eventually linked it to a new FET controller that had be added to replace a part that was being EOL by the manufacturer. The culprit was the FSB_INIT which referenced to 12 volt fill. The signal was found to be picking up noise from a 12 volt fill that was running underneath an SVR and picking up noise directly from the “filter” nodes of that SVR (see Figures 4 and 5). The new FET controller was causing slightly more noise that the previous one.

Figure 4: SVR Noise Coupling Path for PrevGen2

Figure 5: Coupling from Filter Nodes to Power fill to Signal

Decisions In Summary, we spent 6 to 8 weeks and untold man-hours in finding the root cause of each of these issues, and these were only two of the designs with which we found issues. For some of these issues we were able to fabricate design rules that we felt would prevent

the re-occurrence of the problem. But in general, it was obvious that we needed to be able to prevent these types of problems early in the design. At the late stage of the design where we were finding these problems, we really couldn’t take the corrective action that would be the most effective (like moving the signal away from the switch noise) because the amount of rework was too great. So we added capacitors or used parts with better hysteresis; adequate solutions but not ideal and more expensive than ideal. We needed something that would allow us to find the problems before building boards and because of the non-intuitive coupling paths, it seemed that simulation was the only viable solution. Development of Simulation Methodology Based on these experiences, SVR noise coupling was proving to be very common and very difficult to predict or debug, so we launched an effort to find a simulation technology. Our requirements were a tool that would simulate coupling between planes and shapes as well as signal couplings and lossy transmission line effects. It also had to be suitable for a full server mainboard simulation (we have found that our designs can break most board-level simulators on the market). We chose Sigrity Speed2000 as our main simulation engine. In order to effectively simulate the SVR noise coupling into the signals, we have tried several approaches and learned a few things: First, the actual full transistor SPICE models are sometimes available for certain FETs, but often they are unstable and are too slow to use for large system simulations. Hence, we generated a behavioral FET model based on the characteristics of the FETs (see Figure 6). G_FET is implemented as a voltage controlled resistor associated with Ron, as indicated in the curves. This Ron and all the parasitic of the FETs in the circuit model can be obtained from SPICE models or from the datasheets.

Figure 6: Behavioral FET Model

Second, we developed a behavioral model of the controllers to provide the correct stimulus to the FETs. The correct edge rate and timing relation can be obtained from the datasheet. A particular challenge was modeling the overlap control functionality. Third, we automated the process for simulation setup. We developed a setup script to find all receivers, drivers, and resistive loads, for the important pins and attach simple but reasonable models with parasitics for them in the simulation system. We had tested this approach with IBIS models, and found we got accurate results. But we also found the IBIS simulations took take far too long and often, due to the complexity of our boards, were unstable. For the purposes of our SVR noise simulations, simple RC models are much more efficient and provide adequate accuracy. We compared the output loading using one simple resistor vs distributed loading and found that the difference was very small. Hence, simple resistor loading was chosen. We needed to avoid simulating the hundreds of milliseconds of SVR initialization and settling time. We found that we needed to pre-calculate output inductor current and output capacitor voltage and apply those as initial conditions in the simulation. Fourth, in order to clearly identify the problematic victim signals, we developed a post processing script that will take the large amounts of output data and deliver the worst case pk-pk noise for further study. Even with these simplifications and efficiencies, we found that we needed a 64 bit operating system and 24 GB of system memory to effectively simulate a 2 CPU socket, 8 layer server board. And even then, it takes about three days of simulation time per SVR phase. Simulation Process In summary, the simulation process includes (1) make SVR models, including behavioral FETs and controller models (2) generate input database with automated script, (3) run simulation on a given SVR net, (4) extract worst case noise peaks, (5) have SI engineers review the report and identify any problem nets, (6) use the simulation tool to identify the coupling mechanism in problem nets, (7) fix the problem and test the fix in simulation. In the process development cycle, we tested our simulation on PrevGen1, which is the first board on which we have seen this problem. On PrevGen1, the simulated waveforms when compared to measurement show about the same noise levels on I2C signal and slightly less noise on FAN_TACH (see Figure 7). The small difference could be caused by the fact that we used slightly different SVR models in this simulation just to assist the development of our simulation process. We would have checked these signals and caught the problems if we had run the SVR noise simulations at that time. That would have saved us a huge time and effort on debugging the problem.

Figure 7: PrevGen1 Measurement Vs Simulation

CurGen1 We implemented our simulation methodology on our most recent designs, including one board that we’ll call CurGen1. We found potential SVR noise problems on CurGen1 based on our simulations and we used these simulations to provide solutions and improvements to the SVR noise problems. Let’s use PV_VCCP_CPU1 SVR, a four phase SVR, as our first example. The PV_VCCP_CPU1 SVR switching nodes are routed on layer 3 in this 8 layer design. A 5V power plane is routed on layer 4, one layer below the SVR switching nodes. Part of our JTAG chain, JTAG_CPU0_TDI, is routed around 100 mils away from the voltage switching nodes (see Figure 8). This signal is associated with CPU debug functionality and may make the CPU hang if it is malfunctioning. We would usually think that this was far enough away to avoid picking up any stray noise. In this case, however, the JTAG line is routed with the 5V plane as one of its reference planes. CurGen1 is using a non-symmetric stripline, so the JTAG is much closer to a ground reference than to the 5 Volt plane (we call the 5 Volt plane the far reference) When a PV_VCCP_CPU1 SVR switches, the current and voltage transitions in and around the switching node will induce current and voltage changes into adjacent structures through magnetic and electrostatic coupling. In this case, the switching noise was found to be coupling into the adjacent power fill, 5V power plane, and from there into the JTAG and other neighboring signals.

Figure 8: Relative Positions of Phase nodes and JTAG line

Because we were unable to complete the simulations before fab 1 taped out, we were able to correlate simulation results (Figure 9) to measurement results (Figure 10). This signal is simulated and measured at an analog switch. As you can see the measurement and simulations are shown in a relative good agreement. For phase2 we simulated 200 mVpk-pk and measuered 192 mVpk-pk. For phase 3 we simulated 150 mVkpk-pk and measured 120 mVpk-pk. We consider this difference to be within the tolerance of the physical parts and our simulation methodology. During this analysis we discovered another impact to correlation accuracy. The simulations assume the max current loading from the SVR, but that may not be the condition in the measurements. We continue to assess the impact of this variable.

Figure 9: Fab1 JTAG Simulation

Figure 10: Fab1 JTAG Measurement Results

As we have stated, part of the noise is coupled from the layer 3 SVR switching nodes onto an adjacent layer 4 5V power plane. This power plane is the far referencing plane for this signal. In Figure 11, we can see relative good agreement between simulation and measurement for the 5V noise level measured at a mid-south side cap indicated in Figure 8.

Figure 11: Noise on 5V Fill, Fab1 Measurement (left) and Simulation (right)

To repair this problem we removed the layer 3 switching nodes from all 4 phases and also moved the JTAG_CPU0_TDI signal completely out of the SVR area (see Figure 12). We verified the suggested solutions in the simulation shown in the Figure 13. As you can see the noise from the SVR on JTAG_CPU0_TDI signal decreased.

Figure 12: Fab2 (repaired) layout

We implemented the changes on the fab2 board. When we got our fab2 boards back, we verified the solution in the measurement as shown in Figure 14. We see a small difference between simulations and measurements and that can be accounted for by the simplified pin models we used for the drivers and receivers.

Figure 13: Fab2 JTAG Simulation

Figure 14: Fab2 Phase and JTAG measurements.

Let’s look at another case. The noise source is from PV_VTT_CPU1 SVR. The victim signal, IRQ_CPU1_RDIMM_EVENT_N, is measured and simulated at the DIMM connector pin. Part of the switching nodes of PV_VTT_CPU1 SVR is placed on layer 3, similar to the previous case, which is above layer 4 5V power plane.

Figure 15: IRQ Layout.

We simulated this SVR and found about 400mV pk-pk noise on this signal (see Figure 16). We also verified the noise level on this signal on our fab1 board for the similar amount (also in Figure 16). We suspected the noise could be reduced by removing the layer 3 switching node of this SVR. Since the schedule for fab2 was very tight and each simulation takes a long time, we decided to implement our best guess for the solutions on fab2 before we completed the simulations. The reader my find it amusing to note that doing the simulations would have correctly predicted that this change was not sufficient to solve our problem. Measurements on the fab2 board showed a noise decrease to 300mV pk-pk noise. Similar noise levels were found in the simulation (results for both in Figure 17).

Figure 16: Fab1 IRQ Measurement (left) Vs Simulation (right)

Figure 17: Fab2 IRQ Measurement (left) vs Simulation (right)

Summary A primary goal in any of our designs is “first pass success”. That is, we want the first board we tape out to be of sufficient quality for high volume manufacturing. Given the complexity of today’s server board designs, and given that technology today moves faster than a complex board design, this goal is essentially impossible to meet. From this, one might infer that potential problems that are difficult and/or expensive to pre-analyze should be found by testing and then resolved in subsequent builds. But as described in this paper, issues caused by Switching Voltage Regulator noise coupling can be so insidious and so expensive to debug, that the potential impact to program schedule is not tolerable. When issues such as these are not discovered until late in a program, the impact to the project is much greater than just the schedule.

The major shortcoming of the process today is the computational simulation time required. We typically allow only one or two weeks from the time when power distribution routing is completed and when the board tapes out. This is insufficient time to simulate one SVR, identify and devise any needed fixes, re-simulate, and implement those fixes. CurGen1 had 7 SVRs that needed simulation. This means that we are unable to implement needed fixes before the second or third fab spin. We have developed a system for simulating SVR noise coupling issues as efficiently as we are able. The results are sufficiently accurate to drive corrective action before building and measuring boards. The tool is expensive in terms of the software, the hardware, and the simulation time involved, but we believe the cost is justified.