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: 
Explorer
Explorer
3,352 Views
Registered: ‎02-04-2013

oserdese2 high speed clock - timing error

Jump to solution

I would like to run the OSERDESE2 (SDR, data with => 6) with main clock of 100 MHz and high speed clock of 600 MHz. The implementation report timing failure: Intra-Clock Path for the high speed clock within the MMCM. Please see the attached print screen.

 

Is there a solution for this error or am i too close to the limits of the FPGA - 600Mb/s for the -1 device (according to DS181)?

 

Regards

Klemen

 

 

intraclock_path.png
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
5,885 Views
Registered: ‎01-23-2009

Re: oserdese2 high speed clock - timing error

Jump to solution

Yes, you cannot drive a BUFG at 600MHz in this device.

 

Before we look at the clocking, though, are you sure you can generate a 600MHz SDR output clock from the OBUF - this is pretty fast, and not many I/O standards will be able to manage this frequency. Is there any possibility of using a 300MHz DDR clock to your external device, rather than a 600MHz SDR clock?

 

If your device can't accept the DDR clock, then you have to use a "different" clocking structure, using the "High Performance Clocks". Use MMCM CLKOUT0 (or 1, 2, 3, but not any of the higher ones) to generate the 600MHz clock. Drive this clock directly to the BUFIO and the BUFR (in parallel) - this places the clock on the "High Performance Clock" network - this can run at higher clock rates.

 

The problem with this is that the 100MHz clock (the CLKDIV clock) must be generated by the BUFR using divide by 6. Since it is on a BUFR, all the logic must be restricted to one clock region. This must include the flip-flops driving the low speed side of the OSERDES (the CLKDIV side). If the actual data comes from a global domain (i.e. a 100MHz clock also generated by the MMCM and using a BUFG), then you must perform clock crossing from the BUFG domain to the BUFR domain - this will (at least) need a shallow clock crossing FIFO (the distributed RAMs are well suited to do this).

 

Avrum

View solution in original post

0 Kudos
4 Replies
Highlighted
Historian
Historian
5,886 Views
Registered: ‎01-23-2009

Re: oserdese2 high speed clock - timing error

Jump to solution

Yes, you cannot drive a BUFG at 600MHz in this device.

 

Before we look at the clocking, though, are you sure you can generate a 600MHz SDR output clock from the OBUF - this is pretty fast, and not many I/O standards will be able to manage this frequency. Is there any possibility of using a 300MHz DDR clock to your external device, rather than a 600MHz SDR clock?

 

If your device can't accept the DDR clock, then you have to use a "different" clocking structure, using the "High Performance Clocks". Use MMCM CLKOUT0 (or 1, 2, 3, but not any of the higher ones) to generate the 600MHz clock. Drive this clock directly to the BUFIO and the BUFR (in parallel) - this places the clock on the "High Performance Clock" network - this can run at higher clock rates.

 

The problem with this is that the 100MHz clock (the CLKDIV clock) must be generated by the BUFR using divide by 6. Since it is on a BUFR, all the logic must be restricted to one clock region. This must include the flip-flops driving the low speed side of the OSERDES (the CLKDIV side). If the actual data comes from a global domain (i.e. a 100MHz clock also generated by the MMCM and using a BUFG), then you must perform clock crossing from the BUFG domain to the BUFR domain - this will (at least) need a shallow clock crossing FIFO (the distributed RAMs are well suited to do this).

 

Avrum

View solution in original post

0 Kudos
Explorer
Explorer
3,291 Views
Registered: ‎02-04-2013

Re: oserdese2 high speed clock - timing error

Jump to solution

Thank you for your suggestions, this solved the problem :)

0 Kudos
975 Views
Registered: ‎02-15-2017

Re: oserdese2 high speed clock - timing error

Jump to solution

I realize this thread has been marked as solved, but I'd like to follow up on Avrum's proposal, because it's relevant to something I'm doing.

 

Suppose the output device could accept 300 MHz DDR.  Suppose it's another Xilinx FPGA.

 

Does this mean we can use a single MMCM which produces a 300 MHz and a 100 MHz clock, and distribute both of those with BUFGs directly to the OSERDES on multiple banks?  Is there any special configuration we need on that MMCM to ensure that one of three of the 300 MHz edges lines up with a 100 MHz edge?  When data is flowing between the logic behind multiple DDR interfaces on multiple banks, this architecture avoids having the shallow clock domain crossing FIFOs, which although compact do add latency.

 

In particular, I'll note that the 100 MHz clock will have thousands of loads on it from logic all over the chip, and the 300 MHz clock will have just the OSERDES on it.  With such a large ratio of loads, I'd expect the 100 MHz clock to have much slower edges and see significant relative phase delay as a result.  But this is also generally the case with the standard BUFIO/BUFR idiom, and that seems to work.  Has Xilinx somehow made the BUFG/BUFIO/BUFR propagation delay insensitive to loading?

 

The device and speed grade that I'm looking at has the following limits: BUFG: 464 MHz, LVDS DDR output: 950 Mb/s.  Does the above architecture scale all the way to 464 MHz and 928 Mb/s at the output?  (I'll probably choose something like 450/900 because the MMCM can do it with simpler divides and so less jitter.)

 

I'm not suggesting this BUFG/BUFG strategy would work at the DDR inputs, but just at the DDR outputs.  Inputs would still have an LVDS clock arriving with the data, and use the BUFIO/BUFR idiom to propagate that clock to the IOs and clock region, and that clock region would have the shallow FIFOs to cross into the chip-wide clock domain.

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

Re: oserdese2 high speed clock - timing error

Jump to solution

Does this mean we can use a single MMCM which produces a 300 MHz and a 100 MHz clock, and distribute both of those with BUFGs directly to the OSERDES on multiple banks?

 

Yes. This is a legal clocking mechanism for the OSERDES.

 

Is there any special configuration we need on that MMCM to ensure that one of three of the 300 MHz edges lines up with a 100 MHz edge?

 

No. Unless you specify an intentional phase difference in the MMCM configuration, the edge of the 100MHz clock will line up with one of the 300MHz edges.

 

With such a large ratio of loads, I'd expect the 100 MHz clock to have much slower edges and see significant relative phase delay as a result.

 

The clock network (as well as the general interconnect) in the FPGA are fully buffered, and hence are load independent. As opposed to an ASIC clock, the clock tree is already routed in the FPGA, and is distributed to every CLB in the FPGA, whether it uses it or not. The load (and hence the characteristics of the clock) are independent of whether the CLBs actually use the clock or not.

 

NOTE: This is true for everything before UltraScale - the clock trees in UltraScale are different, and hence need some directives (CLOCK_DELAY_GROUP) to ensure that related clocks remain balanced.

 

Does the above architecture scale all the way to 464 MHz and 928 Mb/s at the output?

 

Yes and no. These frequencies are all legal inside the FPGA. There is nothing, though, that says that you have a data eye that is wide enough for your downstream device to receive. The skew between the clock and data has some variation - if you ask the tools, it is actually quite a lot (like +/-600ps) - this is more than a bit period at 900Mbps... The reality is probably less than this, but it is hard to know exactly how much less.

 

And this is even assuming that the LVDS data eye is open at these frequencies - you need to design your board very carefully and probably do spice (or at least IBIS) simulations to know what your data eye looks like at these frequencies...

 

Avrum