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.

ADC schematics

FGPA & SDRAM decoupling caps

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

Top layer

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.

Power plane

bottom layer

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

enter image description here

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:

enter image description here

Point representation:

enter image description here

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.

enter image description here

  • 1
    \$\begingroup\$ Where's the schematic? Where's the layout? You say decoupling caps have no impact and that sperate power planes are used, making me think the layout/schematic is lacking something. How are the power plane routed? What ferriets are used? What FPGA are you using? How are you measruing this noise? What's the update of the ADC? What's wrong with averaging the ADC over a longer time to make sure they're more stable? Is the ADC internal to the FPGA or exteranl IC? If external, how is it wired up? What ground and power planes do you have? What decoupling and isolation do you have on the ADC IC? \$\endgroup\$
    – Puffafish
    Jan 26 at 10:47
  • 1
    \$\begingroup\$ I wonder whether this actually electrical "noise", or if it could it be data corruption from timing problems. You'd need to post details on what timing analysis you've done. If it works without the SDRAM controller in the design, then breaks adding the controller even if the external chips is unused, it's possible that the growth of the design in the FPGA is leading to sub-optimal timing. Have you set up timing constrains on the data interface for the ADC? \$\endgroup\$ Jan 26 at 11:14
  • 1
    \$\begingroup\$ Needs schematic and layout. You can leave the SDRAM controller in the design, but enable/disable writing to SDRAM according to the level on a pin. Then you put a pushbutton on it and you can check with/without SDRAM writes. This way the optimizer won't optimize it out when disabled, and you can test the exact same design in both cases, the only difference being the writes. What's the result? \$\endgroup\$
    – bobflux
    Jan 26 at 11:34
  • 1
    \$\begingroup\$ Is the noise present in the analog input? (probe with scope) \$\endgroup\$
    – bobflux
    Jan 26 at 14:26
  • 1
    \$\begingroup\$ Its a 12 bit adc, probably a 8 bit scope, so I assume you used AC mode and used enough sensitivity on the scope so that if the noise was present on the input, you'd see it loud and clear, right? OK, next: test for noise on all ADC supplies, including and especially its VREF. You can upload a design in the FPGA that writes bursts to SDRAM periodically, output a pulse on a pin when it does, trigger the scope on it, so you can be sure what you're seeing is synchronized with SDRAM. \$\endgroup\$
    – bobflux
    Jan 26 at 16:20

2 Answers 2


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.

enter image description here

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.

  • \$\begingroup\$ The clock to the ADC is made from an external clock source and is independent of the FPGA clock generator. I set the constraints on input and unfortunately, it had no effect. OFFSET = IN 10 VALID 10 AFTER "clock" \$\endgroup\$
    – Farzin
    Feb 13 at 13:47
  • \$\begingroup\$ OK! I see it on the board, the clock oscillator feeds both ADC directly and FPGA through a resistor. I had not seen it before, sorry... So this resistor will add a small delay to the clock received by the FPGA. Maybe if everything aligns correctly, the 3.5ns (typ) Tpd of the ADC means the data arrives at the FPGA at the same time as the clock edge delayed by the resistor... In this case you could have a setup and/or hold time violation. You could try removing the resistor, or using the negative edge of the clock to sample data inside the FPGA instead of the positive edge (would be safer). \$\endgroup\$
    – bobflux
    Feb 13 at 15:04
  • \$\begingroup\$ Basically since the ADC and FPGA receive the same clock from an external source, it's a race between the FPGA trying to register the current bit, and the ADC trying to output a new bit as fast as it can and overwrite the signal while the FPGA is reading it. I thought your clock was generated in the FPGA, in this case there would be no such issue as it would reach the register first, which would sample the current level of the signal, and this would be finished by the time the clock edge reaches the ADC and the new bit reaches the FPGA. So my answer missed the point lol. \$\endgroup\$
    – bobflux
    Feb 13 at 15:08
  • \$\begingroup\$ To see if the clock's phase difference can make the situation better, I applied two generated clocks from a single source which were about 80 degrees out of phase. One to the ADC which is routed also to the FPGA for capturing data and the other directly to the FPGA for toggling SDRAM pins. The noise decreases in the toggling area to a great amount but there is still a negative pulse-like shape present in the ADC readings. Is this still a timing issue? It seems the system can not compensate for at least two or three clocks from when the toggling starts. \$\endgroup\$
    – Farzin
    Feb 28 at 16:32
  • \$\begingroup\$ Good! So there was a timing issue. You could also test with your previous design (same clock for ADC and FPGA) but have the FPGA register the data input on the opposite edge of the clock from the ADC. The ADC outputs data on the rising edge, so you could have the FPGA sample it on the falling edge. \$\endgroup\$
    – bobflux
    Feb 28 at 18:14

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:

enter image description here

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.stack.imgur.com/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!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.