How to get gapless clocking using an FTDI FT2232H? - Page 1
Forum section: electronics / projects

author: berke
author_rank: Frequent Contributor
timestamp: January 08, 2023, 12:13:22 pm
content: Hi all,I want to transmit an arbitrary bitstream to and from a Linux x86 PC using one of the channels of an FT2232H, specifically, the one on the iCE40HX8K Lattice evaluation board. Signals for FIFO mode are not connected unfortunately and the pitch on the FTDI chip is a bit too fine to solder extra wires.Using libftdi 0.20 and some C code lifted from iceprog I managed to send a stream with a 30 MHz clock in MPSSE mode, however I get a gap in the clock every byte, see below. Clock is CH1 in yellow. The effective bit rate is therefore 8/9×30=26.667 Mb/s.I've tried negative and positive edge data output (transfer commands 0x10,0x11) and options (0x8e clock every bit, 0x8f clock every byte) and packet sizes from 16 to 65536 bytes.Is there a way of getting a continuous bitstream?

author: Terry Bites
author_rank: Super Contributor
timestamp: January 08, 2023, 02:47:12 pm
content: A similar query may help.stackoverflow.com/questions/49306040/ft2232h-irregular-clock-in-spi-mode

author: berke
author_rank: Frequent Contributor
timestamp: January 08, 2023, 04:00:23 pm
content: Quote from: Terry Bites on January 08, 2023, 02:47:12 pmIt's not clear what those commands do, but I had already tried a few different values (0/255 etc.) for SETB_LOW. I just tested 0x80 0x08 0x0b. And both clock polarities (0x10 and 0x11) - one of these should match the resting clock polarity, but it makes no difference as far as the gap is concerned. But I just noticed the AN108 saysQuoteSounds like there is an unavoidable gap between commands? But what is a command? I see a gap between bytes of a single MPSEE transfer command.In my case it must be low in the initial state.

author: langwadt
author_rank: Super Contributor
timestamp: January 08, 2023, 04:13:28 pm
content: why is the gap a problem?

author: berke
author_rank: Frequent Contributor
timestamp: January 08, 2023, 04:21:39 pm
content: Quote from: langwadt on January 08, 2023, 04:13:28 pmI want to regularly sample an independent bitstream. If the FTDI clock was regular I could just use that a a sampling clock. Now I will have to generate a slower clock with some margin for drift, create a buffer and deal with dual clock domain nastiness.

author: Someone
author_rank: Super Contributor
timestamp: January 08, 2023, 09:03:33 pm
content: Use slave config on the FPGA? that supports SPI and gapped clocks natively.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 08, 2023, 09:38:13 pm
content: You will never get a continuous stream of data with A FTDI chip - even in FIFO mode. The main difference in FIFO mode is that you'll get much higher throughput.Unless you used an isochronous USB interface (but even that would have some limitations), you'll need to consider your data stream as asynchronous and buffer data appropriately.

author: langwadt
author_rank: Super Contributor
timestamp: January 08, 2023, 10:47:50 pm
content: Quote from: berke on January 08, 2023, 04:21:39 pmmaybe flip the problem around and use fast serial you'll need a 10:8 "gearbox" to add the "start" "stop" bits but it'll all be running on a clock from the FPGA, up to 50MHz afair

author: berke
author_rank: Frequent Contributor
timestamp: January 08, 2023, 11:13:54 pm
content: Thanks to all for the feedback and suggestions. I'll sample the stream at 24 MHz and fill a FIFO, and empty it in MPSSE mode with 30 MHz gapped transfers.Any orders of magnitude for the BER I should expect from the USB part? I get about 5e-10 (example 38 errors out of 77 Gb, often two consecutive bits).

author: Njk
author_rank: Frequent Contributor
timestamp: January 09, 2023, 01:46:25 am
content: Quote from: berke on January 08, 2023, 12:13:22 pmIf your intention to get a continuous bitstream over the USB is strong, don't use a pre-fabricated bridges from FTDI, Silabs, Prolific, etc. That bridges are very convenient, but the host does not reserve USB bandwidth for them. It may work well in most cases but it's possible to conduct a test (e.g. at the lawyer's request) to demonstrate that the continuity is broken. When the host is very busy serving the other USB devices.In that case a better way would be to implement a custom USB device of Audio class (perhaps using the same FTDI chip form factor). So you can specify the bandwidth resource requirements in the Audio class descriptors (not sure about 8 MHz though). When the device has plugged in, the host reads the descriptors during the enumeration procedure and reserves the BW for the device as required. If no BW is available at the moment, the host simply refuses to enumerate the device. But if the device is accepted, the BW is really reserved and you can stream your data over the isochronous pipes with confidence, because the continuity is guaranteed by the USB system architecture.