Side-BUFG, BRAMS and clock routing
Paul Boven
I've built a small project on the XC3SD1800A kit that receives ethernet
frames and displays their content as a 256x256 4-bit greyscale image via
its VGA port. This uses 16 BRAMS (inferred) as video-ram.
At first the image that got displayed was full of distortions. I also
had hold-time violations of more than 8ns to the address lines of some
of the BRAMs. After much research I learned that the vga_clk on this
particular Xilinx dev-kit is connected to a pin (P26) that goes to a
side-bufg (BUFGMUX_X3Y8) at the right-hand side of the die, which can
only use the global clock resources of the right-hand side of the chip.
So, I've added this constraint to my UCF:
INST "Mram_vram*" LOC=RAMB16_X2Y*,RAMB16_X3Y*;
And then the other shoe dropped: I'm using the video-ram as dual-port
ram: the other clock is the eth_rx_clk which comes from pin P1, which is
a left side clock pin. So I end up with error Place:1018 "A clock
IOB/clock component pair have been found that are not placed at an
optimal clock IOB/clock site pair".
I've used the CLOCK_DEDICATED_ROUTE = FALSE setting to get things to
compile, but I get a big warning about this being not recommended at all.
As this kit comes with a PCB and everything already soldered in place I
can't change these pin assignments. Are there any recommended ways to
improve timing in such a situation?
Regards, Paul Boven.
Brian Drummond
wrote:
Derive a third clock from one of these two, in a DCM, which can use
globally routable resources?
- Brian
Paul Boven
Brian Drummond wrote:
> On Tue, 26 Aug 2008 23:38:00 +0200, Paul Boven <p.b...@xs4all.nl>
>> [ clocking a dual-port BRAM from a left and right side bufg ]
>> As this kit comes with a PCB and everything already soldered in place I
>> can't change these pin assignments. Are there any recommended ways to
>> improve timing in such a situation?
>
> Derive a third clock from one of these two, in a DCM, which can use
> globally routable resources?
Ah thanks - that's a very simple solution, and as I have plenty of clock
resources left, should just work. As the vga_clk is only driving the VGA
outputs there's no need for a fixed (or even known) phase offset between
the crystal and the actual pixel clock, so that's the one I'll try to
run through a DCM this evening.
Regards, Paul Boven.