In search of a better SerDes

Oh no! Another dry technical article! True, true. Just pass it by if you’re not interested.

Serdes sounds like a Greek word, but it isn’t really. There are some people with the name Serdes, but it is uncommon. I learned it as an engineering acronym thus (lightly edited):

A Serializer/Deserializer (SerDes) – usually pronounced “sir-deez” – is a pair of functional blocks commonly used in high speed communications to compensate for limited input/output. These blocks convert data between serial data and parallel interfaces in each direction. The term “SerDes” generically refers to interfaces used in various technologies and applications. The primary use of a SerDes is to provide data transmission over a single/differential line in order to minimize the number of I/O pins and interconnects.

Electronic Art

I am trying to work out some cool things to do with LED arrays that would respond to environmental or observer inputs. There are many pieces to such a system. This includes the possibility that the display itself may be some distance from the electronics that collects the input signals and decides what the display should do. The same way a computer monitor can be separate from the computer. And in this case, the two are connected with a cable.

Some of us remember the old printer cables. They were thick, had up to 25 separate wires in them, and couldn’t be much longer than 15 feet. I could probably use such a cable in my projects. But that’s a lot of bulk, and it comes with many limitations. Those cables connected a parallel port on the computer to a parallel port on the printer. There were usually 8 data lines plus a bunch of handshaking signals to make it so the computer would not send data faster than the printer could print it out. If you wanted to get a lot of data back from the printer, you could add another 8 data lines going in the opposite direction.

8 bits can encode into 256 different numbers (0 to 255). That’s enough for an alphabet – both upper and lower case – and a bunch of other symbols. Each symbol has a number “code” that stands for that symbol. Both ends of the line have to use the same code system.

An 8 bit parallel system could go pretty fast; millions of symbols per second. But try pushing parallel data through a long cable that fast and you will quickly run into problems. You would need to shield the cable so external signals won’t interfere with it, and so it won’t radiate signals into external equipment. And the wires in the cable, when they get quite long, resist fast signals going through them in at least three different ways (resistance, inductance and capacitance). So if you want to send data fast through a long cable, you have a whole hardware design challenge on your hands.

SerDes concept

Illustration of the SerDes concept. Original graphic by Gr̩goire Surrel РOwn work, CC BY-SA 4.0

The solutions to these problems usually involve reducing the number of wires carrying signals (ideally just one pair would be enough) and creating special hardware interfaces that alter the signals so that they will make it through the cable successfully, even though the cable presents various barriers to proper transmission.

A standard solution for many years was the “RS-232” serial cable. In this system the signal is amplified to make it more resistant to interference and cable attenuation. And the signal is “serialized” so it only has to use one pair of wires. That means each symbol of 7 or 8 bits would be transmitted as a sequence of bits that would have to be reassembled into 7 or 8 parallel bits at the receiving end. That was an early SerDes system. But we didn’t call it that in the old days. The acronym only came into wide use after the internet and its various forms of information exchange came into wide use. The term commonly refers to high speed data transmissions, but the basic concepts are the same regardless of data rate. My projects use quite low data rates just to make sure I don’t run into too many design problems and can use cheap parts.

The RS-232 standard could probably work for me, but I wanted to try another more modern data transmission standard, TIA-485. (RS = Recommended Standard, as published by the EIA, Electronics Industries Alliance, but now taken over by the TIA, Telecommunications Industry Association). This standard uses two wires for each signal plus a third wire used as a ground (zero volts) reference. The signal is transmitted in an attenuated form, differentially. That means a “zero” would be transmitted by putting maybe 3-1/2 volts on one wire and 1 volt on the other. And a “one” would be transmitted by reversing those. Smaller signals in a cable create less external interference and are easier to pass through longer cable lengths.

I have a connector that is used for MIDI (Musical Instrument Digital Interface) that has five pins, which means it can carry two differential serial signals (or 4 RS-232 signals) plus a ground reference wire. I wanted to use this connector and a 5-wire cable, but there was one problem:

SerDes Timing

Just as in the old parallel printer cables, where handshaking signals were necessary to tell the printer when a symbol to print was put onto the connecting cable, and tell the computer when the printer was busy, serial systems also need a way of at least telling the receiver when the transmitted data is good, how fast it is going, and when an entire symbol has been sent. This requires, minimum, clock and end-of-symbol signals for data rate and data synchronization. In the RS-232 system, the data rate had to be set at both ends in advance. And the end-of-symbol signal was coded into the data stream. It takes a computer to figure out how to decode this data stream, but if you send all three signals separately, you don’t need any computing at the receiving end. Deserialization can be done with one piece of hardware called a shift register.

But I can’t transmit three signals over a five-wire TIA-485 cable, only two. So I thought I’d figure out how to combine the three signals into two so that my system could work with the hardware I have. I devised a rather simple system to do this, and built an initial working system several years ago for my “Christmas” project (Christmas because it used strings of holiday lights for the visual display). Recently I have built two more systems that use this method.


I like to re-design systems each time I build them. This is partly because I might not have the same parts available that I used in an earlier design. Or it might be just to explore different ways the problem could be solved. All the heavy work in my SerDes system is on the transmitting site. The receiver is very easy to make. And for this transmitter design I wanted to use counters to run ICs (integrated circuits, now often known as “chips”) called multiplexers. You put parallel data on the 8 inputs of a multiplexer, then tell it which input to put on the output using a counter. And if the counter repeats a regular pattern (as most do) then the parallel data at the inputs will come out of the output in a predictable serial sequence. And so you have achieved serialization.

In my first design I was getting “glitches” at the outputs of some of my multiplexers. This is because I was using “ripple” counters. In this type of counter, the counting outputs don’t all change at exactly the same time. They might be a little off (usually much less than a microsecond, but that’s enough time to cause trouble). In other words, when changing from count 1 to count 2 for instance, the ones bit has to change from one to zero, while the twos bit has to change from zero to one. If the twos bit lagged a little, both outputs might be zero for a split second, telling the multiplexer to go to the wrong input. Such glitches can be filtered out, which is what I did in the first design. But in the second design I decided to try a different counting scheme, where only one counting bit would change at any one time. This should make counting glitches impossible (it does). But it means the count is no longer in number sequence. In other words to do this with a 4-count pattern, you have to use the pattern 0-2-3-1 (or 0-1-3-2) to get a glitchless count. This different sequence is not a problem when using a multiplexer, though it is more confusing to design if you are used to using ripple counters that count 0-1-2-3 (etc.).

I looked at the waveforms associated with this kind of counting, and they were just two square waves offset by one count. I found a PDF online that describes how to implement this kind of counter. It’s called a “quadrature” counter, and it’s pretty simple to do. Getting a similar sequence of 8 is a little more tricky, but basically just interleaves a quadrature signal with a square wave. I built my second system this way and it works fine (though I had to scratch my head a bit to get the input sequence right, as it is sensitive to the place value given to the various counting signals).

quadrature waveform illustration

A four-count pattern implemented using a quadrature counter.

What form should the data take?

So I now have a hardware system that can be used with either 2 TIA-485 signals over quite long distances (if the cables are made well) or with 4 RS-232 signals (but not the RS-232 encoding system). The RS-232 version is much easier to build, but does have distance and speed limitations compared to the TIA-485 system.

The original intention of the system was to enable transmission of 8-bit-wide signals that would be used to control an array of LEDs. But it could also be used to transmit serial control streams of any bit length. This means a wide variety of displays could be controlled, as long as they didn’t have to change at a very fast rate. In other words, we’re not talking about full-motion video, like TV, but that’s not the sort of display I’m working with. My average display contains less than 100 LEDs, while a modern TV screen contains millions.

I have also tried transmitting analog data using digital serial techniques by using pulse-width encoding, which is very simple to implement in hardware. This gives me the option of using digital data transmission instead of long analog signal lines. This may come in handy in some of my projects.


Tags: , , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s