Hi! This is very interesting information.
On Sun, Oct 19, 2025 at 02:15:30PM +0200, Embedded Systems Engineering wrote: > Hi Everyone, > > thank you for all your feedback. I did some more research, datasheet reading > and calculations to answer everything properly. While doing this I > oscillated back and forth between possible and not possible, now I'm > convinced that it will work :) > > ## Concept/Idea > The idea would be to use a FT601 with some glue/clock-logic supporting only > USB3 for data capturing. > > Important is to use USB3 in bulk transfer and that the FT601 is the only > USB3 device on the bus. For me, this is a significant limiting factor, especially since the topology is not necessarily clear on what is the bus. I'm not 100% sure about USB3 architecture, but in USB2 terms this should rather be "the only USB3 device on the root hub", which is possibly difficult to achieve due to internal architecture of PCs/laptops. > The datasheet of the FT601 claims 100 MB continues data stream and 400 MB in > burst with USB3 mode, so these settings would be an possible: > - 8ch @ 100 MHz: 1 Byte x 100 MHz = 95.36 MB/s or > - 16ch @ 50 MHz: 2 Byte x 50 MHz = 95.36 MB/s or > - 32ch @ 25 MHz: 4 Byte x 25 MHz = 95.36 MB/s > > The FT601 has a 16kB (16384 bytes) FIFO. > Sampling 8 channel with 100 MHz would mean 1 byte per 10ns. > 16384 bytes x 10 ns = 163.84µs > So the FIFO could hold data for 163.84µs. Meaning any jitter past this time would be a problem. > > ## USB Timing > USB1 and USB2 are electrically based on one bidirectional differential pair, > meaning the Host or the Device can send data, not both together. In practice > the host polls the device every (micro)frame and that's the fines time grid, > the device can send data back to the host. > > USB1 frame: 1ms > USB2 micro-frame: 125µs > > It might already work with USB2 since the buffer can data for 164µs and the > USB2 timing grid is 125µs. But its highly unlikely that data can be send on > every micro-frame with USB bulk or interrupt transfer. > > USB3 uses a differential lane, meaning one unidirectional differential pair > for Transmit and one for Receive. Host and device can send data > simultaneously. It also uses 125 µs micro frames for communications, but > uses a credit based system, meaning that the device is allowed to transmit a > certain amount of data without further permission. > > 1 credit = 1 packet (1024 byte) > > Up to 256 credits per endpoint are possible; meaning 256kB without further > permission. Every transmission decreases the credit count, while every micro > frame the Host will update the credits. In practice 8-16 credits are > typical. > > USB3 Bulk transfer can occupy the entire micro frame bandwidth as long as > the host grants enough credits. > > USB3 max data rate: 5Gb/s x 8/10 => 500 MB/s > USB3 max. data per micro frame: 600 MB/s * 125µs = 62.5 kB > FIFO data per micro frame:12.5 kB > 16 USB3 credits would already work. > > With this mechanism the device can send data to the host continuously, > resulting in a stream-like h. > > Please let me know if you find any mistakes in my calculations. > > ## open questions > Can anyone answer or help with those questions: > > 1. How many credits does the FT601 get from the USB Host and can those be > change within the driver? The driver uses libusb and I was unable to find a way to change the credit allocation. TBH, I did not know about the exact mechanism until I read your email. USB2 has been plenty enough for the stuff I usually do. > 2. Could someone check the USB descriptors of the FT601 with "lsusb -v" on a > linux machine and share the output? > 3. Is it possible to change the settings/mode of the FT601 with Lambda > Concept driver? I don't think so, but I might be wrong. I tried to dig into this and I can't find credits mentioned in the lambda driver, or in the linux kernel -- with the exception of USB3 tunneling over TB/USB4. This leads me to believe this is managed in the USB3 silicon. Or it can just be named something I'm not expected, not an expert here. However, this forced me to look into the lambda concept driver and I realized it's not a libusb driver (as I expected it would be), but rather a linux kernel driver. This means it would not be possible to use it on windows/osx, and would be quite difficult to ship it with sigrok. (while it likely also means it would perform well) > 4. Which FT601 board are you guys using? Anyone using the evaluation board > UMFT60x? > Best regards, Ladislav _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
