Comment 1 by Nikolaus Schaller, May 28, 2015
While the theories are almost right (except the models I have seen appear to forget the series resistance between the capacitors by copper traces), all these theoretical and experimental analyses don't help for practical PCB layout where you have to do hundreds of tradeoffs and design decisions and no space - far away from the assumptions of the theory. Regarding the anti-resonant effects, I read mainly that the additional capacitor may have no or only a small effect - but it does not harm (except for cost). Thanks also for your analysis of the schematics for what you think are missing decoupling caps. But please don't forget that this is just a snapshot of work in progress. Nothing is finished where we are need bug reports. The number and placement of caps will also be changed by the final layout. E.g. if two chips are very close to each other it is better to share a capacitor than having none at all. Some chips in the power chain share a capacitor between the output of one and the input of the next one. So they appear to be missing in the schematics just because the way the were split into pages. And e.g. a load switch (TPS2296) does not need decoupling capacitors because the caps are to protect from high speed switching noise creeping out of a chip onto the power network which would become an antenna. A pure load switch does not create such noise - so there is no need to protect from. Another thing to consider: some power signals might stay completely inside the PCB (inner layers). So thanks for bringing up this topic to our attention, but please don't be disappointed if we can't work it in immediately (or in a way that it can be recognized in the end). Therefore we don't take a specific action.
Status:
WontFix
Comment 2 by Matthew Blue, May 29, 2015
Well, my intention was to work at this problem and determine specific capacitance requirements of each IC as well as placement guidelines based on the parameters of the boards' planes (i.e. have equations ready to plug data in if PCB characteristics are not yet availible). I thought that by doing the work in this problem, it would free the devs to do other things. But if that is unwanted I guess it is up to you. Here is what my notes were so far before I saw that the issue had been abruptly closed. Though, I guess they will not be that useful to you because they are notes to myself on an incomplete optimization, but I will put them here in case someone finds them useful at some point: Estimated minimum capacitance, steady state switching, typical conditions: total charge moved = amperage * switch cycle length break-even capacitance = charge moved / voltage NOTE: does not yet account for max conditions or data transaction lengths. TODO: SIM, modem, wireless, audio, uSD, camera, LEDs, analog, block diagram REQ DIFF CALC: DC-DC, LDO, connect IGNORED: BB, proto, incompl Sheet 4: U301,U1,U2 (INA231) VSYS?=3V6x1 CMNx1 - 100kHz (I2C standard), 355uA, C=986pF - 400kHz (I2C fastmode), 385uA, C=267pF - 1MHz (I2C fastmode+), 420uA, C=117pF Sheet 5: U401 = BQ27421 BATT+?=3V6x1 CMNx1 - 100kHz (I2C standard), 90uA (typ), C=250pF - 400kHz (I2C fastmode), 90uA (typ), C=63pF U402 = BQ27421 BATT+?=3V6x1 CMNx1 - 100kHz (I2C standard), 93uA (typ), C=258pF - 400kHz (I2C fastmode), 93uA (typ), C=65pF Sheet 6: U3 = BGM1034N7 1V8x1 CMNx1 - 1575.42MHz, 3.9mA (typ), C=1.4pF - 1598.06MHz, 3.9mA (typ), C=1.4pF - 1605.38MHz, 3.9mA (typ), C=1.3pF U504 = LTC5508 3V3x1 CMNx1 - 300MHz, 550uA (typ), C=0.6pF - 7000MHz, 550uA (typ), C=0.02pF U317,U318 = LMV221 2V7x1 CMNx1 - 50MHz, 7.2mA (typ), C=53pF - 3500MHz, 7.2mA (typ), C=0.76pF Sheet 7: X1101 = NT2016SA 1V8x1 CMNx1 - 26 MHz, 1.5mA (max), C=32pF Sheet 8: S701 = BMG160 1V8x2 CMNx2 - 100kHz (I2C standard), 5mA (typ?), C=28nF - 400kHz (I2C fastmode), 5mA (typ?), C=6.9nF S702 = BMC150 3V3x1 1V8x1 CMNx3 - 100kHz (I2C standard) 130uA (accel typ 3V3 only), C=394pF - 400kHz (I2C fastmode) 130uA (accel typ 3V3 only), C=98pF - 100kHz (I2C standard) 500uA (mag "reg" typ 3V3 only), C=1.5nF - 400kHz (I2C fastmode) 500uA (mag "reg" typ 3V3 only), C=379pF - 100kHz (I2C standard) 130uA (accel typ 1V8 only), C=722pF - 400kHz (I2C fastmode) 130uA (accel typ 1V8 only), C=181pF - 100kHz (I2C standard) 500uA (mag "reg" typ 1V8 only), C=2.8nF - 400kHz (I2C fastmode) 500uA (mag "reg" typ 1V8 only), C=694pF S703 = BMP180 1V8x1 CMNx1 - 100kHz (I2C standard), 650uA (conv peak typ), C=3.6nF - 400kHz (I2C fastmode), 650uA (conv peak typ), C=903pF - 1MHz (I2C fastmode+), 650uA (conv peak typ), C=361pF - 3.4MHz(I2C Highspeed), 650uA (conv peak typ), C=106pF S704 = LIS302DL 3V3x1 1V8x1 CMNx4 - 100kHz (I2C standard), 300uA (typ 3V3 only), C=909pF - 400kHz (I2C fastmode), 300uA (typ 3V3 only), C=227pF - 100kHz (I2C standard), 300uA (typ 1V8 only), C=1.7nF - 400kHz (I2C fastmode), 300uA (typ 1V8 only), C=417pF S1401 = BNO055 3V3x1 1V8x1 CMNx2 - 100kHz (I2C standard), 12.3mA (max 3V3 only), C=37nF - 400kHz (I2C fastmode), 12.3mA (max 3V3 only), C=9.3nF - 100kHz (I2C standard), 12.3mA (max 1V8 only), C=68nF - 400kHz (I2C fastmode), 12.3mA (max 1V8 only), C=17nF Sheet 10 (NOTE: VMMC seems to go nowhere?): U901 = TPA6130A2 VMMC?=3V3x2 CMNx5 (DIGITAL NOISE ONLY) - 100kHz (I2C standard), 1.4mA (typ w/ amp disabled), C=4.2nF - 400kHz (I2C fastmode), 1.4mA (typ w/ amp disabled), C=1.1nF - 300kHz chargepump, 1.4mA (typ w/ amp disabled), C=1.4nF - 500kHz chargepump, 1.4mA (typ w/ amp disabled), C=848pF U902 = TS3A225E VMMC?=3V3x2 CMNx2 (DIGITAL NOISE ONLY) - 100kHz (I2C standard), 10uA (quiescent max), C=30pF - 400kHz (I2C fastmode), 10uA (quiescent max), C=7.5pF Sheet 11 U1077 = TPA2012D2 VSYS?=3V6x3 CMNx3 (DIGITAL NOISE ONLY) - 250kHz PWM freq, 5mA (typ no load), C=5.6nF - 350kHz PWM freq, 5mA (typ no load), C=4.0nF Sheet 16 U1501 = SFH7741 3V3x1 CMNx1 - 44us pulse, 10mA ( 8-12mm dist), C=133pF - 44us pulse, 20mA (12-18mm dist), C=267pF - 44us pulse, 30mA (17-24mm dist), C=400pF - 44us pulse, 40mA (20-27mm dist), C=533pF - 44us pulse, 50mA (23-30mm dist), C=667pF - 44us pulse, 60mA (25-32mm dist), C=800pF U1401 = MLX90248 3V3x1 CMNx1 - 120us periodic wake, 3mA (typ), C=109nF Sheet 18 U1601 = TCA8418 1V8x1 CMNx1 - 400kHz scan ~53uA, C=74pF - 1MHz scan ~72uA, C=40pF Sheet 19 U1701 = TSC2007 1V8x1 CMNx1 - 400kHz (I2C fastmode) 39uA (8.2k rate), C=54pF - 400kHz (I2C fastmode) 165uA (34.42k rate), C=229pF TODO LATER: - Switching event, maximum condition estimated charge requirements. - Per-transaction, etc. estimated charge requirements. - Power/ground plane, via, package, placement, inductance calculation. - Power/ground plane, via, package, placement, damping calculation. - Optimal placement guidelines, critical damping. - Optimal component aggregation guidelines/power hierarchy. - Inductor Q-factor optimization, guidelines. - Power/ground plane current distribution simulation (create examples?).
Comment 3 by Nikolaus Schaller, May 29, 2015
Hi, it was not intended to disappoint you. It just does not fit into our design process. And, we have to optimize the total project, not a very specific detail. When I look over your findings in almost all cases the required capacity is in the pF range. A typical rule of thumb is to use 100nF. Or 1uF if higher current is expected. So the minimum is fulfilled without detailed calculations. Next, most of the capacitor values we did choose were copied from existing schematics and boards - or recommendations by the chip manufacturers. So why improve and reconsider that? Only if we really face a problem. Regarding placement: the manufacturers usually have design guides so we will follow them as good as possible. Finally there are production related thoughts. We should keep the number of different capacitors small since the more different components we have the more is the time to setup the production machines. Which drives cost up. And, we buy components in smaller quantities, which also drives cost. I.e. there are not only technical constraints but economical. So your work is really great - but I must admit that it tries to solve a problem where I do not see that it is a problem at all. The GTA04 board (from which we derive the Neo900 board) works flawless without any such calculations or simulations (see schematics here: http://projects.goldelico.com/p/gta04-main/page/Manual/).
Labels:
Type:Enhancement
Type:Defect
Comment 4 by Matthew Blue, May 29, 2015
I suppose I was dissapointed because I was confused about the response. I think this is because I didn't communicate my intent very well (maybe because in addition to the main statement I also gave a general report on the findings of my literature search). I do think that what I hope to do fits with your design process. If I can tell you: a specific IC needs at least X capacitance within about Y distance, and the package size must be smaller than Z to handle the high frequencies well, then aren't these things important to your design process? That is what I interpreted the decoupling caps on the schematics as being: a note about IC requirements to the guy doing layout. This is what I anticipate the analysis will show, based on the partial findings that I have posted above: - Switching noise from most small ICs can be handled by a 1nF cap in the typical case, and probably not more than 10nF in the worst case (max current draw). This means that you could shrink your cap size to 0402, making layout easier, improving decoupling of high-frequencies, and probably reducing cap price slightly. - The calculation can tell you the diversity of values you actually need, so that a range of values can be rounded to a convenient value that could be used all over the board. - Noise from changing IC power states can probably be handled by a more distant cap of larger value (probably around the 100nF or 1uF you mentioned), and I should be able to calculate roughly how far it can be without ill effects. - Having a calculated value will permit you to know exactly when it is a good idea to share caps, and when it will have a slightly negative impact, and when it will have a significant negative impact. - Looking at different IC geometries could tell you what the consequences would be of various alterations to the recommended layout, in the case that the recommended layout is not feasible because of placement constraints. - Probably what I consider the most important point though, is that an analysis could give guidelines on how to minimize anti-resonant effects, which has the potential of making the decoupling unreliable at the anti-resonant frequency. Since anti-resonance is highly dependent on placement, modifying even a well-tested design like the GTA04 could have unpredictable effects if the anti-resonance is not anticipated. If you had a 10% chance of having an antiresonance problem that had significant effects on performance, you might redo placement of a reliable core design half a dozen times before hitting a problem. That percentage is just an example, but do you find even a low rate of risk for significant anti-resonance problems acceptible? AFAIK most corporate development handles this problem by having more prototypes than the Neo900, which the project doesn't really have the funding for. I suspect that the datasheet decoupling values, as well as the rules of thumb, are trying to give a cap recommendation for a wide range of possible circuits that the IC would be placed in. In this case you can't just assume that nearby ICs will be properly decoupled, or that the power supply was designed competently. So the prudent datasheet or rule of thumb would recommend extreme values to prevent the IC from having problems in poorly designed circuits. Since the Neo900 design looks really good so far, I don't think the extreme values are needed, and so the caps could be shrunk to give better decoupling/less expense/easier layout. As far as this looking like a non-problematic area: even if that is the case, this is something that I think would be quite good to have and so I am willing to do the work to accomplish it. If you look at the finished analysis and agree that it would be an improvement, and it doesn't significantly increase your workload (I hope that it will decrease it), then wouldn't it be positive to include it?
Sign in to reply to this comment.
Reported by Matthew Blue, May 27, 2015