High Speed Digital Bug

I have read about signal integrity problems for years, and even designed my hardware to avoid them. However finally I have managed to find (and fix) a high speed digital signal integrity problem! Wow, reading those last two lines makes me sound pretty geeky, but if the shoe fits….

The IP08 has 4 modules with up to two analog ports on each module. In the configuration I was testing 4 dual-port FXO modules were fitted. The problem was that the driver would not reliably detect all 8 ports. It kept missing between 1 and 3 ports, especially ports 7 and 8 (module 4).

Here is a photo of the IP08 with 4 modules (2 FXO and 2 FXS in this case) installed. The digital signals are daisy chained to each module, like a PCI bus. So the same signal connects to the same pin on each module. Many of the signals (e.g. for the SPI and TDM bus) are sourced from the square chip (CPLD, U20), under the black crocodile clip:

Here is the circuit for the IP08, check out page 3 (module headers J100 to J400) and page 5 (CPLD U20). Track down the BBSCLK net and note how it connects to each module.

High speed digital signals have fast rise and fall times and flow like pulses along the traces of the PCB. As the pulses hit the various terminations they can be reflected back. When there are multiple branches on a net the reflections can bounce back and forth and add and subtract from each other.

So rather than getting a nice square pulse shape, a pin on the net may see a distorted pulse.

Back to my bug hunt. I noticed that when a few of the modules were removed, all of the remaining modules were detected OK. This made me suspect a hardware problem, something to do with the load of the extra modules on sensitive nets. I spent some time checking out a few signals, like PCLK, and RESET, but these looked OK when compared to the Silicon Labs 3050 data sheet requirements.

Then I took a look at the SPI clock signal BBSCLK. This did look a little messed up, a photo of the waveform is below:

Now clock signals are especially sensitive to signal integrity issues. You need to make sure that the clock only travels “one way” (either up or down) to avoid false clocks being detected. In the photo above, you can see a “kink” in the falling edge at about the 1V level. This is definitely a no-no, and could lead to an extra clock edge being detected.

To double check I removed a few modules and sure enough the BBSLCK signal was cleaner. The load of the extra modules was proving extra paths for the signal and the resulting reflections were messing up BBSCLK.

I tried a few things to clean up the signal. I already had provision for a series termination resistor (R109) at the start of the BBSCLK net. The idea of these resistors is to dampen out any ringing due to reflections. I tried various values (from 0 to 47 ohms) but I couldn’t get consistent detection of all 8 ports. After some thought I cut the BBSCLK track between modules 2 and 3 and inserted a 2nd series resistor. The idea was to isolate the two halves of the net, using the new resistor to dampen reflections between the two halves. With both resistors set to 18 ohms I finally had reliable (10/10 times) detection of all 8 FXO modules.

Here is a photo of the same signal after the fix, note how the rising and falling edge is much cleaner (no kinks):

I emailed Alen at Atcom and asked him to try the same fix for his prototype IP08 – the fix worked for him too. However I think for the next batch of IP08s we should use a better clock distribution scheme, for example feed BBSCLK to 4 buffers, each with a series termination resistor. This will isolate the nets and prevent reflections from one module upsetting another. It will also allow indepenedent control of rise time and ringing on each net to assist in EMI compliance, as ringing and fast rise times broadcast a lot of RF energy.

You know I have been designing to avoid these sorts of signal integrity problems for about 10 years, e.g. being careful with layout, considering where high speed currents flow, and using series termination resistors. However (fortunately) this is the first time I have actually found a real-world signal integrity bug.
dvd able 504 mp3om 108 chant mp3mp3 big 06 sykeapplication 6070 mp3mp3 abominable putridity60gb reviews mp3plant mp3 ganja 10ftduniya 07 is mp3 mein aksar Mapacs loan fundingloans aipawards alfred sloan ploans farm 100definition loan 1307illinois student loan acsloan 300k homecalculator accelerated loan payment Mappayday acct savings loanadvance louisiana cash loanpersonal affortable loansfinancing aircraft loansgolf 100 loan coursepayday 1000 advance loan125 loans consolidation2000 cash loan fast Map

2 thoughts on “High Speed Digital Bug”

  1. Interesting dig and interesting description, respect!
    However, active buffering is overkill for sure. From the diagram looks like that bandwidth of the net is much wider, than signal requires. Simple RC filter, I mean a series resistor and a following small capacitor to the ground, all just near to the signal source, or even a resistor plus thick ground wire close to clock line all along path should work as good in terms of filtering “klink”s and lower RF emission as well. Tracing clock to all 4 modules as 4 separate lines with equal length should work also fine.

  2. Thanks Andrew, thats is some excellent advice. You are clearly in the High Speed Digital “Guru” league! You have got me thinking about the concept of the “bandwidth of the net being wider than the signal requires”. Fascinating idea.

    Why would the 4 seperate lines work so well? I guess the idea with the active buffers was to provide some isolation, perhaps it’s the same idea?

    Thanks,

    David

Comments are closed.