UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor pitzlf
Visitor
1,270 Views
Registered: ‎10-22-2014

How to define required clock input rise/fall times

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?

0 Kudos
22 Replies
1,236 Views
Registered: ‎01-22-2015

Re: How to define required clock input rise/fall times

@pitzlf 

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.
CLK_WIZ_jitter.jpg

Cheers,
Mark

 

1,231 Views
Registered: ‎07-23-2019

Re: How to define required clock input rise/fall times

 

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?

1,212 Views
Registered: ‎09-17-2018

Re: How to define required clock input rise/fall times

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.

l.e.o.

 

0 Kudos
Visitor pitzlf
Visitor
1,201 Views
Registered: ‎10-22-2014

Re: How to define required clock input rise/fall times

markg@prosensing.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.

0 Kudos
Visitor pitzlf
Visitor
1,195 Views
Registered: ‎10-22-2014

Re: How to define required clock input rise/fall times

@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...

Visitor pitzlf
Visitor
1,188 Views
Registered: ‎10-22-2014

Re: How to define required clock input rise/fall times

@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?

0 Kudos
Teacher drjohnsmith
Teacher
1,165 Views
Registered: ‎07-09-2009

Re: How to define required clock input rise/fall times

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
https://www.mouser.co.uk/datasheet/2/268/20005529A-1149183.pdf

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.

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Visitor pitzlf
Visitor
1,158 Views
Registered: ‎10-22-2014

Re: How to define required clock input rise/fall times

@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...

0 Kudos
Teacher drjohnsmith
Teacher
1,114 Views
Registered: ‎07-09-2009

Re: How to define required clock input rise/fall times

The answer is in good design
all single ended signals are going to have aground return, and will radiate,
use differential signals, and smaller ones like a LVDS or LVPECL oscillator, and run a good differential signal on an inner layer , Radiation will be very controlled,

You could switch to a clipped or pure sine oscillator ,
again the differential version is all but zero emission,

My experience of this sort of problem, the problem is not the clock output,
its the power supply. ..
Some one forgot to put good de coupling and a BLM filter on the clock power supply , and its radiating all over the system, This is especially true of clock sources such as LVCMOS as these take great big lumps of power, where as differentail clocks such as LVDS take almost constant current off the PSU.

I cant seem to see which chip FPGA you have,
but looking through the Artix data sheet I cant see why you could not put a sine wave into the clock of the FPGA, only the GTx clock seems to have a required rise time, and thats a typical,

How ever, I suspect the jitter is going to be horrendous, but it will cure yur EMC problems,



<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
1,111 Views
Registered: ‎01-22-2015

Re: How to define required clock input rise/fall times

@pitzlf 

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.

 

0 Kudos
Teacher drjohnsmith
Teacher
968 Views
Registered: ‎07-09-2009

Re: How to define required clock input rise/fall times

@markg , I had forgotten about that post. IM not convinced from the post that the slow edge was the problem, more the noise and other inputs with lines connected that had stray signal on them,

If you have to have a sine wave clock cause your boss says so, fit a Schmidt trigger on the board next to the clock pin of the fpga your using,
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
951 Views
Registered: ‎06-21-2017

Re: How to define required clock input rise/fall times

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.

0 Kudos
929 Views
Registered: ‎06-21-2017

Re: How to define required clock input rise/fall times

Is the EMI reduced with an unprogrammed FPGA?  If so, the problem may not be directly related to the trace.

0 Kudos
Teacher drjohnsmith
Teacher
900 Views
Registered: ‎07-09-2009

Re: How to define required clock input rise/fall times

The output of the oscillator over 15 mm of track over a ground plane is not going to be your radiated EMI source unless that track is running right next to a sensitive track that is re radiating the signal.
Even then 15mm of track should couple not a lot into a longer trace at this sort of frequency, I have had a 100MHz clock which some one decided to switch form LVDS to LVCMOS to save money radiate, but that wa smore like 50mm in length , right next to a long tri stated line, The answer there was to change the line that was tri state to being driven always, and it stopped radiating,,,

Do you have analog bits on this board you ?

How much noise at the clock frequency is on the power rails ?

Do you have a near field EMC probe, if not you can make one
It does not have to be calibrated, its a relative measurement of where the problem is,
https://jestineyong.com/make-your-own-emi-measurement-probes/

Do not take some one elses word for it, get in there and probe with an open mind,

EMI problems are very hard to retro fit / find,
For instance, your adding a resistor / capacitor on the output of the oscillator has totally changed the grounding of the circuit. I have ad cheap oscillators were the whole metal can radiates like a good one, Earthing them made a improvement, spending an extra 15 Cent for a recognised manufacturer fixed the problem, only cost a few man weeks to achieve, But purchasing took some great convincing, the two looked the same they said !!

Going ahead just putting a RC circuit cause it worked in a random sample of one, is leaving you to future problems,

As an engineer, get in there and de bug it,




<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Visitor pitzlf
Visitor
893 Views
Registered: ‎10-22-2014

Re: How to define required clock input rise/fall times

@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...

0 Kudos
Visitor pitzlf
Visitor
881 Views
Registered: ‎10-22-2014

Re: How to define required clock input rise/fall times

@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?

0 Kudos
Teacher drjohnsmith
Teacher
847 Views
Registered: ‎07-09-2009

Re: How to define required clock input rise/fall times

There is no rule of thumb re rise/falll time and period,

You could be thinking of the rule of thumb on rise/fall time and track length before termination is needed.
An electrical short trace is one which is not longer than 1/3 he rise time,

FR4 PCB is about 1ns per 150mm,

so a 1ns rise/fall time signal does not need termination if the track is less than 25mm, Your signal at 15mm and 3ns , does not need terminating...


Why have you not been involved in the EMI probing ?
Personally, Id suggest you look quickly at changing managers... You do not deserve them,,,,

There is no official number as far as I can make out as to the required rise / fall times of the clock inputs,

I'd suggest you just stick with 3ns, and put it up to your manager,





<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
639 Views
Registered: ‎07-23-2019

Re: How to define required clock input rise/fall times

 

"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.

Visitor pitzlf
Visitor
568 Views
Registered: ‎10-22-2014

Re: How to define required clock input rise/fall times

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...

0 Kudos
552 Views
Registered: ‎07-23-2019

Re: How to define required clock input rise/fall times

 

By the way, what is the problem? does the FPGA misfunction?

0 Kudos
Teacher drjohnsmith
Teacher
530 Views
Registered: ‎07-09-2009

Re: How to define required clock input rise/fall times

Its unlikely the problem, but just check the inductor, is it a BLM type or a bit of bent wire one ? BLM's are all but shielded, so radiate little, some others do radiate,
Also check the impedance of the fer-rite, at DC and at the frequency of the oscillator, Some have quiet high DC resistance, and some might not clober your clock frequency at all,
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Visitor pitzlf
Visitor
506 Views
Registered: ‎10-22-2014

Re: How to define required clock input rise/fall times

@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...

0 Kudos