What’s wrong with this picture? (Impedance matching and other things)

It’s about time we talked about high speed signals, impedance matching and signal reflections.  Take a look at this picture:

There is something clearly wrong with the image above, the pixels are all there and the colours are almost right, but what you’re seeing above isn’t what was sent from the FPGA. What I think I’m seeing here is signal trace length skew and signal reflections.

Signal skew is when one signal of a set of signals arrives at it’s destination before it’s partner(s). We’ve seen this before inside the FPGA, when a multibit register counts up or down and goes through a transiton to an out of sequence number along the way (f.e. 001 => 011 => 010). If the signals are only checked on the rising edge of a clock, called a synchronous design, then by the time the clock signal triggers a sample, the lines have settled down to a stable state. But what happens if the clock is so fast that it causes a sample before the signals have all arrived? Of course the result is bad and probably will cause freezes or latch ups. This Altera post talks about the problems of timing budgets and explains the problem well for one signal. Multiply that by a number of signals in parallel and the problems are compounded. The solution in most cases is to use a slower clock or adjust the RTL logic.

Now consider the length of the signal traces (wires) from the source of the signal to the destination in a parallel set of signals. Given that electrical signals propogate at a large fraction (but not 100%) of the speed of light, then it takes time for the signal to leave the source and arrive at the destination. Take a look at this great YouTube video describing the transmission process for more information.

With that information information in mind, my board design has two problems.

1. The signal transmission lines for the three video channels (Red,Green,Blue) are not the same length. Take a look again at my board design and you’ll see that my signals exit the ADV7513 video chip, turn right and exit the board through the HDMI connector. A combination of the right turn, which causes an impedance change and the different signal path lengths would cause the signals to propogate down the lines and arrive at the destination at different times. With a fast enough clock, they could be an entire pixel out from the clock signal. I believe this could be contributing to the Red signal arriving before the Blue and Green.
2. The signal paths do not have a ‘controlled impedance’ or impedance matching. At mentioned at 4:30 in the YouTube video, if a terminating resistor is applied at the end of the transmission line, then reflections are minimized. You can see the reflections as the ‘shadow’ to the right of the characters in the screen capture at the top.

Transmission cables, like the one depicted in the video are manufactured to have a specific impedance between the conductors. This is usually 50 or 100 ohms. Terminating these transmission lines with ‘standard’ 50 or 100 ohm resistors will reduce signal reflections.

How do you change the impedance of a copper trace on a PCB? Well, that’s a good question. I found this web site that will allow you to calculate the impedance for a given set of PCB attributes.

If I had added a ground plane on layer 3 of the board, this is the impedance I would see at the ends of the LVDS lines:

So if there was a 164 ohm resistor in the monitor or in this case, my capture card, then the transmission line would be matched to the destination and problems of signal reflections would be minimized. Unfortunately, the terminating resistor on the source chip (ADV7513) is 100 ohms:

This is much more sensible, given that single line transmissions are usually 50 ohms and differential transmission is twice that, at 100 ohms. Unfortunately, that means that I will see some reflections as the signal bounces around until it reaches stability. At the TMDS signal rates (400MHz for 800x600x60Hz, or 1.5GHz for FHD) these reflections do not have time to settle down before the next signal arrives and so the reflections cancel out the incoming signal. What I should have done is this:

If I used PCB traces that were 11.5mil wide and separated from a ground plane by 6.7mil, which is the thickness of the substrate between the top layer and layer 3, then I would have created signal transmission lines that had a controlled differential impedance of 100ohms and would match the terminator in the source/destination.

Unfortunately for me, I was short on track space and I omitted the the ground plane completely because I thought it was for limiting RF emissions only. Only after doing a lot of reading on signal transmission theory and watching some great YouTube videos did I realise the importance of this ground plane. I’m amazed that it worked at all!

It’s worth noting that signal reflections happen on all signals, but it’s only at the higher end of the frequency spectrum that it becomes a problem. Also worth noting that this problem didn’t show itself on the Samsung monitor that I started with, or the Samsung TV that I plugged into. I suspect that these use some sort of timing adjustment or alignments to synchronize the three colour channels (I would, if I were building a TV). This would allow for crappy cables to be used without spoiling the picture.

So the remedy for my custom board is two-fold:

1. Rotate the ADV7513 chip 90 degrees so that the TMDS lines point directly to the HDMI connector, eliminating the signal length mismatch.
2. Add a ground plane on layer 3 and increase the width of the signal traces to 11.5mil so that the coupling between the signal and the ground plane gives the required trace impedance.

Unfortunately for me (again), this means a completely new board design to accommodate the changes. I expect I’ll have similar issues with the SDRAM when I finally fix that as these run at 166MHz and will experience similar signal length and impedance issues. I also have to add UART lines between the supervisor and FPGA, replace the MRAM/Flash combination with an eMMC chip, rotate the FPGA clock chip, upgrade the regulators….the list goes on. Might as well start again from scratch with my new found knowledge! So this will be V3 of the board. I expect I’ll start this soon, but I have some mileage left in the old board!

Below is a capture of the current state of the support chip boot log. Yes, you’ll note that I have added USB support! I am able to plug in a USB1.x boot keyboard (this configuration is very specific) and capture the data from the keys. In the screen capture below, you can see the packet data received by pressing left shift, A then releasing A then releasing shift.

I have already added the CPC keyboard emulator operating through the PPI and sound chip, so I ‘just’ need to connect these two modules together through the support software. Pressing a key on the USB keyboard will send the USB HID packet to the keyboard translator, the translator will map the PC keys to the Amstrad keyboard layout and send the appropriate key presses to the 80-bit key matrix module. The CPC will do its magic and convert those 80 ‘switches’ back into a key stroke.

A quick note on USB device speeds. USB high speed devices rarely work in USB full speed ports. I had hoped that I would be able to use a high speed device in a full speed port, as all high speed devices must support full speed for device information and sometimes for enumeration. While I could detect high speed devices, I couldn’t get past the initial device config requests and into enumeration. These devices refused to enumerate at full speed, or enumerated randomly. The USB link uses a high speed chirp to negotiate high speed, and it’s at this point that the process fails. This is a major blow because I wanted to use a combined WiFi-BlueTooth USB dongle for communication, which will invariably be USB2 high speed. This device won’t be possible with the full speed host chip that is installed on the custom board. I’ll need to replace it with a ULPI high speed host. Another challenge, and another 480Mhz signal, but that’s for later.

If you’re interested in reading up on USB take a look at these two essential sites:

USB in a nutshell and USB Made Simple. Without these two sites, I’d struggle to understand the USB2 specifications. The important aspects of Chapter 9 of the USB spec is brilliantly laid out on these two sites. My thanks go to them both.

Parting thoughts…

I have been reflecting on 18 months of the project to date. A lot has been achieved, but not much to show for it. I’ve spent an inordinate amount of time building up the infrastructure, the debug tools, the supervisor and support software, and very little on the CPC emulation. I guess this is why a lot of FPGA retro builds happen on developer board first, as the infrastructure is already there. The keyboard is one of the last critical pieces of real hardware to connect to the board, so once the keyboard is done, I am hoping to focus more on the CPC modules.

Last Post < —- > Next Post