--- Quote Start ---
Is this an I/O port? Looking at the Data Path tab, I'd guess it's internal to the FPGA.
Your transfer is from rising edge to falling edge(i.e. the latching logic triggers on the falling edge), so it defaults to a half-cycle setup relationship, or 3.75ns. Your latch clock is on a PLL, which basically removes the clock tree delay, but your source clock is not. So the clock skew completely cuts into your setup requirement. Your data path delay is less than 2ns, but because of these two things it's still not enough.
Is the 3.75ns requirement your intended transfer? If so, can the data path be shorter? I doubt it can be 800ps shorter, but might be. Can you change the clocks to make the requirement/skew more palatable? Reading the document will help with understanding, but won't provide a solution, since this is unique to your design.
--- Quote End ---
Hi Rysc and thanks for your reply. Here's a little bit more info about what I am trying to achieve!
Basically my design is to be used in some simple DV testing, where I am taking the top and bottom line of a screen from a LVDS stream and sending it them out over usb.
The LVDS data is deserialised by a deserialiser board into parallel 24-bit LVDS and a Pixel Clock. For the moment instead of using the actual LVDS RGB565 data, I am just using an 18 bit counter (so I know what my expected data is for simulation and can see which bytes im losing/gaining when debugging). Aswell as these 18 bits, there are 4 reserved channels a Hsync and a Vsync.
I am using the actual pixel clock Hsync and Vsync that are generated internally.
The data is clocked into the FPGA using a 33.3MHz clock (LVDS_CLK in my design) this clock is fed through a PLL to give a clock four times the speed (this is MULT_CLK in my design). So that my 24-bit LVDS data can be clocked into an 8 bit DC fifo.
The clock is four times the speed so that the 3 data bytes can be written, and FIFO_WR can be held low on the rising edge of LVDS_CLK to avoid any race conditions or problems clocking bytes into the FIFO. The data is now clocked into the FIFO on the RISING edge of the MULT_CLK, which got rid of the timing issues shown in the screenshot attached to my last message.
My design simulates correctly, and now, timequest gives no errors about timing. However I MUST have timing issues somewhere as the data I am recieving over USB has missing data bytes and bytes read more than once.
I am using the Morph-IC-II board which has the Cyclone II FPGA, and an FTDI FT2232H chip to handle the USB side of things.
Once an entire line of pixels (800 pixels => 2400 Bytes) has been clocked into the FIFO on the FPGA, then it is clocked out to the TX buffer on the FT2232 chip. This then waits for a command on a little C# application which allows it to transmit the contents of its TX buffer over USB.
All buffer sizes are larger than they need to be, so I am not losing data there... so there must be a timing issue somewhere... but I can't find it and don't know where to begin as the simulation looks fine, timequest seems happy, but it doesn't work when dropped onto the hardware...
Any help or ideas are much appreciated as I am very stuck and a little out of my depth!!!
Anymore information that is required just shout!!
Regards,
Lee H
Honored Contributor
