<kbeckmann>
my experiment was with ECP5 + ft600 (theoretial max at 200 MB/s). i had to do use ping pong buffers and make sure they were large enough to not cause buffer underruns.
<kbeckmann>
ft60x wants you to make full 4k transfers in one go. and then there are, like @atx says, long gaps between USB transactions.
<whitequark>
can you tell me more about the buffering in ft60x?
<whitequark>
i'm pretty sure revE will use fx3, but just in case someone convinces me otherwise, i'd like to understand potential pitfalls of ft600
<tnt>
kbeckmann: oh oops, sorry I got confused ... (there is like 2 usb3 IF chips and I manage to confuse them ...)
<tnt>
Wouldn't using a FTDI part sort of clash with the Glasgow name story ? :)
<whitequark>
tnt: shrug. suppose cypress discontinues fx3 tomorrow. what am i going to do?
<whitequark>
i find it exceedingly unlikely that i'll go for ft600 but that doesn't mean i want to be ignorant of the possibility
<whitequark>
(a reasonable answer to "what am i going to do?" that doesn't involve ft600 is LUNA on another ECP5, though this gets weirdly FPGA-heavy...)
<tnt>
I was just looking up the ecp-5g prices vs ft601 prices to suggest that :p But it's not as "unbrickable" though.
<tnt>
(even if the first ecp5 config is supposed to be fixed, it's still on a programmable device somewhere that could get erased)
<kbeckmann>
one more thing with ft60x to consider is that it can operate in different modes. 245 mode which is quite straight forward vs the multi channel mode which i have not used myself. it seems to lack a bit in the documentation, but it might lead to higher throughput on the ft601. the apertus folks have been doing some benchmarking around this recently and also wrote a rust driver which uses way less
<kbeckmann>
cpu than the official driver.
<kbeckmann>
i am not aware of any more pitfalls, and it might be that the issues i saw were caused by my own code.
<electronic_eel>
the thing with requiring full 4k transfers - isn't that problem with usb itself, not just this particular ic? the host just queries the device instantly again if it received a full buffer. otherwise the device has to wait for the next cycle, giving much higher latency and lower throughput.
<kbeckmann>
electronic_eel: the ft60x has internal fifo buffers, and i think what happens when you do shorter transfer, is that they become short usb transfers as well. it could've queued up and combined multiple short transfers into a larger one when the usb phy is ready for a new packet, but i am not sure it does this.
<electronic_eel>
kbeckmann: I don't think it would be a good idea if the ft60x began to combine multiple internal buffers into one usb transfer. because a common pattern for encoding data in usb streams is to encode the data depending on the position within the usb transfer. for example the first byte of a usb transfer is some status bits or encodes the type of transfer or similar, and the rest of the transfer is data of another kind. ftdi uses this scheme
<electronic_eel>
themselves when using one of their uart modes
<electronic_eel>
if the ic would combine and reorder the buffers, you'd completely lose control over what goes together into one usb transfer
<d1b2>
<kbeckmann> Good point. My naive implementation connected a fifo straight to the ft600 which led to terrible performance which is why I went for the ping pong solution.
<whitequark>
ok, that sounds basically the same as the fx2
<_whitenotifier-f>
[glasgow] thasti commented on pull request #215: Update SPI signal terms to COPI / CIPO - https://git.io/JTLnn
<thasti>
wrote my first glasgow applet today :) thanks for this amazing piece of hard/soft/gateware!
Foxyloxy has quit [Quit: Leaving]
Foxyloxy has joined #glasgow
<whitequark>
i'm glad you like it!
emily has quit [Quit: killed]
promach3 has quit [Quit: killed]
fridtjof[m] has quit [Quit: killed]
sambristow_nz[m] has quit [Quit: killed]
ZerataX has quit [Quit: killed]
disasm[m] has quit [Quit: killed]
jschievink has quit [Quit: killed]
gillesmauve has quit [Quit: killed]
jevinskie[m] has quit [Quit: killed]
bvernoux has quit [Quit: Leaving]
jschievink has joined #glasgow
sambristow_nz[m] has joined #glasgow
gillesmauve has joined #glasgow
emily has joined #glasgow
disasm[m] has joined #glasgow
ZerataX has joined #glasgow
fridtjof[m] has joined #glasgow
jevinskie[m] has joined #glasgow
promach3 has joined #glasgow
<_whitenotifier-f>
[glasgow] attie synchronize pull request #215: Update SPI signal terms to COPI / CIPO - https://git.io/JTU4c
<_whitenotifier-f>
[glasgow] attie commented on pull request #215: Update SPI signal terms to COPI / CIPO - https://git.io/JTL2W
<_whitenotifier-f>
[glasgow] whitequark commented on pull request #215: Update SPI signal terms to COPI / CIPO - https://git.io/JTL2z
<_whitenotifier-f>
[glasgow] attie commented on pull request #216: applet.interface.freq_counter: implement a frequency and duty-cycle counter - https://git.io/JTLw9
<_whitenotifier-f>
[glasgow] attie synchronize pull request #216: applet.interface.freq_counter: implement a frequency and duty-cycle counter - https://git.io/JTU6D
<_whitenotifier-f>
[glasgow] attie synchronize pull request #216: applet.interface.freq_counter: implement a frequency and duty-cycle counter - https://git.io/JTU6D
<_whitenotifier-f>
[glasgow] attie synchronize pull request #216: applet.interface.freq_counter: implement a frequency and duty-cycle counter - https://git.io/JTU6D
<_whitenotifier-f>
[glasgow] attie commented on pull request #216: applet.interface.freq_counter: implement a frequency and duty-cycle counter - https://git.io/JTLiR