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 oakley
Visitor
2,339 Views
Registered: ‎02-22-2014

Can Duty Cycle of CLKDIV to OSERDES2 Be 25%?

Jump to solution

I would like to run some Artix-7 OSERDES2 cells in DDR 4:1 mode.  This requires a fast clock (512 MHz) on the OSERDES2 cell's CLK port and half that frequency (256 MHz) on the cell's CLKDIV port.  The rising edges of the clocks must be phase aligned.  For example the clocks can originate in the same MMCM and traverse the same type and number of clock buffers.

 

My problem is I don't have enough MMCM outputs to directly generate both CLK and CLKDIV for the OSERDES2.  (There is more stuff elsewhere in the design that is eating up the other MMCM outputs.)

 

I propose using a BUFGCE to make a divide-by-two divider to generate the CLKDIV from a single MMCM output which directly generates the faster CLK.

 

I understand this must be done with balanced clock buffer paths as Avrum explained with a nice diagram here.  This will keep the rising edges phase aligned as required.

 

Also I will need to apply proper constraints to the BUFGCE divider as explained here.  Thanks again, Avrum.

 

My destination OSERDES2 cells are in several clock regions.  A BUFGCE can reach all those regions.  Thus a divider using a BUFGCE should be more straightforward than one using BUFHCE or  BUFR or BUFMRCE.

 

My question is this.  Will the OSERDES2 work okay with the resulting 25% duty cycle on CLKDIV?  The SelectIO Guide UG471 and the Artix-7 Data Sheet DS181 do not seem to specify any limits on CLKDIV duty cycle or pulse width for OSERDES2.

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
3,268 Views
Registered: ‎01-23-2009

Re: Can Duty Cycle of CLKDIV to OSERDES2 Be 25%?

Jump to solution

So, I don't know... And I am not sure it is knowable.

 

My concern is that the clocking relationships between CLK and CLKDIV are not specified, but instead the user guides tell you what constitutes "legal" clocking for the OSERDES and ISERDES. These are listed in UG471. For the OSERDES

 

The only valid clocking  arrangements for the OSERDESE2 are:
• CLK driven by BUFIO, CLKDIV driven by BUFR
• CLK and CLKDIV driven by CLKOUT[0:6] of the same MMCM or PLL
• CLK and CLKDIV driven by two BUFGs.
When using a MMCM to drive the CLK and CLKDIV of the OSERDESE2 the buffer types
suppling the OSERDESE2 can not be mixed. For example, if CLK is driven by a BUFG,
CLKDIV must be driven by a BUFG as well.

 

What you are proposing is not specifically listed here (CLK by BUFG, CLKDIV by BUFGCE) although the last one (CLK and CLKDIV driven by two BUFGs) is pretty close.

 

So, I see no reason why this shouldn't work - I don't see any reason why the OSERDES would care about the duty cycle of CLKDIV. But I am concerned by the fact that Xilinx seems to restrict the clocking so specifically.

 

You say your OSERDES are in multiple banks - are they in three adjacent banks? If so, you can use the High Performance Clock Path from one of the first four clock outputs of the MMCM to the BUFMR and from there to the BUFIO and BUFR in the 3 different regions. This will work with only one clock from the MMCM, but it is difficult from a number of points of view

  - you have to manually manage which logic resources are driven by which BUFR

  - you have to synchronize the BUFRs (there is a procedure to follow to do this)

  - it is difficult to bring data to and from the BUFR clocks (if the rest of your logic is on BUFG)

 

But I wonder how you can be running out of MMCM outputs. Every device has multiple MMCMs and any MMCM can drive the two BUFGs for the OSERDES - are you really saying that you have no more MMCMs in your FPGA with two outputs?

 

Also, while it isn't specifically listed, I am fairly sure you can use the PLLs as well; every clock region in the Artix-7 has one MMCM and one PLL; if you have run out of the MMCMs you should be able to use a PLL instead. While technically this isn't listed as one of the "legal" clocking schemes for the OSERDES, it should work. Or if you really want to stick to the "legal" clocking of the OSERDES, can you free up an MMCM (being used for other purposes) by using a PLL instead? One (fairly sneaky) thing to know is that PLLs actually have lower output jitter than MMCMs, so if you have a clock domain that is hard to get to meet timing, and you don't need any of the features of the MMCM (dynamic or fine phase shift, the inverted clock outputs, the larger number of clock outputs), switching the clock from an MMCM to a PLL can actually improve timing slightly!

 

So you have some options... I think using a PLL or freeing up an MMCM by using a PLL is probably the safest one, but if that is impossible, then you can try the BUFGCE - the problem is, even if the tools say it passes, there is no way to know (for sure) that it is going to work on the board, and even if it does, there is no way to know that it will work on all boards...

 

Avrum

Tags (2)
4 Replies
Highlighted
Historian
Historian
3,269 Views
Registered: ‎01-23-2009

Re: Can Duty Cycle of CLKDIV to OSERDES2 Be 25%?

Jump to solution

So, I don't know... And I am not sure it is knowable.

 

My concern is that the clocking relationships between CLK and CLKDIV are not specified, but instead the user guides tell you what constitutes "legal" clocking for the OSERDES and ISERDES. These are listed in UG471. For the OSERDES

 

The only valid clocking  arrangements for the OSERDESE2 are:
• CLK driven by BUFIO, CLKDIV driven by BUFR
• CLK and CLKDIV driven by CLKOUT[0:6] of the same MMCM or PLL
• CLK and CLKDIV driven by two BUFGs.
When using a MMCM to drive the CLK and CLKDIV of the OSERDESE2 the buffer types
suppling the OSERDESE2 can not be mixed. For example, if CLK is driven by a BUFG,
CLKDIV must be driven by a BUFG as well.

 

What you are proposing is not specifically listed here (CLK by BUFG, CLKDIV by BUFGCE) although the last one (CLK and CLKDIV driven by two BUFGs) is pretty close.

 

So, I see no reason why this shouldn't work - I don't see any reason why the OSERDES would care about the duty cycle of CLKDIV. But I am concerned by the fact that Xilinx seems to restrict the clocking so specifically.

 

You say your OSERDES are in multiple banks - are they in three adjacent banks? If so, you can use the High Performance Clock Path from one of the first four clock outputs of the MMCM to the BUFMR and from there to the BUFIO and BUFR in the 3 different regions. This will work with only one clock from the MMCM, but it is difficult from a number of points of view

  - you have to manually manage which logic resources are driven by which BUFR

  - you have to synchronize the BUFRs (there is a procedure to follow to do this)

  - it is difficult to bring data to and from the BUFR clocks (if the rest of your logic is on BUFG)

 

But I wonder how you can be running out of MMCM outputs. Every device has multiple MMCMs and any MMCM can drive the two BUFGs for the OSERDES - are you really saying that you have no more MMCMs in your FPGA with two outputs?

 

Also, while it isn't specifically listed, I am fairly sure you can use the PLLs as well; every clock region in the Artix-7 has one MMCM and one PLL; if you have run out of the MMCMs you should be able to use a PLL instead. While technically this isn't listed as one of the "legal" clocking schemes for the OSERDES, it should work. Or if you really want to stick to the "legal" clocking of the OSERDES, can you free up an MMCM (being used for other purposes) by using a PLL instead? One (fairly sneaky) thing to know is that PLLs actually have lower output jitter than MMCMs, so if you have a clock domain that is hard to get to meet timing, and you don't need any of the features of the MMCM (dynamic or fine phase shift, the inverted clock outputs, the larger number of clock outputs), switching the clock from an MMCM to a PLL can actually improve timing slightly!

 

So you have some options... I think using a PLL or freeing up an MMCM by using a PLL is probably the safest one, but if that is impossible, then you can try the BUFGCE - the problem is, even if the tools say it passes, there is no way to know (for sure) that it is going to work on the board, and even if it does, there is no way to know that it will work on all boards...

 

Avrum

Tags (2)
Moderator
Moderator
2,219 Views
Registered: ‎06-30-2010

Re: Can Duty Cycle of CLKDIV to OSERDES2 Be 25%?

Jump to solution
@avrunw has given an excellent reply here, what you are proposing is not part of the supported / recommended clocking. The phase relationship will not be the same so this would add to clock uncertainly and potentially causing timing closure issues. Also can you clarify the multiple banks a bit more are they adjacent or spread over the whole device?

I am not sure if the clocking setup proposed will be allowed through the tools there may be a DRC to catch this. If possible I would try and re-arrange you MMCMs to use a supported clock structure.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Visitor oakley
Visitor
2,170 Views
Registered: ‎02-22-2014

Re: Can Duty Cycle of CLKDIV to OSERDES2 Be 25%?

Jump to solution

Thank you avrum and jheslip for your helpful replies.

 

It is handy to know that a PLL has less output jitter than an MMCM.  Although less jitter is almost always helpful,  I need the MMCM's fractional feedback ("M") divider here to reach my needed frequencies.

 

With my proposed clocking I was specifically trying to meet the OSERDES2 clocking requirements quoted by avrum from UG471.  I hoped my proposed clocking arrangement met UG471's requirements because at the heart of things, all BUFG variants are the same type of underlying primitive cell.  Under the hood a BUFGMUX  is really just a BUFGCTRL with some ports wired a particular way.  Likewise a BUFG is really also a BUFGCTRL with some ports wired a different way.  In this view, the paths from the MMCM go through matched buffer paths (two BUFGCTRLs) on the way to the OSERDES2, and the buffer types are not mixed.

 

On the other hand I now wonder if perhaps a BUFGCTRL configured as a BUFG could have different timing than the same BUFGCTRL configured as a BUFGMUX.  It's a subtle point but perhaps that is the crux of it.  Maybe that is where my proposed clocking scheme has trouble.

 

The OSERDES2 outputs are indeed spread out over banks throughout the device.  So multi-regional or regional clocking resources like BUFMRs and High Performance Clocks are ruled out.

 

Why not use multiple MMCMs?  This is going into an instrumentation application where the jitter (or phase noise) statistics are of interest.  The relative jitter among multiple outputs from a single MMCM will be partly correlated because the outputs share the same VCO.  (The relative jitter will also be partly uncorrelated due to effects independent of the VCO.)  In this application relative jitter from one output to another is more important than absolute jitter and therefore the partial correlation is helpful.  If the clocks are instead taken from multiple MMCMs then I expect no partial correlation.  Thus a single MMCM is preferred.  This does not absolutely rule out multiple MMCMs, but I think a single MMCM will be better.

 

Why are my one MMCM's outputs used up?  I would like to generate several phases of the same frequency.  There are not enough outputs on an MMCM to generate the several phases AND each of their half-frequency counterparts all on the same MMCM.  Thus my proposed clocking scheme for creating the half-frequency clocks via BUFGMUXes.

 

Thanks again,

oakley

 

0 Kudos
Moderator
Moderator
2,101 Views
Registered: ‎06-30-2010

Re: Can Duty Cycle of CLKDIV to OSERDES2 Be 25%?

Jump to solution
have you tried to implement your current setup, does it go through without errors?

Do you have HW to try this on, we can't give any details on the impacts if you do not follow the documentation so you would need to test that for yourself.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos