Re: Synchronous FIFO hardware considerations, was: Re: kudos Thomas Heller Tue Apr 03 11:01:09 2012
Am 03.04.2012 18:50, schrieb Uwe Bonnes:
"Thomas" == Thomas Heller<[EMAIL PROTECTED]> writes:Thomas> Sure it is something similar to /dev/null currently. If there is some physical transfer I don't consider it as /dev/null... Thomas> I'm using Thomas> a FT2232H minimodule, TXE# is connected to WR#, and RXF# is Thomas> connected to RD#. Let's just assume that my FPGA that I will Thomas> connect next can keep up with the read/write cycles. The FPGA should easily cope with the rate. What's hard to reach is the timing. WR# needs minimum 11 ns before CLKOUT, so with 16.667 ns period you have only 5.667 ns in the FPGA. You won't reach that with a XC6S-4 device. I had to relax the constraints for about 1/2 ns.
Sure, we had this before. I need an XC6S-3 anyway to meet the timing constraints for my logic; parts of that need to operate with 250 MHz clock. Then, the FT232H is a little mit faster. Finally, I have seen a trick where the RD# and WR# signals are pipelined outside the FPGA throughD-flipflops - although the state machine must be changed to work with that approach. I haven't yet thought this through but will consider it.
Thomas> My program uses a home-grown ctypes based python wrapper for Thomas> libftdi, it reads resp. writes in 1MB blocks from/to the Thomas> minimodule. The functions that I use are ftdi_read_data() and Thomas> ftdi_write_data(); the program measures the time that these Thomas> calls take and reports a datarate of 19.xxx MB/s in each thread. Thomas> I'm looking with an oscilloscope at the RD# and WR# signals, a Thomas> screen shot is attached. I can see bursts of 8 block (of 512 Thomas> bytes probably). With real data every time the FTx232H is not ready you need more clocks to recover than with your data-shortcut. So data rate might drop. But we also reach> 16 MByte/s.
Well, actually my application needs to write with a rate of less than1MB/s, but should be able to read with 10MB/s or more. The most important point, however, is that there should not be too long pauses
in the reading stream because the FPGA cannot buffer too much data. And I don't wont to learn how to build a real deep fifo with a DDR2 memory. Thomas -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details.To unsubscribe send a mail to [EMAIL PROTECTED]
- kudos Thomas Heller 2012/04/03
- Re: kudos Uwe Bonnes 2012/04/03
- Re: kudos Thomas Heller 2012/04/03
- Synchronous FIFO hardware considerations, was: Re: kudos Uwe Bonnes 2012/04/03
- Re: Synchronous FIFO hardware considerations, was: Re: kudos Thomas Heller 2012/04/03 <=
- Re: kudos Xiaofan Chen 2012/04/03