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: 
Observer swseo83
Observer
351 Views
Registered: ‎05-23-2017

How to match the phase of the clock.

Jump to solution

Please see the attached figure below.
We want to synchronize the clock (clk_usb) generated inside the FPGA with the external device.

The propagation delay of the clock generated by the "clocking wizard" increases due to the ODDR and the pad of the chip, so that the phase difference between the clock in the internal logic of the FPGA and the clock of the external device becomes more than 5 ns.
The problem is that the external device data output is about 7ns from the rising edge of the clock. Therefore, there is a problem that the data of the external device can not be received correctly in the FPGA operating at 100MHz.


Is there any way to accurately match the phase of the internal clock with that of the external clock?

There may be a way to synchronize the clock generated inside the FPGA by feeding it to the outside of the chip and then feeding it back to the inside of the chip.
However, we want to solve this problem as much as possible internally.

 

 

clockphasematchingQ.jpg
0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
313 Views
Registered: ‎01-23-2009

Re: How to match the phase of the clock.

Jump to solution

There is a way to match the output clock to the input clock, but not to the internal clock. But even if there was, this probably wouldn't help - you would be trading one problem for another.

This kind of interface is deceptively difficult to deal with; it is a source synchronous interface in the output direction, but a "worse than system synchronous interface" in the input direction. Take a look at this post on "worse than system synchronous interfaces".

Like in that post, you need to verify that this interface is even possible. You have a lot of uncertainty in this system - the uncertainty of the output flip-flop, OBUF (which is large), routing delays, and clock to out of the external device (which can also be large). If the sum of these is even close to your period, then this interface is impossible (at least at this speed).

If there is still some margin left after the uncertainties, then you will need to find a clocking scheme that will capture this interface. Almost certainly this will involve some "other" clock - either a negative edge or a phase shifted MMCM generated clock, since, if this return window still exists after all the uncertainties, it is not going to be centered around the next edge of the internal clock (i.e. the round trip time is more than one clock period).

For future reference, it is far easier to deal with devices like this in a pure "system synchronous" mechanism - instead of having the FPGA forward a clock to the external device, clock the FPGA and the external device on the same board clock - i.e. clock the USB device on Clk_100M.

Avrum

0 Kudos
4 Replies
Highlighted
Scholar dpaul24
Scholar
338 Views
Registered: ‎08-07-2014

Re: How to match the phase of the clock.

Jump to solution

@swseo83,

The propagation delay of the clock generated by the "clocking wizard" increases due to the ODDR and the pad of the chip, so that the phase difference between the clock in the internal logic of the FPGA and the clock of the external device becomes more than 5 ns.

This delay will remain due to the primitives.

The problem is that the external device data output is about 7ns from the rising edge of the clock. Therefore, there is a problem that the data of the external device can not be received correctly in the FPGA operating at 100MHz.

Why don't you use an ODELAY element or play around with the set_output_delay command at the XDC for your data going out of the FPGA, such that the data is aligned to the phase-shifted output clock.

 

--------------------------------------------------------------------------------------------------------
FPGA enthusiast!
All PMs will be ignored
--------------------------------------------------------------------------------------------------------
0 Kudos
Observer swseo83
Observer
335 Views
Registered: ‎05-23-2017

Re: How to match the phase of the clock.

Jump to solution
Yes, I tried to use set_output_delay, and it works properly for output signals of FPGA. No problem!!

But, the problem is the input from the slave device.
As I said earlier, the latency of the valid data output is too long 7 ns from rising edge of the clock.
Thus, the registers in FPGA cannot capture the input data at the same cycle as the slave device.

0 Kudos
Voyager
Voyager
323 Views
Registered: ‎08-16-2018

Re: How to match the phase of the clock.

Jump to solution

Why do you need that perfect, text book synchronicity of clocks?

Clocks are used to send and receive data. What you need is your data being in phase with your clock. Your clock gets delayed as it passes through the pads and PCB traces and your data will suffer (or enjoy) a similar delay, so you communicate effectively even if your clocks get delayed.

0 Kudos
Historian
Historian
314 Views
Registered: ‎01-23-2009

Re: How to match the phase of the clock.

Jump to solution

There is a way to match the output clock to the input clock, but not to the internal clock. But even if there was, this probably wouldn't help - you would be trading one problem for another.

This kind of interface is deceptively difficult to deal with; it is a source synchronous interface in the output direction, but a "worse than system synchronous interface" in the input direction. Take a look at this post on "worse than system synchronous interfaces".

Like in that post, you need to verify that this interface is even possible. You have a lot of uncertainty in this system - the uncertainty of the output flip-flop, OBUF (which is large), routing delays, and clock to out of the external device (which can also be large). If the sum of these is even close to your period, then this interface is impossible (at least at this speed).

If there is still some margin left after the uncertainties, then you will need to find a clocking scheme that will capture this interface. Almost certainly this will involve some "other" clock - either a negative edge or a phase shifted MMCM generated clock, since, if this return window still exists after all the uncertainties, it is not going to be centered around the next edge of the internal clock (i.e. the round trip time is more than one clock period).

For future reference, it is far easier to deal with devices like this in a pure "system synchronous" mechanism - instead of having the FPGA forward a clock to the external device, clock the FPGA and the external device on the same board clock - i.e. clock the USB device on Clk_100M.

Avrum

0 Kudos