Noise / EMC issues or something else?

[Mario87]

Hi all,

I am working on a project where I have tapped into a GPU and feeding that data into an FPGA, currently the FPGA literally does nothing other than pass the data to other pins on the output, this will then go to a HDMI encoder and out to a screen. On my development board I have created a mezzanine card with the best part of 60 headers (mini antennas  ) and at the moment I am just trying to confirm the signal comes in on the input and passes out without any changes. For the most part it does, but there are points (especially on VSYNC, where DIN9 is the input to the FPGA and DIN14 is the output from the FPGA) where I seem to get random state changes on the output that are not there on the input.

I have checked VSYNC with an oscilloscope and it is seeming being pulled down a little bit on the FPGA output and a bit nosier too, but the input is fine (see images below). When you add in the noise that is being picked up on the FPGA output the signal can go as low as 0.89v which could be picked up as a state change. What could cause this?

I have also included images from the logic analyser, both zoomed out and zoomed in. The red horizontal line on the 1st image indicates the separation between input signals and output signals, the colours then indicate various issues and the subsequent pictures are zoomed in areas of these coloured zones (colour coded to make it easier to understand). Green is VSYNC which as you can see probably has the most obvious issues.

Any thoughts / suggestions welcome.

[nvmR]

Hey Mario,

It is a bit hard to debug without the schematic + fpga project etc.
A few things to make sure off the bat is that you have a good ground connection - you can measure it on a live board, and see what the difference between the ground pin is here and there.
Also, try to make sure all of the fpga pins are configured correctly, and don't have pull ups/pull downs. Make sure the output isn't driving anything too power hungry. Debug that by setting the problematic ones to high-Z and seeing what happens.
Further points of debug are to look at your fpga project and make sure that there are no relevant warnings. Depending on the exact design, try to make sure that the board can provide enough power to the FPGA.
Where is the daughter board power coming from? Is there really enough power on the relevant rail?

[oz2cpu]

you got a reel of alufoil in your kitchen ?
cut a piece same length of all your test cables, and fold it round all your test wires, individually
and connect each end of the foil to gnd, target and the debugger/logger

same ?

[Mario87]

Hey Mario,

It is a bit hard to debug without the schematic + fpga project etc.
A few things to make sure off the bat is that you have a good ground connection - you can measure it on a live board, and see what the difference between the ground pin is here and there.
Also, try to make sure all of the fpga pins are configured correctly, and don't have pull ups/pull downs. Make sure the output isn't driving anything too power hungry. Debug that by setting the problematic ones to high-Z and seeing what happens.
Further points of debug are to look at your fpga project and make sure that there are no relevant warnings. Depending on the exact design, try to make sure that the board can provide enough power to the FPGA.
Where is the daughter board power coming from? Is there really enough power on the relevant rail?

Hi, so in terms of the FPGA project it is literally just assigning the input and output pins together at this time for all the connections (ie "assign out1 = in1" for each pin). The FPGA is really doing nothing other than passing data from 1 pin to the next for now. More will come once I get this working properly and this was the exact reason I have the FPGA doing essentially nothing, to aid with debugging issues that are coming now.

I have checked all pins against GND, there is only 20mV maximum difference between GND and any given pin when the pin is being held low. There are no pull ups or pull downs configured in the FPGA design and setting various pins to high-Z makes no difference at all.

Only warning in the FPGA design is to do with the lack of a user defined clock as like I have mentioned above, the input & output pins are just mapped 1 to 1 to minimise the FPGA introducing any issues. This will be changed later.

The mezzanine card is being powered from the FPGA dev board FMC connector, all voltages are very stable and the only thing they are driving is an ADV7513 HDMI encoder which is powered off at the moment, but powering it on via the registers does not change things anyway.

Something I have noticed however is that on the clock pin specifically, when I disconnect my mezzanine board the original output works fine on a TV, but when I connect my mezzanine board the voltage gets clipped off top & bottom as it's being loaded up and the TV signal disappears (see 1st image below).

Then when I measure the input of the mezzanine card the CLK signal shows -20mv to 1.62v which is still fine (2nd image) and finally when it leaves the FPGA the voltage is as I expect (voltage up to 1.76v, as per the 3rd image).

Seems strange that the voltage on the clock pin is as expected out of the FPGA (1.76v peak) but the VSYNC is being pulled down by about 0.5v when it comes out of the FPGA compared to the VSYNC input (as low as 0.89v on the output with noise, which would explain the random pickups from the logic analyser).

Anyone got any ideas on why this would occur?

you got a reel of alufoil in your kitchen ?
cut a piece same length of all your test cables, and fold it round all your test wires, individually
and connect each end of the foil to gnd, target and the debugger/logger

same ?

Thanks, I will try to take a look at that and try it out during the week. Late here (23:40), so going to bed now. However I am beginning to think this is something else. Question is why is VSYNC being pulled down by about 0.5v on the output of the FPGA, but the clock is not. I have not checked, but I suspect the other signals I am seeing random state changes on are also being pulled down a little bit.

[Mario87]

Sorry, I realised I was an idiot yesterday. I had updated my scopes FW & OS the day prior and all the probe settings where changed back to default, including the "10x" setting. So I had my probe set to 10x and my scope set to 1x, all my results with the scope just didn't make sense and I didn't even notice. 

I have gone back and updated my previous posts with new images and info to match those images from the scope, so can you please re-read them if you have already looked in this thread and read them prior?

Thanks

[T3sl4co1l]

What's the mezzanine pinout?  Are all the grounds connected?  How well grounded is the riser board?  (I see top side pours, but it's not obvious if it's 2 or 4 layer, and if the pours are relevant (i.e., image planes of most/all signals), how well stitched they are.)

What bandwidth is the scope?  If it's just 100MHz, it's not really enough to see more than a hint of signal quality issues.

What logic analyzer?  Is it fast enough as well?  It's probably not getting great signal quality either, for the same reason (extra stub lengths), but also, wildly poor impedance as well (jumpers flying through air have Zo closer to 150-200 ohms, with extra coupling to neighboring lines).

Tim

[Mario87]

What's the mezzanine pinout?  Are all the grounds connected?  How well grounded is the riser board?  (I see top side pours, but it's not obvious if it's 2 or 4 layer, and if the pours are relevant (i.e., image planes of most/all signals), how well stitched they are.)

What bandwidth is the scope?  If it's just 100MHz, it's not really enough to see more than a hint of signal quality issues.

What logic analyzer?  Is it fast enough as well?  It's probably not getting great signal quality either, for the same reason (extra stub lengths), but also, wildly poor impedance as well (jumpers flying through air have Zo closer to 150-200 ohms, with extra coupling to neighboring lines).

Tim

Hi, answers to your questions below:

• Mezzanine pinout has all grounds connected. Pinout is essentially a GND, then 2 signals, then 2 GNDs, then 2 signals, then 2 GNDs, etc. All inputs are on the 1st 2 rows (C & D) and all outputs are on the 2nd 2 rows (G & H) of the 160 pin FMC connector, power rails come from the bottom end of rows C & D, but there is grounding on all 4 rows, which as I said are all connected.
• The board is just 2 layers, when I think about it, 4 layers may have been a better choice, but all those ground pours shown in the picture are tied to the GND pins on the FMC connector. There is lots of stitching all over the board, almost every part has some stitching between top & bottom GND layers
• Scope is a Siglent SDS 1104X-E, so a 100MHz scope, but it has been unlocked to 200MHz bandwidth and is essentially an SDS 1204X-E
• Logic analyser is a Digilent Digital Discovery running at 200MHz, but I do have the High Speed Adapter with twisted pairs so I can measure up to 800MHz, but this will reduce the number of signals I can capture from 32 down to 16 if recording 400MHz and down to 8 if recording 800MHz

I didn't at this time read / understand the whole details of what you're describing, but concerning signal integrity and droop:

* Try to couple each signal point to point in a twisted pair or side by side (e.g. like a ribbon cable adjacent pair)  along with the signal ground return for that signal.  The ground for a signal is literally as important as the signal itself at AC frequencies.

* If you have any kind of droop / glitch when you connect the peripheral (FPGA) board (ignoring anything to do with logic analyzer / DSO probe connections etc.) for a given signal you should verify that your I/O bank VCCIO and I/O type settings and logic levels for the FPGA input match the signal source output logic level / type / supply voltage.  It might be easy to tell the FPGA to enable some kind of input termination or connect the FPGA I/O bank VDDIO to say 1.2V when the signal source's logic level is 1.8V and get clipping or loading or other anomalies.  I assume you've got something like LVCMOS or LVTTL or such single ended digital logic signals at some particular voltage level for most or all of these logic signals so just make that match.

* The power ground should not also carry signal returns for any or several signals.  Ideal case one signal, one signal ground reference return.  Then also grounds for power / chassis connections etc.

* You said you saw a low DC signal voltage between the board grounds which is good.  But do verify that the logic related power supply voltages as well as the I/O standards are closely compatible since you really don't want a logic high to be 0.4V or whatever too high relative to the VDDIO of whatever is receiving that signal for instance.

* You could always add some source side series termination resistors like 22 ohms in series with the signals coming out of the signal source PCB (GPU I guess) to help limit the signal rise / fall time a little and damp out any ringing that comes back to the source due to the impedance mismatched "load" and wiring stubs to the receiver and any test instrumentation.

Personally if this is something you're going to continue with for quite a bit more time / debugging I would think about making a custom "interface" PCB which takes in signals from the signal source, includes whatever you can reasonably include like source series termination resistors, low capacitance TVS or similar ESD protection devices, a 0.1" pitch dual row header with opposing ground and signal rows for each signal to connect to the logic analyzer, some kind of header to accommodate a short ribbon cable or similar to go betwen the interface board and the FPGA board, and maybe another little PCB to break out the board to board signal coupling cable end to whatever connector or breakout suits the FPGA board itself if you can't literally make them just plug together with a straight cable or board to board connector pair.

For unidirectional signals with suitable characteristics you could even add some octal buffers or something on the interface board near the connector accepting the signal source signals to provide better SI isolation between the source and FPGA board, enable better driving for the FPGA / DSO / LA etc. inputs, etc.

Answers you your queries below also:

• Where you say try to couple each signal to a point in a twisted pair, do you mean from the mezzanine board to the logic analyser? If so, as mentioned above, I have the high speed adapter for the LA which includes twisted pairs, so I can give that a try and measure at higher frequencies
• FPGA constraints file is set to "IOSTANDARD LVCMOS18" for all pins, so that should be correct
• The grounding could well be an issue as there is just 1 GND plane used for power, but I am also connecting to that as a reference GND on my logic analyser. Suspect this won't be helping things?
• Logic analyser has a threshold of 820mV to determine if it is low or high when the voltage is set to 1.8v, unfortunately this cannot be changed independently and may be partly what is causing me to see these issues. As in the scope capture in my 1st post you can see the VSYNC output of the FPGA goes down to 890mv in that capture, at some times it might be classified as a "low" signal by the LA when it is not. I have found the image below which states the max "low voltage" of 1.8v LVCMOS is 630mV and the min "high voltage" is 1.17v, so 820mV is part of a dead zone where nothing should happen from what I can gather, which may be resulting in false "state changes" on the logic analyser that would not be seen by an LVCMOS18 compatible device
• Sorry, think I forgot to mention earlier, I do have source side termination resistors of value 47 ohms in series with the signals coming from the GPU

[Mario87]

Ok,

This definitely seems to be related to the signal integrity to the logic analyser. I have just tested with the High Speed Adapter and twisted pairs to take a reading from VSYNC input to the FPGA and VSYNC output from the FPGA at 800MHz and they match 100% perfectly!

Also checked another comms line (bit 8 of the red colour data) and again, at 800MHz sampling with twisted pairs, the input & output match perfectly. So looks like in order to measure more signals I need to look at improving signal integrity from the mezzanine card to the LA. At least it doesn't appear to be an issue with the mezzanine card for the time being. 

I even tried the LA at 800MHz without the high speed adapter and twisted pairs, it still improved things A LOT, there were still some small random issues (kind of expected with the wiring when sampling at that frequency), but it appears the sample rate (or lack thereof) is causing me more issues than the wiring itself.

Strange, as I would have thought 200MHz would have been ample??

[T3sl4co1l]

Part of the difficulty of using a logic analyzer is, you don't get waveforms, just 1/0.  Or at best (but also worst, heh), maybe you get a fuzzy transition as the level crosses the input threshold.

If you can adjust the threshold however, you can potentially slice data at different levels and therefore get a feel for over/undershoot or ringing, rise/fall time, and output high/low levels.  Also if you can phase the sample clock versus data clock, effectively allowing an equivalent time sampling as well.

This can in fact be entirely automated, allowing for example, the complete reconstruction of a repetitive waveform, to arbitrary accuracy, given unlimited time -- an example application being something like, a handheld TDR tester that can do basically millions of tests, while still returning a useful result to the user within 100ms, say.  Not that you'd want to [ab]use a logic analyzer this way when you just need to look at some data -- but it's food for thought as far as figuring out noisy/low quality signals, making adjustments to optimize (if not eliminate) error rate, and maybe some postprocessing you can do, say to remove runt pulses, once you've verified they can safely be ignored.


Anyway, good to hear that's solved (or, more-or-less).  What was the thing about TV?  Signals being loaded/corrupted by the riser board? LA? causing the HDMI transmitter to fail in some way?  Or did it just look like it, but you're just measuring a blur on the scope and, kinda, who knows?

Tim

[Mario87]

What was the thing about TV?  Signals being loaded/corrupted by the riser board? LA? causing the HDMI transmitter to fail in some way?  Or did it just look like it, but you're just measuring a blur on the scope and, kinda, who knows?

Tim

Yeah, so the thing with the TV is still, well, a thing. However it's not a big issue for my purposes, and was more of a "why is it doing this" type of query.

The GPU goes to a DAC which converts the signal to AV / scart and connects to a TV that way. I have tapped into the GPU lines where they enter the DAC and what I have noticed is when I connect the cable to my board the clock signal (maybe others too, but not checked) is clamped top and bottom, so instead of going from 0v - 1.8v, it clips down to about 360mv - 1.28v and the TV displays "no signal".

However when signal is in this "clipped state" at the DAC, when I measure the input to the FPGA it shows 0v - 1.62V (which is fine) and the output of the FPGA to the HDMI encoder is 0v - 1.76v which is also fine.

So it might cause me issues if I ever wanted to keep both the analog video and add HDMI output, but if I am happy to completely remove the older AV connector and not make use of it (which I am), then it should work over HDMI only without issue.

Next step is to configure the HDMI encoder registers and if all my checks so far have been correct, then I SHOULD get some kind of output on HDMI once the registers are set.