Longer cable not working for FPGA - Page 1
Forum section: electronics / beginners

author: mazraedar
author_rank: Newbie
timestamp: November 25, 2021, 10:55:05 am
content: Hello everyone,I'm new to this site and also new to forums overall ~I'll do my best to describe my issue and also spend a bit of time on the forum to help people if I can.Here's what works pretty fine :I use a cable connecting 50 pins from a PCB card to another. The resistance of the cable is 0.4 ohm for each pin and the calbe is about 20 centimeters longs (8 inchs for fellow Americans). The signals that are transmitted come directly out of an FPGA (no impedance adaptations) and go directly to another FPGA. Some siganls are continious, some others are alternative. The cable is shielded.Now the issue starts when I use a longer cable ( 1.5 meters ( 3.2 feet) ). The resistance of the cable is 0.6 meters so I thought that it shall be fine, but I encounter numerous defective communications between the two FPGAs.Anyone knows what can I do to properly use this cable ? Both cables are shielded and twisted the same way, and there's almost no difference on their resistivity ~I think about modifying the VHDL code, but I can find any option to amplify a signal (assuming my issue is due to a power lack).I hope I have been clear enough,Thanks in advance

author: Zero999
author_rank: Super Contributor
timestamp: November 25, 2021, 11:33:51 am
content: It's probably due to the impedance mismatch, causing ringing and reflections. This wasn't a problem with the short length of cable, because it was electrically short, compared to the signal rise/fall times. The longer cable acts as a transmission line.You could try adding damping resistors in series with the outputs: try 100R. This will absorb any reflections and dampen oscillations.

author: mazraedar
author_rank: Newbie
timestamp: November 25, 2021, 12:32:28 pm
content: Thank you for your answer, I'll try to do that and come back to this as soon as possible. The pcbs are already printed so I have to use an external modul to do this.Thanks again.

author: Manul
author_rank: Super Contributor
timestamp: November 25, 2021, 04:22:54 pm
content: Welcome to the forum.The fact, that you are talking about cable resistance beeing 0.4 or 0.6 Ohms indicates that you lack understanding with what you are dealing in your circuit. You have signals with fast edges, containing very high frequency components, likely into 100's of Mhz range. Also you likely have some signal timing requirements.So you have a cable to send these signals. And 1.5m is big length. What you are dealing with is transmission line and propagation delay. It was already mentioned, that you should have some form of impedance matching. That is a good start, but also don't forget, that there is propagation delay, which sets the limit for speed and distance of clock synchronous data transfer.Signal travels aproximately 30 cm / nanosecond. 1.5m is 5ns delay one way and 5ns delay back. Depending on your interface type and signaling speed this could already be critical. Image that there is comunication between master and slave. Master sends clock, slave receives clock, slave sends data to master, master reads data. Both of them synchronous to master's clock. With a cable of 1.5m master will receive with an extra 10ns delay. Depending on speed and timing requirements, data could be delayed so much, that the timing is not correct and transfer gets corrrupted. On some interfaces it is important to also keep signal line length equal (or matched to some proportion). Have you seen wiggly PCB traces on high speed data bus in PC motherboard? These wiggles match the propagation delay of different signal lines. Yes, that is really so important at high speed.General rule - if you can, avoid cables and long trace lengths, makes life easier for any given design.

author: mazraedar
author_rank: Newbie
timestamp: November 25, 2021, 05:23:04 pm
content: Thank you for your answer, I learned a lot thanks to it.Does that mean that I could eventually resolve my issue if I divide my clk frenquency by a significant value ?Thanks again

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 25, 2021, 05:27:25 pm
content: Depending on the FPGA, you may be able to adjust pin drive strength, slew rate and maybe input threshold to improve things, but either way you need to look at it with a scope to see what's actually hapenning.

author: mazraedar
author_rank: Newbie
timestamp: November 25, 2021, 05:43:47 pm
content: Thank you for your answer.So I already did a comparative analysis between the two cables using a scope, and I noticed no significant differences between the two signals, the longer cable was just a bit noisier.But according from what I learned right now, I think I'll try to compare the phase of the signals at the beginning of the cable and at its end. Maybe I'll be able to have an interresting conclusion.Thanks to everyone so far, it helps a lot.

author: Manul
author_rank: Super Contributor
timestamp: November 25, 2021, 07:57:46 pm
content: Good suggestion by mikeselectricstuff about configurable output drive strength. This could help with ringing, definitely check that out.Quote from: mazraedar on November 25, 2021, 05:23:04 pmYes, that's possible. You need to check timings and signal integrity to evaluate how fast you can go.Quote from: mazraedar on November 25, 2021, 05:43:47 pmYou also should check phase between clock and incoming data lines (you haven't told us what interface you have, so I'm just assuming). Like in datasheets where they give timing diagrams, for example, SPI bus. CLK is overlayed with MISO and there are timing (phase relationship) requirements given.

author: Kalvin
author_rank: Super Contributor
timestamp: November 25, 2021, 08:36:39 pm
content: Quote from: mazraedar on November 25, 2021, 05:23:04 pmNot necessarily. The culprit is not the the clock frequency per se, but the signals' slew rate (read: signals' rise and fall times) which determine how bad situation you have. Especially clock signals need good wiring (like twisted pair if using a ribbon cable) and they need to be terminated properly in order to eliminate signal ringing, false triggers and cross coupling to other signals.Likemikeselectricstuffwrote, you should be able to control FPGA's output slew rate, and use as slow slew rate which is practical.If you do not have a cable with twisted pairs, you should try to arrange your ribbon cable so that every other wire is a signal and every other wire is a ground.Edit: AsZero999wrote above, you need to terminate the signals. Placing a 100 ohm resistor in series with each output has worked pretty well with a ribbon cable. You may need to experiment with resistor values a little in order to find best resistor value for best matching, but 100 ohms is a pretty good starting point.

author: radiolistener
author_rank: Super Contributor
timestamp: November 26, 2021, 01:24:25 am
content: As I know FPGA output is not intended to drive high capacitance load. You're needs to use buffer circuit between FPGA and long wires.Also a long wire for a high frequency signals may raise another issue with impedance mismatch and ringing.

author: Kalvin
author_rank: Super Contributor
timestamp: November 26, 2021, 11:29:22 am
content: You may want to study some material about transmission lines. For example this is quite practical:https://www.analog.com/media/en/training-seminars/tutorials/MT-097.pdfYou may also want to simulate your circuit with a simple model shown in attachment. You need to explore different termination/matching topologies (source termination, end termination, combination of source/end termination), adjust R2 and R3 accordingly, and see how their values affect the signal quality seen by the FPGA input (VIN). You can also change the output's slew-rate (Voltage source V1, rise and fall times), and study how it affects the signal quality seen by the receiver.The circuit uses a lossless transmission line for a twisted pair with 100 ohm impedance. This model is good enough for your short 1.5m cable. If you want to experiment how a coaxial cable will behave, just change the cable's impedance to 50 ohm.As this initial simulation without proper cable termination shows, the clock signal VCLK (green line) is not quite good when received by the other FPGA (VIN, light blue).This simulation model doesn't simulate the signal cross-talk in the cable. But using proper source termination, and a twisted pair or ribbon cable with every other wire as ground will typically give you good results.

author: mazraedar
author_rank: Newbie
timestamp: November 26, 2021, 03:27:43 pm
content: Thanks again everyone for all of your answers, it really helps a lot.Overall, it seems that I'll have to manage the slew rate and also the drive in the fpga, add a dumping resistance and maybe reduce the frequency of my signals.I'm using LVDS for the twisted pairs and the frequency is about 600MHz, which seems to be a bit high for a long cable communication. My PCBs are already printed so it'll take a bit of time for me to find an adaptative module for the tests, but I'll come back to this thread as soon as I'm done to explain what I did and hopefully tell what made things work.Thanks again everyone