11-15-2019 12:40 AM
Due to EMR problems I've a request on my desk to define the exact required rise and fall times of a clock input signal for a Spartan-6 device. We use a 50 MHz external clock oscillator providing a CMOS compatible signale to a normal input pin configured to use LVCMOS33 standard. Inside the FPGA the CLK input is feed into a IBUFG and from its output to a DCM_SP primitive and some other logic. As a rule of tumb I would expect a rise/fall time of about 10% of the period time to be good enough, but know I'm requested to define rise/fall times greater than this rule of tumb to solve the EMR problems...
The only relevant points I could get from device datasheets are the LVCMOS33 input levels V_IL_max = 0.8V, V_IH_min = 2.0V and for the DCM_SP a cycle-to-cycle jitter at its CLKIN input of +- 300 ps (FCLKFX < 150MHZ), period jitter at CLKIN +- 1n and a required duty cycle of CLKIN in the range of 40% to 60%.
On a first thought I've tried use the maximum cycle-to-cycle jitter as a maximum time the clock input signal must cross the voltage range between V_IL_max and V_IH_min as within this range there is no clear defined input state and therefore we can get a great cycle-to-cycle jitter if the input driver switching point differs between two clock cycles. But if I interpolate the resulting clock input slew rate of 1.2V/300ps to a 10-90% rise time signal definition I would end up with tr = 660ps which sounds very tight to me.
Any other suggestions how to get a more "valid" and "practicable" rise/fall time definition for the clock input signal?
11-15-2019 05:55 AM
Welcome to the Xilinx Forum!
Since you are using LVCMOS33, a starting-point requirement for rise/fall time of the digital waveform is the requirement for LVCMOS, which TI document SDYA009C says is about 6ns (ie. 5ns/V over the 0.8V to 2.0V transition region).
However, since you are specifically using LVCMOS33 for a clock input to the FPGA, then a better requirement for rise/fall time can be obtained from clock buffer ICs. For example, the TI CDCLVC1102 has an LVCMOS33 output rise/fall time of between 0.3-0.8ns.
Rise/fall time of the clock waveform is only one of the factors that contributes to clock jitter. It is best to place the burden-of-proof on the clock manufacturer and require them to provide measured jitter for the clock that you buy.
Finally, I understand that you are routing the clock from the FPGA-pin through an IBUFG and into a DCM. So, it is helpful to know how jitter on the clock input to the DCM affects jitter on the clock output of the DCM. I don’t know this relationship for the Spartan-6 DCM. However, for 7-Series FPGAs, one can use the Clocking Wizard (ref PG065) to observe the relationship for an MMCM (similar to DCM). For example, with 50MHz input and output of the MMCM, a 10ps Pk-Pk jitter on the input gives 174.9ps Pk-Pk jitter on the output. When input jitter is increased to 100ps Pk-Pk then output jitter increases to only 179.3ps Pk-Pk.
11-15-2019 06:17 AM
It sounds to me like one of these things bosses ask to cover their backs even if they are absolute nonsense.
Rise/fall time is not the only parameter defining a clock. If you worry about EMI (EMR=EMI?), better to follow proper layout rules (short, shielded traces, ideally a differential clock).
What is the meaning of setting a max rise time if you already have an oscillator? And how is writing such a limit going to prevent EMI?
11-15-2019 07:58 AM
Use the IBIS models in a SI CAD Tool,
Like HyperLynx, or the Cadence Tool. You will be able to model and see the rise time. Then lower the drive levels (set the strength of the FPGA device outouts to lower drive levels, set slow slew) and consider adding series terminastion resistors on signals driving the FPGA to removeany oved shoot or under shoot.
11-15-2019 08:36 AM
email@example.com Thank you for the hints on LVCMOS definitions and you are right that this is only one of the jitter sources. But the DCM_SP input jitter is at the moment the only parameter I can see to be used to get a "hard" clock input limit, the DCM's output jitter is a different story and I've to take it also into account (for DCM's outputs I will be able to get a maximum allowed jitter from my design...). The 300ps input jitter is the limit when the DCM_SP will be unable to lock and therefore this will be hard limit which can't be influenced by my design.
11-15-2019 08:53 AM
@archangel-lightworksWe already have a short trace running from the oscillator to the FPGA, direct below this trace is a GND plane. I've not the exact length of this connection to my hands at the moment, but if I remember right it should be no more than 15mm (0.590in), which would be well below the cirtical net length - and again we aren't seen any reflections on this signal, there is only some "mystery" in the EMI-Plots at the harmonics of this signal.
The reason why I was asked to give a limit for the rise/fall times is that our EMI (the problem is on radiation not immision) guys get much lower harmonic levels if they put a low-pass filter on this signal, right after the oscillator. I've even had already suggestions from this side on my desk where the cut-off frequency was so low that the clock signal really looks like more to be a triangle and not more a rectangle signal. Now they (and the bosses) asked me how much they are able to lower the clock signals rise/fall times to be still in a safe state.
I've already mentioned to the EMI guys that on my opinion the problem can be more related to the (not really optimal) FPGAs power system, but up to now they want to change something (add the low-pass filter) on the clock signal too - and here I am as the FPGA designer comes into the story...
11-15-2019 09:05 AM
@lowearthorbitUsing the designs IBIS-Model would be the right way if we would observe some problems with the signal integrity, especially if we had problems with one of the FPGA outputs. But in our specific case the problem comes from the FPGA's clock input and this signal looks from a signal integrity viewpoint quite (using a 1 GHz measurement equipment for a 50MHz signal with 2ns rise/fall time should be enough to see if there were some problems) well.
As the exact oscillators output and the net length were not known to me at design time, I had already requested to add a series termination resistor right after the oscillator. At the moment this resistor is used to build up a low-pass filter by adding a small capacitor after it and if the EMI guys use a capacitor big enough the harmonic's levels will be reduced a lot, but the clock signal is going to leave the rectangle shape more and more and that's the reason why I was asked to define a limit for clock signal's rise/fall times.
So still have anybody some suggestions how to get a more "valid" and "practicable" rise/fall time definition for the FPGA's clock input signal?
11-15-2019 09:42 AM - edited 11-15-2019 09:43 AM
They are just asking what is the clock rise / fall time,
Whats driving the clock into the FPGA is the way forward
for instance , selected at random , this device
has a rise and fall time of less than 3ns,
If manager is asking for exact, then ask then are they willing to pay to get each oscillator specially tested, as no manufacturer in the world is going to be able to tell you the exact number.
If the requirment is so purchasing know what to purchase, just give them the answer less than 3ns,
BTW: that rule of thumb about period and rise / fall time, not a good one IMHO.
11-15-2019 10:07 AM
@drjohnsmithThey are asking for the maximum acceptable rise / fall time from the FPGA's point of view. The problem is not to buy a device with a higher maximum rise / fall time specification as if you have pointed out it could be faster in reality without a selection process.
The EMI guys have the idea to use a passive low-pass filter right after the oscillator's output to increase the rise / fall time and therefore to get rid of the problematic harmonics. And now they asked me where is the limit the can go to.
But you are right, even with a low-pass filter eleminating the problematic harmonics at the moment we can get them back if the oscialltor's manufacturer delivers us a new charge with much lower rise/fall times as the usually only guarantee a maximum value. On the other hand if the low-pass filter's cut-off frequency is low enough the probability will be not too high.
So managers will still request me to give a limit to the EMI guys...
11-15-2019 12:27 PM
11-15-2019 12:33 PM
DCM_SP input jitter is at the moment the only parameter I can see to be used to get a "hard" clock input limit..
Another hard limit is the 6ns rise/fall time requirement for standard LVCMOS33. I expect the FPGA input buffers (when configured as LVCMOS33) adhere to this standard. That is, if you increase rise/fall times above this requirement then the LVCMOS33 gate is not guaranteed to work properly. Noise together with too-slow rise/fall time will cause FPGA input buffers to oscillate as observed in <this> post.
11-16-2019 01:36 AM
11-16-2019 03:38 AM
It's 6:30 AM on a weekend and I don't feel like going throught the math, but is there a chance that the jitter is what is reducing the EMI peaks? It will spread the energy a little. Doesn't the Spartan 6 DCM have a spread spectrum option? It might be worth a try. Some energy will radiate from the trace, but a single short trace shouldn't contribute that much. Could always put a strip of copper tape over it to see if it makes a difference. Is the power supply somehow synchronized to a signal divided down from the 50MHz clock? Slightly dithering the synchronization can spread the energy a bit. Most switching power supplies can tolerate at least a little dither but don't expect the data sheet to mention this.
11-16-2019 08:23 AM
11-16-2019 09:16 AM
@bruce_karaffaWe had also made some measurements with an unprogrammed FPGA and the clock input harmonics were still present.
The used Spartan-6 LX4 does offer a spread spectrum option inside the internal clock manager. I've not used it at the moment as my design implements a single line serial data interface between different devices where the reciever must run a CDR circuit to recover clock and data from the incoming bitstream. Using a spread spectrum clocking may made the receiver design more complex or even impossible, but that depends on some details and is another story as the clock input EMI problem is independent from my digital design so the spread spectrum option of the DCM doesn't help to solve this problem.
I belive the problem is more related to the not really well designed power supply but that is hard to prove without making a new PCB revision...
11-16-2019 09:54 AM
@drjohnsmithI have no sensitve track running right next to the problematic clock signal in my mind, but its weekend and I can't access the pcb data at home. I'll check it when I'm back in office at monday.
There are no relevant analog bits (sorry I'm not a native speaker - does this mean analog circuit?) on the boards (we are talking about four different pcbs). All four boards consists of a SOM, some digital stuff and small local power circuits (e.g. for FPGA's VCCINT) only.
Our EMI guys have already tried to seek for the problem source using near field probes and have isolated it to the clock oscillator / FPGA place. The strange point is that the harmonics go away if the series termination resistor right after the clock oscillator will be removed from the board - but they are still present if the FPGA stays unprogrammed. As I've already mentiond in a former post I have the not really well made power system in suspicion but I'm not able to prove it as I'm only the FPGA designer and not one of the EMI guys. The pcb's were design by an external engineering partner who made int the past many real high speed stuff (SOMs) and our managers decide to not made a layout review due to lack of time. As from a functional and signal integrity view point all things looks quite well we didn't made a closer look on the pcb design up to now and what I've seen made me not very happy...
I agreed with you that putting a RC circuit on the clock line is not a good way and has much risk to bring problems back as the product will enter the field - but what to do as little FPGA designer if managers constantly ask you to support this way by giving a rise / fall time limit to the EMI guys?
BTW: You have written that the rule of tumb about period and rise / fall times I've mentioned isn't a good one. Have you a better suggestion to use - I'm always willing to improve my knowledge?
11-16-2019 01:09 PM
11-18-2019 12:48 AM
"get much lower harmonic levels if they put a low-pass filter on this signal, right after the oscillator"
Emm, yes, sure. A square clock has a fundamental frequency and a series of harmonics. If you low-pass a clock just over its fundamental frequency, you kill the harmonics and you end up with a sinusoidal wave. But digital systems need sharp edges not sinusoidals. that cannot be your problem and your solution.
EMI is very empirical, it's almost impossible to give a generic (working) solution from a series of symptoms. And usually the symptom is just "it doesn't work".
I'd say, your problem is EMI and you shouldn't look into the clock edges. If you use an oscillator from a known manufacturer, there are probably millions of them clocking FPGAs and other chips without problem, does that seem reasonable?
From my experience, I found that the supply to those oscillators is important. They draw a significant current, is the PSU capable of that? Decoupling of the supply is also important, a large thin track will be both resistive and inductive. Some people fix everything with "more bigger caps". No, it's not that simple. I found in most cases a ferrite in the supply net helps stopping noise going back to the supply and everywhere.
11-19-2019 01:08 AM
Thanks to all, who replied so far.
@archangel-lightworksI totaly agree with you. The clock oscillator's supply is already decoupled by a PI-filter (decoupling cap - ferrite - decoupling cap) and should be not the source of our problem as no relevant harmonics were present anymore if we remove the series termination resistor form the oscillator output. Maybe the missing load to the oscillator's output could also play a role but this can be checked by the EMI guys.
At the moment I've asked the EMI guys to dig more into the PCBs if cross-coupling from the clock input signal to some higher impedant signal could be the source of our problems. I'll update this thread if there exists an outcome...
11-19-2019 07:11 AM
11-19-2019 11:51 PM
@archangel-lightworksThe FPGA runs quite well, all signals looks also quite well from a signal integrity point of view. "Only" on EMI we have to high levels on clock harmonics.
@drjohnsmithThe used ferrite is from Taiyo Yuden's BK-series. It has a DC resistence well below 1 Ohm and 1k@100MHz. My colleague has already started some measurements in this area, but from schematics this filtering of the oscillator's power supply looks like not very poor. Let's see what the measurments will tell us...