Xillybus does not met timing

Questions and discussions about the Xillybus IP core and drivers

Xillybus does not met timing

Postby Guest »

Hi guys,

I'm experimenting with a custom logic implemented in den zedboards fabric and would like to use the xillybus for interfacing an embedded linux. But I have problems with implementing the xillybus in my design.
ISEs synthesis reports a maximal frequency of 85 MHz, while the critical path seems to be somewhere in a dcm used by the xillybus vga core. The specific message from the synthesis report is:
=========================================================================
Timing constraint: Default period analysis for Clock 'dcm_ins/clkout0'
Clock period: 11.708ns (frequency: 85.413MHz)
Total number of paths / destination ports: 4024 / 450
-------------------------------------------------------------------------
Delay: 4.503ns (Levels of Logic = 4)
Source: xillybus_ins/system_i/xillyvga_0/xillyvga_0/xillyvga_core_ins/vga_fifo_wrapper_ins/vga_fifo/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/v6_noinit.ram/SDP.WIDE_PRIM18.ram (RAM)
Destination: xillybus_ins/system_i/xillyvga_0/xillyvga_0/xillyvga_core_ins/vga_fifo_wrapper_ins/vga_fifo/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/v6_noinit.ram/SDP.WIDE_PRIM18.ram (RAM)
Source Clock: dcm_ins/clkout0 rising 2.6X
Destination Clock: dcm_ins/clkout0 rising 2.6X

Data Path: xillybus_ins/system_i/xillyvga_0/xillyvga_0/xillyvga_core_ins/vga_fifo_wrapper_ins/vga_fifo/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/v6_noinit.ram/SDP.WIDE_PRIM18.ram to xillybus_ins/system_i/xillyvga_0/xillyvga_0/xillyvga_core_ins/vga_fifo_wrapper_ins/vga_fifo/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/v6_noinit.ram/SDP.WIDE_PRIM18.ram
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
RAMB18E1:CLKARDCLK->DOBDO13 1 2.454 0.485 ramloop[0].ram.r/v6_noinit.ram/SDP.WIDE_PRIM18.ram (DOUTB<32>)
end scope: 'xillybus_ins/system_i/xillyvga_0/xillyvga_0/xillyvga_core_ins/vga_fifo_wrapper_ins/vga_fifo/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/gnativebmg.native_blk_mem_gen/valid.cstr:DOUTB<32>'
end scope: 'xillybus_ins/system_i/xillyvga_0/xillyvga_0/xillyvga_core_ins/vga_fifo_wrapper_ins/vga_fifo:dout[32]'
LUT4:I2->O 3 0.053 0.616 scan_ins/fifo_rd_en1 (fifo_rd_en_w)
begin scope: 'xillybus_ins/system_i/xillyvga_0/xillyvga_0/xillyvga_core_ins/vga_fifo_wrapper_ins/vga_fifo:rd_en'
LUT3:I0->O 1 0.053 0.399 U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/tmp_ram_rd_en1 (U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/tmp_ram_rd_en)
begin scope: 'xillybus_ins/system_i/xillyvga_0/xillyvga_0/xillyvga_core_ins/vga_fifo_wrapper_ins/vga_fifo/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/gnativebmg.native_blk_mem_gen/valid.cstr:ENB'
RAMB18E1:ENARDEN 0.443 ramloop[0].ram.r/v6_noinit.ram/SDP.WIDE_PRIM18.ram
----------------------------------------
Total 4.503ns (3.003ns logic, 1.500ns route)
(66.7% logic, 33.3% route)


I've tried to reduce the systems clock to 50MHz or 85MHz but then implementation fails, I guess because the dcm needs 100MHz to generate the correct clock for the vga core?
Are there missing constraints in the .ucf file - I'm currently using the xillydemo project.

Would be great, if someone can help me with this!
Thanks, cheers,
Friedrich
Guest
 

Re: Xillybus does not met timing

Postby support »

Hello,

As you've surely noticed, the Xillybus bundle has no problems meeting timing when implemented by itself.

ISE's critical path report says very little about where the timing problem is, because it doesn't have the information about what clock frequencies are actually going to run on each clock net. In other words, it hasn't looked in the UCF.

The fact that a path in the Xillyvga path showed up is meaningless, as the rough frequency limit estimation is 85 MHz, but the actual clock running there is 65 MHz. So there is no reason to suspect a problem here.

The place to look for timing issues is the post-place-and-route timing report. And that info should be taken with a grain of salt as well, because the failing paths are sometimes a result of some other paths eating up the precious routing resources. So the solution to a timing problem sometimes lies in the paths that appear in the list of worst paths, and sometimes in something completely different, which prevented the paths that failed from getting fast routes.

In short, noone said saving timing problems was easy. :)

Regards,
Eli
support
 
Posts: 802
Joined:


Return to Xillybus