Scrambled Bus
This special newsletter goes out to my colleagues at Hewlett Packard, in celebration of 10 years of working together. Thanks so very much for your support over the years. It has been a pleasure working with you and I look forward to continued visits to Houston.
Scrambled Bus
This article springs from discussions held during my recent seminar at HP in Vancouver, Washington. That particular division designs DeskJet printers.
Each printer incorporates a ribbon cable, which I am sure you have seen if you ever popped open one of those printers to replace the ink cartridge, or just to admire the mechanical intricacy of the design. The ribbon provides electrical power and signals to the print head, which slides back and forth (amazingly quickly) on a metal bar.
At present the ribbon is implemented using a single-layer flex circuit with no shielding. Apparently, the data rate is sufficiently slow that emissions compliance may be obtained simply by limiting the slew rate and amplitude of the data drivers. Unfortunately, as the printer gets faster with each generation, and the dot matrix more dense, you can predict that the aggregate data rate on that cable has got to increase, and that, eventually, unless something is done, the product may exceed its limits on acceptable radiated emissions.
This difficulty reminds me of a similar design problem that occurs in laptops. At the joint between the laptop body and the screen you will often find a single-layer flex. All the data necessary to drive the screen passes through this connection. Similar difficulties have ensued with increasing data rates.
Both problems also suffer from mechanical constraints involving the flexibility and reliability of the connection. The solution in both cases has been the use of single-layer flex-circuits.
At this point I should mention, for those of you not acquainted with flex-circuits, that while it is possible to make a two-layer flex with a solid reference plane on one side, the additional mechanical stress generated by the sandwich-like construction causes the flex to fail after repeated flexing. The reference-plane layer would dramatically lower emissions, but at the cost of reliability.
Two-layer flex circuits work well in applications that flex into place once, and then remain fixed. One-layer flex circuits generally appear in applications that must be highly flexible (as in printers and laptops).
Given that background, let's look at four ways to reduce radiation from a single-layer, unshielded flex circuit.
- Lower the transmitted amplitude
- 2Use differential signaling
- Use data coding
- Use scrambling
The first approach evokes an obvious tradeoff between radiation and susceptibility. I am going to assume familiarity with this idea and proceed to the other, more interesting, subjects.
Let's look afresh at differential coding as an example of a simple data code. The differential code maps each single bit into a pair of wires having opposite (antipodal) behavior. The net effect, presuming the wires remain sufficiently close, is that radiation from the first wire is cancelled by the equal and opposite radiation of the second wire.
Unfortunately, to its great disadvantage, differential signaling doubles the number of wires.
The radiation advantage of differential coding in the present application example derives from the raw, underlying cause of radiation: common-mode currents. The total common-mode current in a bus structure equals the sum of currents flowing on each wire of the bus. In a differential system, the differential action associated with each individual bit automatically nulls the total sum to a constant value, but doesn't it seem wasteful to double the number of bits just to obtain a constant sum? Aren't there other data codes that could accomplish this trick with less overhead?
I'm going to propose one simple code here, a variation of the 4B5B code popularized, among other places, in FDDI and 100 Mb/s Ethernet. This code maps each 4-bit data group to a 5-bit code. This process adds 25% to the total number of wires you need to convey the coded data, a distinct disadvantage, but not as bad as the 100% added with differential coding. The balance of the 4B5B code is not perfect, but it is good enough to present a viable alternative to differential schemes in our present application. I will work with a single four-bit group here, although obviously you could extend the scheme to any multiple of four bits, with a fifth bit added to each 4-bit group.
Figure 1 illustrates the four-bit bus before coding. It conveys a simple, 16-word repeating pattern. The four waveforms at the top of the graph represent the data bits, and the blue waveform at the bottom represents the common-mode sum. Since there are four bits, the sum ranges from 0 to 4.
Figure 2 illustrates the same pattern after coding. The five waveforms at the top of the graph represent the coded data bits, and the blue waveform at the bottom represents the common-mode sum.
The sixteen values in my data code table are as follows, with the leftmost bit from each entry in the table coded into the topmost waveform of the figure:
| Allowed data code values | |||
|---|---|---|---|
| 01010 | 01100 | 01110 | 01101 |
| 11100 | 10011 | 10001 | 10010 |
| 00110 | 01011 | 01001 | 00101 |
| 11001 | 10100 | 10110 | 11010 |
As you can see, the data code is selected to guarantee that on each row either two or three bits are set. Therefore, the sum of the five output bits always equals 2 or 3, yielding a maximum peak-to-peak range of one, a 4:1 improvement (12 dB) over the common-mode range of unencoded data. This 12 dB reduction in common-mode signal amplitude translates directly into a 12-dB advantage in worst-case radiation.
Figure 3 presents the same examples in the frequency domain, using a 150-KHz analysis bandwidth. As you can see, the coded spectrum is better, but on this 10dB/div scale, I expected more of a difference. Where is the expected 12dB improvement?
To understand what has happened you must examine the common-mode signal for the unencoded data bus shown in Figure 1. The common-mode signal has a range of four, but only attains its extremes rarely, when you happen to hit on a data bus pattern of all zeros or all ones. If we want to stress this system to the worst case, we should exercise the bus with data patterns that slam all the bits up and down together (as you might get when printing or viewing a solid-gray background pattern composed of alternating black and white dots). This new comparison appears in Figure 4, 5 and 6.
Now in Figure 6 the 12-dB advantage of data coding stands out clearly at each and every harmonic of the repeating data pattern.
Could we extract further improvements with more sophisticated coding? Possibly, but it may not help as much as you would think. Even if you coded the bus perfectly, the drivers will not balance each other well enough to deliver practical improvements much beyond 12 dB.
As a next step, let's try scrambling. Right now, all the power in the transmitted signal is bottled up into a few very tall, very powerful harmonics. If you scramble the data sequence before transmission, and unscramble afterward in the receiver, the same total noise power spreads itself more evenly across the whole spectrum.
Figure 7 illustrates the radiation from a scrambled 4-bit bus, showing plain scrambling of a raw four-bit data bus (quite useful) and also scrambling followed by my 4B5B coding (even better). Overall, the improvement from the straight, unencoded, worst-case example to the best scrambled-and-coded version is better than 30 dB, and that should be enough to hold you for a while.
If you do a wider bus, the benefits of scrambling improve. With K sections of bus, the worst-case coherent power addition increases the noise by 20log(K), but with scrambling you only get a power-law summation of 10log(K). The additional improvement, 10log(K) can be substantial. For example, a 40-bit bus having ten sections would experience an additional 10 dB improvement, above and beyond the 30 dB already cited.
Best Regards,
Dr. Howard Johnson
For further study see these related articles:
DataCodingLowNoise.htm?
jitterfreeclocks.htm
The MathCad scripts used to calculate the examples in this
newsletter appear at:
zipped MathCad file (7_10mcd.zip) (You will need at least MathCad 2000i to read
this file)