SDRAM logic makes noise on ADC readings with FPGA

Question

I am working on a design in which an FGPA reads the output of a 12-bit 40MHz ADC and then stores half of the data on an external SDRAM and the other half on an on-chip BRAM after some averaging. The problem is that the operation of SDRAM logic makes noise on ADC readings with FPGA. I have also desoldered the SDRAM from my board and yet the noise remains on the data on BRAM. It seems the logic of SDRAM itself is responsible for this noise. When this logic is removed from my code the noise disappears. I have read the ADC output with a simple code using Chipscope and noise amplitude is half of the case when the SDRAM logic is working. The bypass/decoupling caps of FPGA seem to have no or less impact on the issue. Separate power planes for analog and digital parts are also used.

How can I keep the SDRAM from creating noise on the ADC?

UPDATE: Here are the schematics for the ADC(External), and Power decoupling of SDRAM and FPGA (SPARTAN-6 SLX9). The ADC chip is AD9236 from Analog devices.

The top layer and also the power plane layouts are as follows and the ground plane is solid everywhere:

The digital ADC rail under the analog front end and the analog ADC rail under the digital outputs are a mistake writing net names on the image, sorry for that. They are in the right places. I also don't see any abnormal behavior at LDO outputs.

There are separate LDOs for each power rail at the bottom layer which are connected directly through vias to the power plane and also ferrites are placed at the outputs of each LDO.

UPDATE1: The ADC output after toggling data and address pins of SDRAM for a certain amount of time

UPDATE 2: The pins are just toggled between sample 500 and 600 a hundred times. The pattern shows interference(data corruption) rather than noise.

Line representation:

Point representation:

UPDATE 3: After applying two external clocks one to the ADC and the other to the FPGA for toggling pins with about 80 degrees phase difference the p-p noise in the toggling area decreases but there is still a negative pulse-like shape present.

Answer 1

I have no timing constraints on ADC inputs, but does this toggling affect ADC timing?

If you set no timing constraints, the FPGA synthetizer will assume these signals are not related to any clock (asynchronous). It has no way of knowing whether your timing will work or not. For example it may decide to place the logic that processes ADC inputs on the other end of the FPGA because it's convenient for meeting other constraints, it will spend minimum effort on routing, etc.

When the ADC sees a rising clock edge, it will output a data bit after tPD (typ 3.5ns in datasheet, no maximum specified).

So the whole timing is:

Clock inside the FPGA -> FPGA output buffer -> trace propagation delay -> ADC tPD -> trace propagation delay -> FPGA input buffer -> FPGA routing -> FPGA register, clocked by the same clock we started with.

Total delay in this propagation chain should be low enough that the FPGA register timings are met. With 40MHz clock you have 25ns cycle time. Here it's mostly about setup time, you want the data to arrive fast enough where it matters (at the register) to be valid when the registers sample it.

Normally (on the left) you want the signal to reach a stable level for longer than minimum setup time when the register will sample it. When timing is "borderline" and setup time is violated (on the right), for example because the signal arrives too late, the register will sample the signal before it has stabilized. This can seem to "work" but really does not, because any increase in propagation delay (due to temperature, individual chip differences, etc) will make the edge arrive even closer to the sample point... at which point the register may input either the current or the previous value, depending on how it feels about it. Noise sensitivity also increases, which means noise from your pins toggling has a much higher chance to cause errors.

Anyway. I haven't done this in a while, so I don't remember the exact syntax, but here's what you have to tell the synthesizer:

"Data on the ADC_INPUT pins is valid xx ns after the ADC_CLK pin outputs a rising clock edge"

Then the synthesizer will ensure the path from that pin to the ADC data registers is fast enough so the data arrives in time.

What should the value of "xx" be? Unfortunately the ADC datasheet doesn't specify a max tPD, it only gives 3.5ns typical, so I'd say 10-15ns to be safe. Ideally you should use the highest value that is still synthetizable, to leave as much margin as possible to the ADC and board routing.

Other things to check:

You have a clock that will both drive the ADC and the flops inside the FPGA that will register the ADC outputs. This must be labeled as a clock so it uses low-skew dedicated clock routing, and does not route through generic FPGA fabric. This clock is probably going to come from one of your FPGA's clock generators. If that is the case, the software will generate all constraints about it (period, frequency, etc).

Check how the clock output pin is written in your HDL. There's usually a special buffer mode for this, to ensure low skew.

Most FPGAs have registers in the pin input buffers. That removes propagation delay inside the FPGA from pin to register and relaxes setup time. Yours may need a special syntax to activate this feature, or maybe the synthesizer will figure it out.

Your board layout is very clean. So with these changes you should get good performance.

Answer 2

A number of points, in no particular order.

Points also drift arguably into meta topics, as FYI for interested readers who may have related questions. There doesn't seem a better venue to air these points (I would "sticky" them if I could), so I shall include them here for completeness.

---

This question probably isn't answerable as-is -- not conclusively, at least. An illustrative moment for incomplete information. The best answer I can give, then, is comments regarding likely areas of concern. But this is a frustrating state, both for the asker who receives poor quality answers, and the answerer who has incomplete information to merely speculate beyond. (This sort-of lecture, or lecturing tone, will appear here and there to point out such gaps.)

EMC is a holistic topic. Whether the concern is radio interference at a distance, or interactions between components within a single PCB, potentially the whole system (everything on the board, near the board, wired to it, etc.) is in question. The quality of possible answers is in direct relation to the amount of information given.

Mind that, even given complete information, this venue is a poor choice for EMC questions: the volume of information required is potentially vast (assuming you are free to publish such data in the first place: this is also an open venue), demanding comparable volunteer time from the community to answer; in turn making the average answer poor quality, or a complete answer unlikely to be written.

For more private, comprehensive, and confident / likely-to-succeed answers, your preferred business alternative is hiring or contracting an expert in the field, preferably a local one who can work with your entire system as-is, and who is well equipped to analyze the system, and modify the design to suit (or to at least propose modifications). Such a solution will be expensive, but so it is, merely the cost of doing business. (I'm somewhat making an assumption here, that information is hid for business reasons. But, again: incomplete information leads to speculation; I can only guess whether this is the case.)

Vias: why such large groups of vias? Fewer stitching vias are needed, and in more strategic locations, to stitch mostly-contiguous planes together. They have come at the price of sawing up your power planes, which are especially thin around the 1V2 supply connection, under the ADC (both rails), and to the nearby connector (JTAG..?).

Stitching vias should be used judiciously, at modest density as dictated by the maximum frequency of interest or signal harmonics / edge rates, should be prioritized around sources/sinks where the low impedance is necessary, and avoiding routing hazards on all layers where their negative space (the clearance enforced around them) would interfere.

The inner planes, as a hazard, seems to have been missed as oversight; perhaps an automatic stitching placement tool was used, which does not account for polygons. Regardless whether automated or manual, final review is the duty of the designer!

Power: you mention ferrite beads on LDOs, but have not shown either (schematic or layout detail) after comments asking for them, so I am unable to make any statement to their effect; only that this is a completely unknown region and may be in need of consideration.

Routing: most of the signals look reasonable: short, direct paths (length tuning aside), spacially separated, SDRAM off to one side, ADC the other. That leaves these:

The entire analog front end is not shown, and it is a mystery where these signals go, if they carry common mode interference into the front-end, or what. Several of them cross over an apparent void in the ground plane, potentially radiating noise to nearby circuitry, and compromising their signal quality.

Note that, even signals that are set to logic-low (pin connected to internal FPGA GND at the IO pad), emit some noise due to FPGA GND not being exactly PCB GND; and for that matter, PCB GND not being ideal itself, but having some switching noise in the direction of the SDRAM. Low-speed signals should have that bandwidth enforced by filter (RC, ferrite bead or better), to avoid transmitting into nearby circuitry, or radiating into space.

Again, whether this is an issue, is impossible to say without a wider layout view, without assembly details (maybe this is inside a sealed metal enclosure so that radiation is moot), without susceptibility or emissions levels, etc.

My strongest bet is on these signals interfering with the analog front-end, or the AFE itself having design issues that haven't been accounted for (beyond the scope of the question as asked).

Interference: it appears to manifest as a DC offset, or perhaps that's aliasing due to common clock sources. The fact that it aliases to AC in this figure, https://i.sstatic.net/jhS4F.jpg suggests it is aliasing, and you're effectively sampling at different phase shifts around the wave. Whether this is due to VREF stability, AFE interference, RFI rectification, or other unanticipated means, I cannot say. You might ask a separate question regarding the AFE, including the context of, or in relation to, what (digital) signals might be routed near or into it.

Notice you have only given long-term averages as evidence; whether the individual samples are complete gibberish (perhaps a timing issue?), or indeed reading correctly such interference at the ADC input (or REF), isn't known.

Which, timing: it seems bobflux has made some progress in discussing timing constraints; whether this is a matter of reading the port correctly in the first place, or phasing the clocks to just avoid a burst of interference, isn't yet clear. But this is another example of out-of-scope topics or omitted information; it's also leading to (at time of writing) an extended comment discussion, which is generally discouraged. (Again, this is by design: brief, self-contained questions and answers are preferred on this venue; if discussion would suit you problem better, I would suggest the EEVblog forum, among others. Mind, you might not get answers at all, it's just a discussion forum; but perhaps it isn't a problem that needs a conclusive answer.)

---

While I may not have a resolution to the problem, I hope these points at least prove helpful; cheers, and good luck!