Hello guys,

    I'm not entirely sure how these blog posts should look like, but I'm going to give it a try and hope I won't be off by too much. I figured I should play a little with PRBS and tell you what I did, since it's one of the most prominent features of the Agilent 33600A series and maybe shed some light on why and when it's needed, so those of you who didn't know about this until now, can make a more informed decision when you're going to buy your next waveform generator.

    PRBS (pseudo-random binary sequence) is a stream of random bits, that is usually used to test high speed data lines, where bus capacitance has a higher impact and where reflection and cross talk related issues are more likely to surface with this kind of signal. It's a fairly simple concept, but when you have it on a waveform generator, you get all the perks that come with such a device, like quickly adjustable period (how often the same sequence of bits will occur) as well as amplitude, offset and data rate settings.

    Low Data Rate

    Although it truly shines when you deal with high data rates, you can also make good use of PRBS at lower speeds. The moment I read about it, in the specs of the 33600A, I  had several flashbacks. One of them was about a one-off power supply I designed, where because I didn't care much about the communication speed, I used some cheap optocouplers and once the PSU was done, I spent quite a bit of time figuring out what's the best bit rate I can get.

fig. 1

    I re-created the isolation circuit I used in that PSU project and I managed to take two screenshots that exemplify the difference between a square wave and a PRBS waveform. Difference that makes itself visible even at low data rates, which is pretty much the point I'm trying to make.

    You can obviously test a low speed bus with square waves alone, but you'll never get the same amount of information as you do with PRBS. Even if you don't get anything weird, you still have a higher level of assurance when you test it with real-looking data.

    The small circuit responsible for this is found in fig. 1 (note that the output is inverted). I put a PRBS stream trough it and increased the bit rate until the resulting waveform stopped having complete edges, then I switched to a square wave with the frequency equal to half the data rate, since 1 Hz = 2 bits.

40 kHz square input - doesn't look that bad, does it?

80 kbps PRBS

    I think the difference is striking and it shows that PRBS, even at low data rates, tends to reveal things that other test signals might miss. The reason why it was still generating full edges with the square wave signal, is because it was not getting fully turned on or off, while with PRBS it had the chance to do just that, which is when the latency of either the LED, the phototransistor or both came into play and became visible on the output.

    High Data Rate

    At high speeds, the signal gets affected by lots of factors so the only way you can properly test the bus is by sending real data and checking that you can receive it properly. When doing this over long distances, a second waveform generator can take advantage of the fact that PRBS is predictable and generate the exact same signal at the other end of the line, so you can check the data you are receiving, against the data you are generating.

    If we take a look at the following waveform, we can see the effects that parasitic capacitance has on this signal.

PRBS @ 150 Mbps into breadboard bus

    By simply looking at it on the scope, we can't tell if the receiver will be able to detect each bit and we can't really figure out what is the maximum bit rate we can push through this bus, because we can't be sure if or at which bit rate the generated edges cross the minimum and maximum levels that are needed to be read as a low or high value.

    I don't normally deal with high speed buses, but just for kicks, I decided to make the following experiment: I wanted a data line that is bad enough to easily fail, so I put a simple resistor on a breadboard (yeah, that's all it takes) and considered that my receiver is an FPGA. The goal was to reliably detect what is the best data rate I can push through that bus.

    To actually test such a bus, we can either use a logic analyzer or a device that works in the same parameters as our intended receiver, that can compare the locally generated PRBS with the received one. Since I put this experiment together on my bench, I simply used the same signal, but sampled from two different points in the circuit: before passing it through the part that distorts it and after, basically giving me two signals, a clean one and a distorted one.

    As the test device, I used an FPGA and in order not to deal with clock regeneration, I used the second channel of the 33622A as the clock, this allowed me to have the signal and the clock perfectly synchronized (check the notes). Alternatively, if clock regeneration is already implemented, the second channel can be used to source an identical signal to be fed directly to the test device.

    The only thing the FPGA had to do was to compare the clean and the distorted signals, on each clock edge and, if there was a difference, to power on an LED. I did not make a video of me turning the knob, but for what it's worth, the error LED turned on at around 60 Mbps.

PRBS @ 60 Mbps into breadboard bus

Ch 1: Distorted signal. Ch 2: Clock. Ch 3: Clean signal.

Well, that's pretty much it. At the end of the day, testing any bus is done by sending data and checking it at the receiving end. PRBS is offering that data, the means to reproduce it and when generated by a waveform generator like the 33600A series, quick adjustments to any of the parameters.

Notes about the 33600A (hopefully Agilent will address this):

    1) When generating PRBS on one channel and another signal on the second channel, there's no option for frequency coupling. I understand that bit rate is not frequency, but this doesn't mean that it shouldn't be possible to couple them. Being able to generate a clock signal that adjusts itself in frequency to match the PRBS on the other channel would be extremely useful.

    2) Another feature that would be very useful, is to be able to adjust the phase of each channel even in tracking mode, as this would allow one of the outputs to trigger delayed events, while the other output could be used as the test signal.

In the absence of the first feature (1), the second feature I described (2) would have saved the day. Since both are missing, my only option was to manually change the bit rate, calculate the needed clock frequency (1/2 of bit rate) and manually set the resulting frequency on the other channel.

Thanks for reading,

Razvan