7 Series FPGAs

[patocarr]

Hi folks,

  I'm using MIG to generate a 3-controller DDR3 core, using single HP banks for each, 16-bit wide @800MHz rate. In this configuration, there's no room in the bank to add the sys_clk input, so it needs to come from a nearby bank. I'm not using *_cs or mask pins to be able to fit the controllers into one bank each.

  Based on the clocking user guide ug472, the BUFH buffers allow an input clock to cross from a horizontally adjacent bank to the PLL in the controller. I changed the logic to instantiate a BUFH in clk_ibuf after the IBUFGDS, and LOCking the sys_clk to the adjacent clock regions, hence for controllers in banks 32, 33, 34, they'd use sys_clk in banks 12, 13, 14 respectively.

  While all of this worked fine (ie. got a bitfile), I'm concerned that MIG didn't suggest putting these clocks in other banks other than same-side adjacent banks. Looking at it in fpga_editor, routing seems correct with the clocks using appropriate BUFHs and paths.

  Another question. Since these controllers will be using the same sys_clk input rate, it would be better to save some pins and use one sys_clk input. So it would go: sys_clk differential pin, thru IBUFGDS, to a BUFG, to 3 PLLs, one in each of the 3 controllers. Again, this built fine with no errors, but I'm wondering if it's a suitable clock configuration.

Thanks in advance for any pointers.

-Pat

[jschmitz]

sys_clk is required to come in on the same column as the interface.  The sys_clk can be shared vertically among the controllers.  While you can route the clock in from other places, it isn't supported.  Your method might work, but it won't be supported by Xilinx.

Can you do anything else to squeeze in the sys_clk in these interfaces?  DCI cascade?  Using Micron parts with dynamic ODT to save a pin?

[rloader]

Re:

> While you can route the clock in from other places, it isn't supported.

> Your method might work, but it won't be supported by Xilinx.

Is there any chance Xilinx could provide less black-and-white advice on clocking for people who don't need the highest possible data rates?

E.g., DDR2-666 presumably has hugely more relaxed clocking requirements than DDR3-1866.

[Ditto clocking transceivers - there's orders of magnitude difference between driving 8b/10b SGMII one inch to a phy and  128b/130b at 28Gbps over a metre of cable.]

I'm guessing that providing relaxed clocking guidelines would need to be in the form of software tools for design-specific analysis...

Cheers,

Ralph.

[jschmitz]

>> While you can route the clock in from other places, it isn't supported.

>> Your method might work, but it won't be supported by Xilinx.

> Is there any chance Xilinx could provide less black-and-white advice on clocking for people who don't need the

> highest possible data rates?

I suggest you open a webcase and/or contact your FAE with this request.