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: 
Highlighted
Voyager
Voyager
828 Views
Registered: ‎04-04-2014

ISERDES clocking in oversample mode

Jump to solution

Hi,

 

In oversample mode an ISERDES requires 4 clocks:

 

- CLK

- CLKB

- OCLK

- OCLKB

 

-> MRCC -> MMCM ->CLKOUT2 -> BUFG -> CLK

                                 -> CLKOUT3 -> BUFG -> OCLK

 

The design I have inherited uses an MMCM to create CLK and OCLK, passes through a BUFG, and then inverts to create CLKB and OCLKB. This doesn't seem great practise, given the logic delay and associated routing in the inversion. Given we have had some odd behaviour in the past, It thought I'd fix it.

 

I thought I would use the B outputs form the MMCM to produce the inverted clocks instead. Another 2 BUFGs is required, or swap for all BUFIOs. This seems like a better option as all the endpoints are nearby. So, I tried

 

-> MRCC -> MMCM ->CLKOUT2 -> BUFIO -> CLK

                                 -> CLKOUT2B -> BUFIO -> CLKB

                                 -> CLKOUT3 -> BUFIO -> OCLK

                                 -> CLKOUT3B -> BUFIO -> OCLKB

 

But routing is found to be incomplete, the CLKB and OCLKB can't be routed, doesn't say why.

 

Is this because the adjacent inverted output from the MMCM is unavailable once the non-inverted output is used? Or is it because only the non-inverted outputs can drive the BUFIOs?

 

What is the recommended method for what I'm trying to do?

 

Thanks

0 Kudos
1 Solution

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

Re: ISERDES clocking in oversample mode

Jump to solution

This doesn't seem great practise, given the logic delay and associated routing in the inversion.

 

So this doesn't actually use any "logic delay". The input clocks to the ISERDES (and most clocked cells) have optional inversions on the clock pins. These inversions either add negligible delay, or are balanced with the non-inverted path in the ISERDES; there is no significant penalty for using the "local inversion".

 

However, there may be some concern regarding duty cycle. The (BUFG) clock distribution network in the FPGA is not differential, so there may be some duty cycle distortion. So even though the MMCM generates a 50/50 duty cycle, by the time it gets to the ISERDES it may be distorted, causing the CLK and CLKB sample to not be exactly 180 degrees apart. For this reason, some people have the MMCM generate an inverted clock (although they usually use a 180 degree phase shifted clock from a different output - I don't know the characteristics of the CLKOUTxB outputs). 

 

BUT. I have observed some very weird results trying to propagate both the inverted and non-inverted clock through different clock buffers. I had a system where I was pretty sure that the tools were messing things up and the "inverted" clock was not actually inverted (or I suspect it was double inverted - once by the MMCM and once by the local inverter). I had to revert the change to just use the local inverter. I never had enough proof to submit an SR on this, but I just want to mention that I have some suspicions...

 

Another 2 BUFGs is required, or swap for all BUFIOs. This seems like a better option as all the endpoints are nearby.

 

These are not the same solution, and, ultimately, are the cause of your problem.

 

The MMCM -> BUFG connection is a "normal" clocking connection. Any MMCM output can drive any of the 16 BUFGs located in the same half (top/bottom) of the FPGA as the MMCM. So if you had used 4 BUFGs for this (assuming that 4 of the 16 were available) this would have been routable.

 

However the MMCM->BUFIO connection is a "special" connection  - referred to as the "High Performance Clocks". These routes are specially buffered and isolated (and may even be differential - I am not certain), which allows (as the name implies) higher performance clocking. However, there are only 4 such routes and they only from the CLKOUT0, CLKOUT1, CLKOUT2 and CLKOUT3 outputs of the MMCM to the BUFIOs in the same clock region; none of the other MMCM outputs (CLKOUT4 and on, and apparently the CLKOUTxB outputs) have access to these routes. It is also worth noting that these are from the MMCM only - there is no equivalent in the PLL.

 

Avrum

7 Replies
Historian
Historian
811 Views
Registered: ‎01-23-2009

Re: ISERDES clocking in oversample mode

Jump to solution

This doesn't seem great practise, given the logic delay and associated routing in the inversion.

 

So this doesn't actually use any "logic delay". The input clocks to the ISERDES (and most clocked cells) have optional inversions on the clock pins. These inversions either add negligible delay, or are balanced with the non-inverted path in the ISERDES; there is no significant penalty for using the "local inversion".

 

However, there may be some concern regarding duty cycle. The (BUFG) clock distribution network in the FPGA is not differential, so there may be some duty cycle distortion. So even though the MMCM generates a 50/50 duty cycle, by the time it gets to the ISERDES it may be distorted, causing the CLK and CLKB sample to not be exactly 180 degrees apart. For this reason, some people have the MMCM generate an inverted clock (although they usually use a 180 degree phase shifted clock from a different output - I don't know the characteristics of the CLKOUTxB outputs). 

 

BUT. I have observed some very weird results trying to propagate both the inverted and non-inverted clock through different clock buffers. I had a system where I was pretty sure that the tools were messing things up and the "inverted" clock was not actually inverted (or I suspect it was double inverted - once by the MMCM and once by the local inverter). I had to revert the change to just use the local inverter. I never had enough proof to submit an SR on this, but I just want to mention that I have some suspicions...

 

Another 2 BUFGs is required, or swap for all BUFIOs. This seems like a better option as all the endpoints are nearby.

 

These are not the same solution, and, ultimately, are the cause of your problem.

 

The MMCM -> BUFG connection is a "normal" clocking connection. Any MMCM output can drive any of the 16 BUFGs located in the same half (top/bottom) of the FPGA as the MMCM. So if you had used 4 BUFGs for this (assuming that 4 of the 16 were available) this would have been routable.

 

However the MMCM->BUFIO connection is a "special" connection  - referred to as the "High Performance Clocks". These routes are specially buffered and isolated (and may even be differential - I am not certain), which allows (as the name implies) higher performance clocking. However, there are only 4 such routes and they only from the CLKOUT0, CLKOUT1, CLKOUT2 and CLKOUT3 outputs of the MMCM to the BUFIOs in the same clock region; none of the other MMCM outputs (CLKOUT4 and on, and apparently the CLKOUTxB outputs) have access to these routes. It is also worth noting that these are from the MMCM only - there is no equivalent in the PLL.

 

Avrum

Voyager
Voyager
807 Views
Registered: ‎04-04-2014

Re: ISERDES clocking in oversample mode

Jump to solution

Thanks so much for detailed reply. 

 

I have actually stumbled across the documentation where it says the BUFIOs can't be driven from the B outputs of the MMCM. Since my post I have tried generating 4 clocks from outputs 0-3, by adding 180 degrees to the outputs for the inverted clock. But, it sounds like this isn't a great idea and actually it may be best just to revert back to what was there originally.

 

I had thought BUFIOs might have been better anyway, as the fanout is small and very local. I hate wasting BUFGs on this kind of clock network!

 

However I have found another problem with theBUFIO approach. My ISERDESE is followed by an IN_FIFO, clocked by one of the 4 ISERDESE clocks, but the IN_FIFO can't have it's clock input driven by BUFIO, only BUFG, BUFH or BUFR. So, I had the MMCM output drive both the BUFIO and a BUFH. This routed, but failed timing due to different propagation and net delays associated with each path. I didn't do any clock crossing as the signals are essentially synchronous, being driven form the same clock (pre-buffer..). I am now trying BUFR instead of BUFH to see if it has suitable delay properties. If not, I get I could clock cross? Or revert to BUFGs...

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

Re: ISERDES clocking in oversample mode

Jump to solution

I am now trying BUFR instead of BUFH to see if it has suitable delay properties. If not, I get I could clock cross? Or revert to BUFGs...

 

Yes, the High Performance Clocks (HPC) can drive both the BUFIO and the BUFR - this is the recommended way of driving ISERDES/OSERDES using the HPC (this is often used for the OSERDES). A single HPC route can drive both the BUFIO and BUFR inputs; the BUFIO drives the high speed clock (CLK) and the BUFR (using division) drives the low speed clock (CLKDIV). This is a "recommended" clocking structure for the ISERDES/OSERDES and will meet the skew requirements of the ISERDES/OSERDES clocks.

 

The BUFIO/BUFH combination is not skew matched and can/should fail.

 

Avrum

0 Kudos
Voyager
Voyager
795 Views
Registered: ‎04-04-2014

Re: ISERDES clocking in oversample mode

Jump to solution

Ah, I think you misunderstand my setup a little bit. 

 

The ISERDESE is in oversample mode so I'm not using the CLKDIV input, just CLK, CLKB, OCLK, OCLKB. These are all the same frequency but need 0, 90, 180, 270 phase respectively. I have currently assigned BUFIOs to drive these.

 

The BUFH/BUFR requirement comes from needing to clock the IN_FIFO wr port that the output of the ISERDESE is connected to. This needs to be the same as the ISERDESE CLK input but can't be driven by a BUFIO.

 

I have now tried BUFH and BUFR but both fail setup timing, with the delay through the BUFIO seemingly the main culprit as it is much longer than through the BUFR/BUFH, so the clock arrives at the IN_FIFO too early.

 

MMCM (CLKOUT0) -> BUFIO -> ISERDESE (CLK)

                                 -> BUFH/BUFR -> IN_FIFO (WRCLK)

 

The two primitives are part of a dynamic phase alignment group, along with the MMCM phase adjustment and an IDELAY.

 

0 Kudos
Voyager
Voyager
789 Views
Registered: ‎04-04-2014

Re: ISERDES clocking in oversample mode

Jump to solution

Ok, so I added a single register between the ISERDESE and the IN_FIFO, clocked to the IN_FIFO WRCLK domain (the BUFH clock), and timing now seems to be good...

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

Re: ISERDES clocking in oversample mode

Jump to solution

Ah, I think you misunderstand my setup a little bit. 

 

No, I understand - I have used the OVERSAMPLE mode in the past. My point is that the clocking structures around the BUFIO/BUFR are designed in a particular way to allow for the "normal" mode of the ISERDES (when it is deserializing). Since these are the "normal" modes, we know that the clock connections are legal. 

 

We can then use that to extrapolate what are/are not legal clock connections to the ISERDES - even in OVERSAMPLE mode.

 

Avrum

0 Kudos
Voyager
Voyager
741 Views
Registered: ‎04-04-2014

Re: ISERDES clocking in oversample mode

Jump to solution

Ah ok thanks. I would then go for BUFIO/BUFR over BUFIO/BUFH then.

 

Yesterday I was using BUFIO/BUFH and saw some very strange behaviour I couldn't explain. I reverted back to a single BUFG as before and it went away. I have two data channels set up in exactly the same way. Each is completely isolated from the other, with it's own adc data bus (from it's own IO bank), it's own adc clock driving it's own MMCM, generating the necessary clocks that go to it's own IDELAY/IOSERDESE/INFIFO chain, before a state machine does dynamic phase alignment using the MMCM phase adjustment and then IDELAY (for bus skew). I took channel 1 out of reset,it aligned, data looked good. I then took channel 2 out of reset, it too aligned correctly btu all of a sudden channel 1 was completely wrong with some obvious bit misalignment going on.

 

I don't really understand this as the two channels are logically completely isolated. My only thought is that there is a power supply instability issue when the second channel starts up due to increased current draw. They may have their own IO banks but the banks are powered by the same rail. Either way, unless the BUFH is the culprit, I will go back to BUFG :(

 

Thanks again

0 Kudos