Bit Error Rate Test
nezhate
I want to implement a BERT test on FPGA. Can anyone give or point me
to some good documentation for understanding how BERT test works?
Thanks.
rickman
BERT is a technique rather than a functional unit like a UART. It
just means you are measuring the error rate of a communication
channel. This typically involves either the test equipment operating
in a looped back circuit so that it sends a data pattern and compares
the received data to that pattern counting the errors, or two units
are at opposite ends of a channel with one sending a predetermined
pattern and the other receiving and comparing to the expected
pattern. This pattern is often a pseudo random sequence to assist in
synchronizing to the pattern, but is ad hoc to the application.
So you have to decide how to do BERT depending on your application.
Is this a conventional app or a proprietary app?
Rick
Allan Herriman
I've implemented BERTs in a few products at rates up to 10Gb/s in
FPGA.
I have not found good, free documentation describing how it's done
properly though.
So I will give you some pointers here.
Firstly, I assume that you mean a traditional serial BERT. These are
intended for testing serial bit streams. BTW, Don't use these if you
have a parallel bus; they don't produce enough transitions to stress
the DUT properly.
The serial BERT patterns are actually standardised. Standardisation
helps to ensure that a BERT receiver from one manufacturer will lock
to a BERT generator from another manufacturer.
Please refer to ITU-T O.150 through 153, especially O.151.
Free download from official site here:
http://www.itu.int/rec/T-REC-O/e
You choose the pattern (e.g. 2^23) based on the run length
requirement. Since (I assume) you are designing your system, you
should already know the expected run length on the serial line. Choose
a pattern to match that.
E.g. the 2^23 pattern from O.151 has a maximum run length of 23.
The hardware for the O.151 patterns are described in that document as
LFSRs, e.g. shift registers with linear (i.e. xor) feedback. This is
fine for bitrates up to some hundreds of MHz; the LFSR will produce
one bit of output per clock.
For bitrates higher than that, you will need to convert the LFSR to a
parallel form that produces several bits per clock. This allows you
to keep the clock rate to something managable in an FPGA (e.g. <
200-300MHz). E.g. The last one of these I did (SONET, 10Gb/s) had a
clock rate of 155.52MHz and a 64 bit bus.
I won't describe the process to convert the "serial prototype" to a
parallel form, but you shouldn't find it difficult to work out the
details yourself. (Or start another thread :)
First gotcha: The O.151 generators all have lockup states. For
example, the 2^23 pattern is locked up when it outputs more than 23
zeros in a row. It will continue to produce all zeros until you
detect the problem and kickstart it by injecting a one into it
somewhere.
The measurement process is best described with a diagram:
"Serial prototype" of Generator:
+------------------<----------------+
| +---------------<----------+ |
| | | |
| | tap1| |tap2
| | | |
+-----+ A +--------------------------+
| XOR |-+--->| >> Tx Shift register >> |
+-----+ | +--------------------------+
|
|
|
+ Output of generator
|
|
|
errors +-----+
------->| XOR | This models the channel,
+-----+ which adds some errors.
|
|
|
|
|
"Naive" serial model of receiver:
|
+--------+
| |
+-----+ | A' +-----+
| XOR |-|------| XOR |---> errors out
+-----+ | +-----+
| | | +--------------------------+
| | +--->| >> Rx Shift register >> |
| | +--------------------------+
| | tap1| |tap2
| | | |
| +---------------<----------+ |
+------------------<----------------+
If the channel doesn't inject any errors (i.e. the "errors" signal is
0), the same bits will pass through both Tx and Rx shift registers,
and the feedback point A' in the receiver will match the feedback
point A in the transmitter. In this case, the "errors out" signal
will be low.
Now consider injecting a single bit error, by making the "errors"
signal high for one clock. This will produce a mismatch between the
receiver input and point A', which will make "errors out" high (good).
However, the bit error will also pass through the Rx shift register.
As it passes tap1 and tap2, it will also make "errors out" high. This
effect is known as Bit Error Multiplication (when applied to
scramblers), and is a problem if we are trying to get an accurate BERT
measurement. This is why I described that receiver design as "naive".
Here's how we fix it:
"Improved" model of receiver:
|
+---+---------+
| |
+-----+ | A' +-----+
| XOR |-+---|-------| XOR |---> errors out
+-----+ | | +-----+
| | | +-----+ +--------------------------+
| | +-| MUX |-->| >> Rx Shift register >> |
| | +-----+ +--------------------------+
| | tap1| |tap2
| | | |
| +--------------------<----------+ |
+-----------------------<----------------+
Now we have a multiplexer that can select either the receiver input,
or the locally generated feedback signal as the input of the shift
register.
We have introduced the concept of a "mode". In Unlocked mode, we take
the input from the line, as before. When we don't see "errors out"
high for a while, we can switch to Locked mode, and connect the
locally generated feedback signal 'A' to the input of the shift
register. The Rx Shift register is now completely decoupled from the
Tx shift register. They will have the same value, however, and each
incoming bit error produces a single high signal on the "errors out"
line. These should be counted, etc.
If "errors out" shows an excessive number of errors (e.g. high for
more than about 25% of the time), we should switch back to Unlocked
mode. N.B. A completely bad input signal will produce a BER of about
50% (not 100%) which is why we should set the unlocked threshold at
less than 50%.
I hope this helps.
Regards,
Allan
Symon
news:94fts3h0p9mp4b49r...@4ax.com...
> "Improved" model of receiver:
> |
> +---+---------+
> | |
> +-----+ | A' +-----+
> | XOR |-+---|-------| XOR |---> errors out
> +-----+ | | +-----+
> | | | +-----+ +--------------------------+
> | | +-| MUX |-->| >> Rx Shift register >> |
> | | +-----+ +--------------------------+
> | | tap1| |tap2
> | | | |
> | +--------------------<----------+ |
> +-----------------------<----------------+
> If "errors out" shows an excessive number of errors (e.g. high for
> more than about 25% of the time), we should switch back to Unlocked
> mode. N.B. A completely bad input signal will produce a BER of about
> 50% (not 100%) which is why we should set the unlocked threshold at
> less than 50%.
>
> I hope this helps.
>
> Regards,
> Allan
Hi Allan,
There's a better way to detect whether to resync or not. There's no point in
resyncing unless the incoming stream has 'slipped' one or more bit positions
relative to where it should be. When this situation arises, the 'errors out'
output of the 'Improved' circuit you drew (see above) will have the same
PRBS on it but with a phase shift of some amount. This is because a PRBS
xored with a shifted version of itself is the same PRBS but shifted some
other amount. I'll leave the modulo arithmetic that proves this as an
exercise for the reader! So, the trick is to then feed this 'errors out'
signal into your first 'naive' circuit, this one,
'errors out'
V
> |
> +--------+
> | |
> +-----+ | A' +-----+
> | XOR |-|------| XOR |---> slip errors out
> +-----+ | +-----+
> | | | +--------------------------+
> | | +--->| >> Rx Shift register >> |
> | | +--------------------------+
> | | tap1| |tap2
> | | | |
> | +---------------<----------+ |
> +------------------<----------------+
>
and only resync if 'slip errors out' is very low. So, in summary, resync
when 'errors out' is often high, maybe above 25%, but 'slip errors out' is
often low, maybe a few percent. This improved method makes it easy to
measure bit errors in circumstances where there are burst of high bit error
rate. The circuit won't accidently resync because of the burst unless a
genuime slip occurs.
HTH., Syms.
p.s. I think this method was invented by a German guy named Gelbrich.
Allan Herriman
wrote:
Nice. I'll try that one the next time I have to implement a BERT.
Regards,
Allan
nezhate
@ Allan : thanks for this link.