Editor’s note : James Bryant (retired), Analog Devices, is back with this informative and intriguing blog.
[Q] : We have been manufacturing a system using an Analog Devices' component for many years. Recently our purchasing department bought a consignment of cheaper replacement devices from another company and the whole batch of systems using them failed to work. Every specification on their data sheet is the same as ADI's, and when we test them they are well within those specifications. What is happening?
[A] The operation of your system relies on some feature of our product which is not featured on the data sheet and is different in the second source.
This can apply to any component, not just ICs or active devices. In an entirely different context I keep a bottle of hot sauce in my kitchen to adjust the heat of curries and other hot dishes. I recently bought a new bottle – my usual brand was unavailable so I bought another with the same Scoville rating (i.e. the data sheet specification was the same). This second sauce was horrible – the heat was indeed the same, but it had much slower onset (first taste seems bland, but the tongue burns several seconds later, which may cause the cook to judge too soon and add too much) and, while my usual sauce just contributes heat, the second sauce has a bitter acrid taste in addition to its heat which spoils the carefully planned flavor of the dish. Obviously the flavor of electronic components is irrelevant, but other unspecified parameters may be critical.
While I should like to tell you that all will be well if you remain loyal to Analog Devices – and that is probably true – it is quite important that you ensure that there is sufficiently close liaison between your purchasing department and system designers that when a change of component is proposed, for cost or any other reason, the new component is evaluated to ensure that it is truly compatible. Such evaluation must include hardware tests as well as any paper and/or simulation exercises since no model can simulate every feature of a device, and to improve their run-time macro-models often deliberately simplify structures which the modeller considers unimportant. It is impossible to discuss every possible issue in a large book, let alone a short article, but the principle involved in anticipating trouble is simple: ask yourself what non-ideal component behaviour may cause a circuit to malfunction – and check it out.
I shall list a few that I have encountered over the years, but I am trying to teach a mind-set here, rather than present a (far from exhaustive) list of potential problems.
- A recent RAQ considered unused device pins – I have seen second-sources where an unconnected pin in the original had an internal connection in the second source.
- Some op-amp inputs are high impedance even with large differential voltages, others have high impedance when used with negative feedback (and hence small differential Vin ) but their protection circuitry reduces Zin dramatically when the differential Vin >600mV.
- A modern (“improved”) second source of an old circuit may use a faster IC process and have unexpectedly wider bandwidth, potential instability, and broadband noise.
- Or a faster logic process may be vulnerable to ns glitches (which its predecessors ignored).
- A 10 nF 50 V ceramic capacitor may have much lower inductance, and hence HF impedance, than a cheaper foil capacitor of the same value.
- And even two manufacturers' standard (Cat 5) Ethernet cables may have sufficient differences of loss and crosstalk that only one works in a particular system.
Think, test and retest your hardware, and always remember Murphy's Law.
2 “If it can go wrong, it will go wrong”