| 00:58 | karl[m] | left the channel |
| 00:58 | holger[m] | left the channel |
| 00:58 | apurvanandan[m] | left the channel |
| 00:58 | bluez_[m] | left the channel |
| 01:01 | holger[m] | joined the channel |
| 01:01 | karl[m] | joined the channel |
| 01:01 | apurvanandan[m] | joined the channel |
| 01:01 | bluez_[m] | joined the channel |
| 01:03 | hans[m]1 | left the channel |
| 01:03 | fabian[m]1 | left the channel |
| 01:03 | elkos | left the channel |
| 01:03 | pedro[m] | left the channel |
| 01:03 | francois[m] | left the channel |
| 01:03 | gretax[m] | left the channel |
| 01:03 | robert[m]1 | left the channel |
| 01:03 | oscar[m] | left the channel |
| 01:03 | apurvanandan[m] | left the channel |
| 01:03 | holger[m] | left the channel |
| 01:03 | karl[m] | left the channel |
| 01:03 | bluez_[m] | left the channel |
| 01:03 | Guest93381 | left the channel |
| 01:03 | promach3 | left the channel |
| 01:03 | joe[m]1 | left the channel |
| 01:03 | panintended | left the channel |
| 01:03 | pierre[m]5 | left the channel |
| 01:03 | davidak[m] | left the channel |
| 01:03 | preetimenghwani[ | left the channel |
| 01:03 | alexandros[m] | left the channel |
| 01:03 | metal_dent[m] | left the channel |
| 01:03 | MarkVandenBorre[ | left the channel |
| 01:03 | john_the_savage[ | left the channel |
| 01:06 | WalterZimmermann | joined the channel |
| 01:10 | apurvanandan[m] | joined the channel |
| 01:11 | joe[m] | joined the channel |
| 01:11 | davidak[m] | joined the channel |
| 01:11 | karl[m] | joined the channel |
| 01:11 | preetimenghwani[ | joined the channel |
| 01:11 | aleb | joined the channel |
| 01:11 | oscar[m] | joined the channel |
| 01:11 | elkos | joined the channel |
| 01:11 | alexandros[m] | joined the channel |
| 01:11 | john_the_savage[ | joined the channel |
| 01:11 | robert[m] | joined the channel |
| 01:11 | bluez_[m] | joined the channel |
| 01:11 | holger[m] | joined the channel |
| 01:11 | francois[m] | joined the channel |
| 01:11 | pedro[m]2 | joined the channel |
| 01:11 | metal_dent[m] | joined the channel |
| 01:11 | pierre[m] | joined the channel |
| 01:11 | fabian[m]1 | joined the channel |
| 01:11 | hans[m]2 | joined the channel |
| 01:11 | panintended | joined the channel |
| 01:11 | gretax[m] | joined the channel |
| 01:42 | promach3 | joined the channel |
| 01:42 | MarkVandenBorre[ | joined the channel |
| 04:06 | intracube | left the channel |
| 04:07 | intracube | joined the channel |
| 05:08 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 05:52 | flyinprogrammer | joined the channel |
| 07:13 | flyinprogrammer | left the channel |
| 07:13 | flyinprogrammer | joined the channel |
| 07:46 | kbeckmann | joined the channel |
| 08:31 | kbeckmann | se6ast1an: hi! about the ft60x and throughput.. the stuff that i've done successfully with real-time data and ft600 has been working great up to around ~70 MB/s. Above that, I really need a larger FIFO.
|
| 08:35 | flyinprogrammer | left the channel |
| 08:50 | kbeckmann | if i generate data from the fpga, i can stream at 194MB/s, however there will be a lot of random, but short, delays which is why a larger FIFO is needed when you want to stream real-time data.
|
| 08:54 | mumptai | joined the channel |
| 09:00 | WalterZimmermann | left the channel |
| 09:06 | se6ast1an | hi kbeckmann!
|
| 09:06 | se6ast1an | you are very quick :)
|
| 09:06 | se6ast1an | too quick for me
|
| 09:06 | se6ast1an | but now I am back
|
| 09:06 | kbeckmann | haha i just had some spare time now.
|
| 09:08 | se6ast1an | what transfer mode are you using with USB
|
| 09:08 | kbeckmann | 245
|
| 09:09 | se6ast1an | we want to get to the USB3 bandwidth limit so 70MB/s or even 194MB/s is still not really what we aim for
|
| 09:09 | kbeckmann | i have not tried to use the fancier mode, it seems a bit complicated. but makes sense if you are pumping data in both directions simultaneously.
|
| 09:09 | kbeckmann | well the ft600 has a theoretical max of 200MB/s
|
| 09:10 | kbeckmann | it has only 16 bits in contrast to tf601/tf602 that has 32 :)
|
| 09:10 | kbeckmann | ft*
|
| 09:10 | kbeckmann | so 194 / 200 is probably as good as it gets.
|
| 09:10 | se6ast1an | ah, we use the FT601
|
| 09:11 | se6ast1an | but Isochronous transfer is not supported from what we gathered so far IIRC
|
| 09:12 | kbeckmann | right. and bulk will always have some random delays/jittar to it.
|
| 09:13 | kbeckmann | i don't know how the ft602 works, but my guess is that it's just ft601 with some extra descriptor glue and some more configuration functionality.
|
| 09:13 | kbeckmann | i'm not even sure if you can have isochronous mode at these speeds.
|
| 09:17 | kbeckmann | honestly I'm not sure what is causing the random jitter. it could be the driver. i should try again with this driver that is a kernel module, it might work better actually. https://github.com/lambdaconcept/ft60x_driver
|
| 09:20 | kbeckmann | se6ast1an: what data rates were you able to get with your ft601 adapter? were you limited by your fifo filling up and having to drop input data, or were you not able to reach a high data rate at all when sending generated data from the fpga?
|
| 09:22 | se6ast1an | we need to wait for Bertl_zZ, he will be able to share details
|
| 09:22 | kbeckmann | if you were having issues with your gateware, you could look at https://github.com/lambdaconcept/usbsniffer/blob/master/gateware/ft601.py for a good implementation.
|
| 09:22 | kbeckmann | cool
|
| 09:23 | se6ast1an | the large fifo should not be an issue, the fpga side will very likely also not be the bottleneck
|
| 09:23 | kbeckmann | which fpga are you using again?
|
| 09:24 | se6ast1an | from what I remember Bertl_zZ said the FT601 had eratic behaviour and higher datarates worked only unreliably...
|
| 09:25 | se6ast1an | Lattice MachXO
|
| 09:25 | se6ast1an | on the usb3 module
|
| 09:25 | se6ast1an | zynq 7020 on the camera core side
|
| 09:26 | kbeckmann | alright
|
| 09:26 | kbeckmann | looks like lcmxo2-2000hc-6tg100c from the photo
|
| 09:30 | kbeckmann | looks like it doesn't have a huge amount of embedded ram. are you able to buffer the frame on the camera module and consume the framebuffer asynchronously? in my case i am receiving a HDMI stream that doesn't wait for anybody, so I have to buffer as much as possible (because the ft60x will randomly stall because of how USB works).
|
| 09:34 | kbeckmann | sorry for all the questions.. i don't know a lot about your architecture, should read up on that :)
|
| 09:36 | se6ast1an | no worries
|
| 09:36 | se6ast1an | but I am afraid we have to wait for Bertl_zZ to wake up :)
|
| 09:36 | se6ast1an | for these technical details
|
| 09:56 | Bertl_zZ | changed nick to: Bertl
|
| 09:56 | Bertl | morning folks!
|
| 09:59 | Bertl | kbeckmann: we basically retrieve the data from DDR memory on the camera side and send it directly to the MachXO2
|
| 09:59 | Bertl | so buffering/feedback is possible, but we need a 'guaranteed' throughput as we are transporting live data as well
|
| 10:01 | Bertl | kbeckmann: why should 'USB' randomly stall on a dedicated USB connection of good quality?
|
| 10:27 | Bertl | off for now ... bbl
|
| 10:27 | Bertl | changed nick to: Bertl_oO
|
| 10:28 | kbeckmann | I see, that's great. This means that even if the transfers stall for short periods of time, this should be fine. As far as I understand it, bulk transfers don't have any guarantee of when they will occur, so your OS might handle some interrupt and not do another USB transfer for a while.
|
| 10:50 | kbeckmann | Bertl_oO: something that i also noticed, was that it's really important to transfer large chunks of data to the FT60x. The datasheet mentions this as well. If you transfer less than 1024 bytes, this will lead to a small USB bulk transfer which will lead to increased overhead which in turn will lower your throughput. Maybe this is what happened to you? I worked around this by using ping-pong
|
| 10:50 | kbeckmann | buffers and only initiate a transfer when i had a full 4096 bytes to transfer.
|
| 10:58 | Nick123 | joined the channel |
| 11:25 | Nick123 | left the channel |
| 11:34 | kbeckmann | It seems that the USB spec allows for isochronous transfers utilizing up to 80% of the available bandwidth, which for SuperSpeed means arond 500 MB/s. However your device still needs to support and configure this, which the FT60x doesn't seem to do, not even the ft602 that uses the UVC (USB Video Class). So you'd have to go for the Cypress FX3 or similar if you want this.
|
| 11:51 | Bertl_oO | well, the OS (on the USB controller side) is Linux, so I think it will not just ignore USB transfers because some interrupt is handled ... at least we get around 420MB/s transfer via USB storage which also uses block transfers
|
| 11:53 | Bertl_oO | the FT60x is limited to 32bit so the maximum data rate we can produce there is 3.2 Gigabit/s but I do not see why that should not be doable with a 5Gbit/s connection
|
| 11:54 | Bertl_oO | and yes, we figured out (too late) that the FT60x (not even the FT602) officially support isochronous transfers ... which seems especially strange as the FT602 is intended for UVC video
|
| 11:56 | Bertl_oO | the main problem so far seems to be to figure out the perfect package size as the payload on the bus is limited and to find a driver which is not based on the FTDI libraries which seem to do an awful job at receiving the data reliably :)
|
| 11:57 | Bertl_oO | so we are very much interested in alternative/known good solutions which can unlock the full potential of the FT60x chips
|
| 12:24 | se6ast1an | and yes we are also having our eyes on the FX3 now
|
| 12:57 | kbeckmann | Bertl_oO: regarding drivers, it might be worth checking out https://github.com/lambdaconcept/ft60x_driver
|
| 13:22 | RexOrMatrix[m] | joined the channel |
| 13:22 | RexOrMatrix[m] | Is the imec Temp Cam on schedule?
|
| 13:39 | oscar[m] | left the channel |
| 13:40 | se6ast1an | RexOrMatrix[m]: wrong channel probably but yes
|
| 13:42 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 13:50 | flyinprogrammer | joined the channel |
| 14:20 | MichaelSchwarzma | joined the channel |
| 14:22 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 14:33 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 14:33 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 16:41 | flyinprogrammer | left the channel |
| 17:58 | MichaelSchwarzma | left the channel |
| 18:29 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 19:06 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 20:39 | Bertl_oO | off to bed now ... have a good one everyone!
|
| 20:40 | Bertl_oO | changed nick to: Bertl_zZ
|
| 20:49 | panintended | Hi all
|
| 20:49 | panintended | Here's a PR for T1203 (the observer pattern for subscribing to attribute changes)
|
| 20:50 | panintended | https://github.com/apertus-open-source-cinema/AXIOM-Remote/pull/20
|
| 20:50 | panintended | Sorry it took a while, but today I had finally some breathing room with my day job :)
|
| 20:51 | panintended | Still no tests to go with it, but se6ast1an said it might still be worth merging it to the main repo
|
| 20:53 | se6ast1an | thanks!
|
| 20:53 | BAndiT1983 | hi panintended, just merged, thanks for your support!
|
| 20:53 | BAndiT1983 | will go through it soon, maybe tomorrow
|
| 20:56 | se6ast1an | great
|
| 21:05 | panintended | cool, any questions please let me know and I'll get back to you the soonest possible!
|
| 21:05 | panintended | have a good night guys
|
| 21:05 | panintended | talk to you soon
|
| 21:28 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 23:20 | mumptai | left the channel |