Before we get too deep into the technicals of the project, I wanted to take a moment to explain why I'm even doing this. Obvious question, why not just bundle up a Raspberry Pi and stream it?

SerDes is a portmanteau of the words SERializer and DESerializer so when we talk about serdes, it's referring to the whole link. A modem is another portmanteau of MODulater and DEModulator which takes digital signals and makes them analog. What both of these technologies do though is convert data from one format to another format to easier handling, the data remains the same but it's just structured in a more convenient format.

SerDes devices serialize and deserialize a data stream with the most obvious and primary benefit of reducing wires. This was the main driver of needing GMSL because the automotive industry wanted cameras and displays throughout the car. The issues quickly became cabling and EMC.

Let's use an example of a parallel 10-bit camera: each bit is a signal, plus the timing signals (HS, VS, and DE), plus low speed communication to program a camera (let's assume I2C), and power. That's over 15 wires to get a fairly low resolution camera. Each signal is a wire that can fail. All are moving at a decent clock frequency requiring the bits to be very synchronized but also creating radiated emissions. On top of that, there are the IR losses of the wire that degrade the signal limiting the reach. 

Additionally, in automotive and any robotics applications cabling translates to weight

Another example a lot of us are familiar with is the infamous printer cable:

It was big, bulky, and carried a lot of wires. However, when you do a quick Google search of "printer cable" all that comes up are USB cables. USB standing for Universal SERIAL Bus, so you may not realize it but you've been using a form of serdes already in your day to day!

So how is the data sent in a serial format? Well, data is data and engineers get creative solving problems. Serdes from a very high level puts the data into packets versus discrete parallel signals and the packet of data is clocked in and out faster to reduce the number of wires if the system can accommodate generating a faster clock.

There is numerous resources describing how serdes works so I won't go deep into the details (unless you wanted my take) but essentially below is a simplified block diagram of the serdes operation. The serializer clocks in all the parallel signals then packetizes the data and clocks out the data at a much faster rate. By the time the packet is sent out, the serializer is ready to packetize the next set of data. The deserializer's role is to take that data and depacketize the stream into the output interface format.

This all happens so fast that it shouldn't even seem like there is something else happening between the sensor and processor.

This is great but why go through the trouble of using serdes in the first place. 

By using serdes devices, we can now extend where we put the camera and with GMSL, simplify the overall system architecture. This is because the GMSL serdes not only transmits the high bandwidth data, but it can also packetize GPIOs, I2C, SPI, UART, etc on the single cable. Additionally with coax cable applications, we can send power over the coax with a simple inductor network. GMSL is also automotive certified and will adapt to extreme temperatures.

Going back to the original design problem with a GMSL link, I can put the camera, I2C communication (I'll be using QWIIC connectors) and power all over a single wire out to a camera that is remote in my backyard. And given that it gets cold where I'm at, the cable will be able to adapt to the changing temperature conditions without degrading the signal.

I'll be getting into the different aspects of these features as we go through the design, but let's take a look at the serdes pair I'll be using.