Ripple on outputs when driving a high level

[luisengelmo]

Dear all,

this is my first post. I will do my best to do follow the guidelines.

My main problem is that I have a ripple on *most* of my outputs when I am driving a logic '1'. The ripple does not appear when driving a logig '0'.

Also, the ripple frequency is almos the same as my input clock. The peak-to-peak value is aprox. 400 mV (my IOs are configured as LVTTL).

Please see attachments.

I do not observe the ripple neither in VCC nor in GND. We have checked all VCC pins and many GND pins.

I am using a Spartan XC3S500E-4 and I am using only about 25% of the FPGA:

------------------------------------------------------------------------

I/O Register bits:                  58

Register bits not including I/Os:   2334 (25%)

Total  LUTs: 3038 (32%)

------------------------------------------------------------------------

As I said, my design has a primary clock of 88.1 MHz.

25% of my design uses this clock.

The other 75% uses a secondary clock which is 4.005 MHz (88.1 MHz divided by 22).

I have observed the ripple in outputs that are driven by the primary clock but also in outputs that are driven by the secondary clock.

Also, I have tried to divide internally the input clock (88.1 MHz) by two, so that my primary clock becomes 44.05 MHz and my secondary clock becomes 2.0 MHz. In this case, the ripple disappears.

So my conclusion is that my system clock is coupling to my outputs when its frequency is 88.1 MHz, but the effect disappears when I work at 44.05 MHz.

Any suggestions are welcome.

Thanks and best regards,

Luis.

[austin]

What does the clock look like at the input to the FPGA (scope picture)?

What does the Vcco look like at the FPGA?

[jianlong]

Hi, luisengelmo

I guess the problem is that you didn't give your vcco bank power supply a good filter, you can add some little cap, such as 0.1uf and 0.01 uf, if the ripple will be smaller, then that should be the root cause.

If nothing changed, I don't know, too :)

[luisengelmo]

Hi Austin,

thanks for your feedback.

Yesterday there was some brain storming here and the general opinion points in direction to the clock signal. Unfortunately, I can not provide any scope picture now. The electrical engineer is doing some experiments (trying to filter the clock signal in some way).

I will try to post some screenshot.

Best regards,

Luis.

[ccon67]

Sounds like you have poor byppas in the power plan for this freq range (88 MHz)

For experiment, try to lower the primary freq. (i.e. 1 MHz step ) until the ripple goes away, that is your system 'bypass' cut off freq

Review your FPGA bypass caps, what values? package? and most important how to place them at the FPGA power pins.  Normally the 0.1 uF ceramic in 0402  would do well for this freq. (if placement correct), althougt its resonant freq could be lower than 88 MHz.  

[eteam00]

Sounds like you have poor byppas in the power plan for this freq range (88 MHz)

That is but one of a myriad possibilities for the ripple in the 'scope waveform display.

Reducing a switching frequency in 1MHz increments, or adding decoupling caps, is unlikely to magically clear up the ripple.  Perhaps there might be a 6dB improvement (i.e. half the amplitude), but not a complete elimination.

From the original post:

So my conclusion is that my system clock is coupling to my outputs when its frequency is 88.1 MHz, but the effect disappears when I work at 44.05 MHz.

There are many possibilities for what might be inducing the ripple, but [not enough] power supply decoupling caps would not be my first guess. Having said that,  adding decoupling caps is simple enough to try, and worth the effort to confirm the likelihood that it might (or might not) answer the problem.

-- Bob Elkind

[ccon67]

---

@eteam00 wrote:

That is but one of a myriad possibilities for the ripple in the 'scope waveform display.

.

-- Bob Elkind

---

Had a though on that, but the OP also stated that "he did not see the ripple on GND or VCC", and not on the logic '0' either (asshown in the waveform)

Anyway it's loggically to assume he used same scope, same probe, same settings...  to look at those signals. This means the the ripple does not likely come from the 'measurement' error, or such reasons

[ccon67]

Another though but relate to the byppass caps: it's the power supply not enough 'juice', or poor filter, or poor return path for such freq. range

I notice some people just like to add ferite bids/inductors at the regulator output before supply it to the FPGA power pins.  This is not a bad practice in order to prevent high freq. return to power source and possibly couple into other circuits.

However, if the FPGA has poor bypass design, those ferite bids would make things worse, since the high freq. has no place to go, can't be bypass, neither be able to return to power source.  AS a result it just hopes to anywhere it like' to

So another sugestion, try to bypass those ferite bids with 0 ohms , if they exist

[muzaffer]

does the ripple die off ? it could be reflection because of impedance mismatch but it takes already too long. Do you have a series resistor on this wire? If not try adding one. Also if the line is drawn to have 50 ohm impedance try setting the drive strength of the IO to 8mA and see if that helps.

[eteam00]

does the ripple die off ? it could be reflection because of impedance mismatch

Something to add to the troubleshooting knowledge base:

• The period of the ripple is about 11nS, which corresponds to a one-way flight time of 5.5nS if the ripple is a reflected wave.  5.5nS flight time is roughly 1 meter of circuit board trace length.  If the trace length is much shorter than 1 meter, this would suggest that the ripple is not caused by signal reflections.

• A typical reflection problem would dampen quickly over successive reflection cycles, and this ripple does not seem to dampen.  Keep in mind that the intrinsic output impedance of the source (signal driver) is, in effect, a series damping resistor.

• The original post suggests that the ripple disappears and reappears with clock frequency changes.  Board signal reflections, even a ringing oscillation (if present), would not be affected by clock frequency changes.  Each signal edge (rising or falling) would produce reflections regardless of the frequency of the occurrence of the edge.

Note to the original poster:  While the waveform (with ripple) does not look like a textbook drawing of a digital logic square wave, the ripple amplitude is much too small and too far outside the logic threshold voltage region to affect normal operation as a digital logic signal.  If this ripple is the only problem you have in your board design, then you are having a very good day.

-- Bob Elkind

[luisengelmo]

Hi Austin and all,

first of all, sorry for the delay in answering you all. I will try to answer most of the messages.

I need to correct my original post: my outputs are LVCMOS33, not LVTTL.

Austin, please find the screenshots you were asking for.

CLOCK (1Ghz differential probe)

VCCO (1Ghz differential probe)

Kind regards,

[luisengelmo]

Hi jianlong,

we started using 100 nF at the power supply, one cap per each power pin.

We did this for every different power supply (power for IOs, internal core, …)

Then we added a second cap of 10nF as you suggest. We did this only on the power supplies of one side of the FPGA, where the ripple is mostly present.

The effect was that the ripple peak-to-peak increased to 600 mV (!!).

We then removed the 100nF caps, leaving only the 10nF caps. The results were similar thatn when we were using 100nF + 10nF.

Best regards,

[luisengelmo]

Hi ccon67,

these is our basic decoupling system:

- 100nF for each individual power pin, as near as possible to the FPGA
This makes 6x caps on each SIDE of the FPGA: 3x for VCCO, 2x for VCCAUX and 1x for VCCINT

- 3.3uF on each power supply, one for each SIDE of the FPGA
This makes 3x caps on each SIDE of the FPGA: 1x for VCCO, 1x for VCCAUX and 1x for VCCINT

Regarding the input clock, we made the experiment using a high frequency waveform generator.
We saw the following results (the numbers are aprox):
- 90 MHz : the ripple had a maximum 600mV peak-to-peak
- 77 MHz : the ripple had a maximum 600mV peak-to-peak
- 64 MHz : the ripple had a minimum
- 44 MHz : the ripple had a maximum aprox. 600mV peak-to-peak

Below 44Mhz, the ripple would reduce until it dissapeared.


Best regards,
Luis.

[luisengelmo]

Hi ccon67,

as you mention, we used the same scope, same probe and same settings.


Regards,
Luis,

[luisengelmo]

Hi ccon67,

unfortunately, we can not use ferite bids due to production constraints.


Best regards,
Luis.

[luisengelmo]

Hi muzafter,

no, the ripple doesn't die off.
In fact, we cut the line very close to the FGPA and put a load resistor of 1.2 Kohm and the ripple did not change.


Regards,
Luis.

[luisengelmo]

Hi Bob,

our typical trace length is between 2cm and 5 cm long. All the outputs are connected to a driver input in order to drive the signal to another board.
Regarding the ripple amplitude, our concern is that the receiver shall not receive anything above 3.6 V.


Regards,
Luis.

[eteam00]

Regarding the input clock, we made the experiment using a high frequency waveform generator.
We saw the following results (the numbers are aprox):
- 90 MHz : the ripple had a maximum 600mV peak-to-peak
- 77 MHz : the ripple had a maximum 600mV peak-to-peak
- 64 MHz : the ripple had a minimum
- 44 MHz : the ripple had a maximum aprox. 600mV peak-to-peak

Below 44Mhz, the ripple would reduce until it dissapeared.

This seems to contradict your first post, in which you said that the ripple disappeared with a 44.05MHz clock.  Is there a contradiction, or did I misunderstand you?

If the ripple gradually diminshes with lower clock frequency, then perhaps this is power supply ripple.  You can verify or eliminate this possibility by soldering in an additional 330uF or so of capacitance on the 3.3V rail.  Measure the ripple before and after adding the capacitor, and see if that makes a difference.

When you vary the clock frequency, does the ripple frequency track the clock frequency?

-- Bob Elkind

[eteam00]

Regarding the ripple amplitude, our concern is that the receiver shall not receive anything above 3.6 V.

If the ripple persists, reducing VCCO from 3.3V to 3.0V might be a reasonable countermeasure.  This is used on some circuit boards where 3.3V PCI busses exhibit overshoot which causes either noise spikes or input circuit breakdown.  A 3.0V supply for PCI bus drivers is used to bring the bus overshoot within a safe voltage region.

-- Bob Elkind

[ccon67]

---

@luisengelmo wrote:
Hi ccon67,

these is our basic decoupling system:

- 100nF for each individual power pin, as near as possible to the FPGA
This makes 6x caps on each SIDE of the FPGA: 3x for VCCO, 2x for VCCAUX and 1x for VCCINT

- 3.3uF on each power supply, one for each SIDE of the FPGA
This makes 3x caps on each SIDE of the FPGA: 1x for VCCO, 1x for VCCAUX and 1x for VCCINT

Regarding the input clock, we made the experiment using a high frequency waveform generator.
We saw the following results (the numbers are aprox):
- 90 MHz : the ripple had a maximum 600mV peak-to-peak
- 77 MHz : the ripple had a maximum 600mV peak-to-peak
- 64 MHz : the ripple had a minimum
- 44 MHz : the ripple had a maximum aprox. 600mV peak-to-peak

Below 44Mhz, the ripple would reduce until it dissapeared.


Best regards,
Luis.

---

Interesting, looks like you have a notch at 64 MHz

Anyway, if the ripple just occurs in some 'random' pins, then investigate in this perpective may give a clue

I guess those pins with the noise might not be random as you though.  Try to list out all of them and see if they match a pattern, such as same FPGA bank, or somthingelse ?

[luisengelmo]

Hi Bob,

reducing VCCO to 3.0V would be a nice workaround for this prototype but our final device accepts 3.0V as the absolut minimum power supply for the drivers.

[luisengelmo]

Hi ccon67,

I agree with you, this is a good idead. But unfortunately we must share the board with other colleagues and that is why it takes me a couple of days to answer.

We will try to do that next week or so.

[luisengelmo]

(I thought I had sent this answer yesterday but something went wrong)

(it is regarding the possible contradiction you found between my OP and  my message about the rippled found at 44 MHz in another message)

Hi Bob,

thanks for your quick reply.

In my opinion, there is no such contradiction, but I think after so many posts I need to clarify this

In my original post, I mentioned that at some point we did an experiment using an input clock of 88.1 MHz and dividing it internally by two, and then using the 44.0 MHz clock internally. (Normally, the input clock is used as it is as primary clock.)

In this case, the ripple almost dissapeared (it was reduced significantly).

But then we returned to our original design, the one without the internal clock divider, and we used the waveform generator.

Then we started playing with the input clock frequency as described above, and the ripple did not disappear at 44 MHz at all. Only when we used lower frequencies did the ripple disappear.

And yes, the ripple frequency did track the input clock frequency.

Regarding the power supply ripple, we have a DC filter between the 3.3V regulator and the power supply pins which is composed by a serial coil and some parallel capacitors. We don't believe it really is power supply ripple.

Regards,

Luis.

[eteam00]

reducing VCCO to 3.0V would be a nice workaround for this prototype but our final device accepts 3.0V as the absolut minimum power supply for the drivers.

You should check with the manufacturer of the devices which interface to the FPGA.

Is 3.6V an absolute input voltage limit, or is the input voltage limit related to the device's supply voltage (e.g. VCC + 0.3V)?  If so, then providing a VCCO for the FPGA which is lower than the external device VCC (or a VCC for the external device which is higher than the FPGA VCCO) might work.

Would a series resistor increase the allowed input voltage, serving to limit any clamp or breakdown currents in the device?  This is a popular method for extending the range of input voltage tolerance for Xilinx FPGAs.

Is the input voltage limit based on steady state input or transient limit?  Often the input voltage limit for transient pulses is a bit higher than the steady state input voltage limit.

-- Bob Elkind

[eteam00]

Regarding the power supply ripple, we have a DC filter between the 3.3V regulator and the power supply pins which is composed by a serial coil and some parallel capacitors. We don't believe it really is power supply ripple.

Everything you have reported suggests that power supply may very well be the path for this signal ripple.  If coupled noise is causing the ripple, the ripple would appear in the 'scope trace both at the LOW and HIGH logic levels.  But there is no such ripple at the LOW logic level.

What sort of noise path would affect only the HIGH logic level but not the LOW logic level?

Power supply ripple would be such a path.  There are various clues if supply ripple is part of the problem.

Try increasing overall current load (DC) on the supply.  Does the noise increase?  If the power supply is a switching supply, then the ripple frequency would be related to the supply switching frequency, as the increased load current would increase power supply droop.  The countermeasure would be increasing regulator current capacity, or increasing bulk capacitance on the supply rail.  If the noise does not change with increased supply load current, then the source power supply circuit is likely NOT the cause of the noise.

If the power supply isolation filter is contributing to the noise, you would expect the ripple frequency to track the system clock frequency, and you would expect the ripple amplitude to increase or decrease with increases or decreases in the system clock frequency.  This is the nature of low-pass filters in the power supply distribution path.

If the power supply decoupling capacitors on each supply pin are poor or inadequate, you would expect the ripple frequency to track the system clock frequency and you might expect the ripple amplitude would likely NOT increase or decrease as the system clock frequency is varied.

When you check the power supply ripple, do you measure on both sides of the coil (inductive) filter?  Are there differences on either side of the coil?  What are the values of the coil and the large (bulk) capacitance on the FPGA side of the coil?

Finally, it may well be that the source impedance of the FPGA output signals is lower in the LOW logic state than in the HIGH logic state.  This would make coupled noise amplitude much more noticeable in the HIGH logic state.  What happens if you change the FPGA output pin drive level?  What happens if you add a 50-ohm load resistor between the output signal and GND?

-- Bob Elkind

[austin]

All,

This is beginning to look like a very poor power distribution network (PDN) problem.  Depending on the clockk frequency, the PDN resonates, or not, creating large variations.

Unfortunately, if you did not follow the PDN recommendations in the user's guide, then it is unlikely that anything other than a re-layout will fix it.  Once the board is fabricated, the values of series inductances in the PDN are fixed, and no amount of piggy-backing capacitors (or hacking) will result in an acceptable PDN.

If I go back to your list of capacitors, there are far too few, and the placement may be incorrect.

http://www.xilinx.com/products/design_resources/signal_integrity/resource/si_power.htm

[trenz-al]

make a indirect VCCIO measurement: program one IO pin output driving constant 1 with maximum drive strength, and measure the ripple.

If you see the ripple there, then the ripple is present on the VCCIO as the FPGA sees it internally on the DIE.