Metastability issue? How to clock in high speed ASYNCH Data

[Altera_Forum]

Dear Gurus, 

 I am relatively new to VHDL and hardware so here goes…   I have designed a board that receives asynchronous data from a PC via USB @ ~ 12mb/s via an FTDI device (FT2232H). The device (in the mode I'm using) clocks its data out to the FPGA using a 60MHz clock (so the WR# strobe is ~16.67ns). The FPGA clock is 50MHz.   I'm still in trying to determine whether this is an FTDI driver issue but and I have started to read about metastability and clock domains and wondered if there is a laymens guide out there. I am trying to digest SDYA006...    I have tried using the megawizard to generate a dual clock FIFO to sort the issue but I don't yet understand how I know when/how I can get out of it...    I have a block that waits to see when the rdempty signal is deasserted i.e. there is some data before clocking data out with rdclk , but it seems that the rdempty signal is clocked by the rdclk (so i am having to read it when it says it's empty to make get to say it's OK to read from it! [if that made any sense]).   I know I'm rambling and several guides just say use back to back registers but any guidance would help as a sensible way to practically achieve this. As I say I am no expert but you patience and guidance would be greatly appreciated.   Yours faithfully,   H

[Altera_Forum]

FYI, I'm not familiar with the FTDI chips. 

But if you have a 60 MHz clock on one write side and a 50 MHz clock on the read side, using a dual clock FIFO is, IMHO, the best aproach. Otherwise, you can't keep up with the write bursts from the USB chipç.  Assuming those two clocks are not related, you should generate the FIFO with 2 or more synchronization stages.  Regarding the read process, you sound a bit confused, but it's the same as for a single clock FIFO and depends on weather you've generated a "legacy" or "read-ahead" FIFO. Depending on how you've configured your FIFO, asserting rdreq when rdempty is active can cause the FIFO to become corrupted so you need to be carefull about that.

[Altera_Forum]

You are on the right track. dc fifo contains the neccessary clock domain transfer circuitry. They are reliable.  

 All what is left is control the buffering i.e. data transfer without getting your fifo empty or full.   reading empty fifo or writing to full fifo is not advised...   buffering control can be done by letting the fifo have a suitable depth and suitable start level then it simply provides the required so called elasticity of rate differences. The depth is dependant on your input burstiness.   In short: I will let my fifo first write to a predetermined depth level then start read/write cycles and keep a wacth on empty/full flags.

[Altera_Forum]

Hi Folks, 

 Thank you for taking to the time respond (and for going easy me).    I’ll stick with the DCFIFO and make sure the USB chunks are small enough to fit safely. Rbugalho is right – I am confused as I’m fairly new to this. Just as quick test I had a 1s clock connected to rdreq, redclk (and an LED) to clock the data back onto the USB input put so I could read it back. I got confused as to why it was taking ~5 clks for the rdempty signal to disappear after I had written to it. I have now attached the 50MHz clk to the rdclk and assert the rdreq to get data out.   Just out of interest, do anyone know if there are any timing constraints on the width of the wrclk – for example could this be as little as 1ns?   Thanks again or your help and advice, and for such a rapid response.   Best regards,   H

[Altera_Forum]

Hi, 

 The speed of fifo will be limited due to timing rules of any device(setup/hold). 1ns is pretty high speed(1Gig) and not achievable in fpgas yet. You may hit 300MHz in best devices(stratix iv).   RdEmpty signal update is delayed due to internal pipeline(synch pipeline defaults to 2 in megawizard, I believe).

[Altera_Forum]

The reverse is also true: wrfull update also be delayed relatively to reads because of the internal synchronization pipeline.