pepijndevos changed the topic of #apicula to: Project Apicula: bitstream documentation and tooling for Gowin FPGAs https://github.com/YosysHQ/apicula -- logs https://freenode.irclog.whitequark.org/apicula
<trabucayre> pepijndevos: to use your rpi for flashing an FPGA it's now possible to use netcat :-)
<disasm[m]> trabucayre: does it use USB CDC for communication?
<disasm[m]> I also thought about something like this for flashing iCE40 with compressed bitstreams (which ice40 don't support): just stream a compressed bitstream into a programmer, the programmer decompresses it on the fly and programs the FPGA/SPI flash
<trabucayre> in my case it's a just support of '|' (ie a read for stdin)
<trabucayre> I have a github issue to support a gzip compressed bitstream.
<disasm[m]> Oh, apparently, you're talking about regular rpi, not pico
<trabucayre> yep. I've forget everyone is focused to the pico
<trabucayre> :)
<disasm[m]> <trabucayre "I have a github issue to support"> My idea was to improve performance for slow JTAG interfaces. For example, Colorlight i5 board has a CMSIS-DAP JTAG probe, which is extremely slow. If you feed a compressed bitstream instead of a regular one, you can cut programming time in half, for example.
<disasm[m]> Same thing for ULX3S. Luckily, ECP5 supports compressed bitstreams out of the box.
<trabucayre> yep
<trabucayre> I've added the colorlight i5 in my order list :)
<trabucayre> for ULX3S the ft232R is a problem :-/
<trabucayre> bitbanging is always slow
<disasm[m]> Maybe one day I write a damn fast firmware for that colorlight programmer chip.
<disasm[m]> IIRC I achieved 10MHz JTAG bitbang speed on STM32F103
<trabucayre> it's a thing I need to improve for openFPGALoader. By default it use 6MHz freq
<trabucayre> I must to configure freq to fit max allowed speed for the target FPGA
<disasm[m]> I investigated this problem for iceprog which also uses 6MHz iirc. The main issue was synchronous USB access which limits the overall speed by a great amount.
<disasm[m]> For iceprog you can't do better if you just change the frequency to 24MHz. Nothing changes, really.
<trabucayre> with openFPGALoader you need to use --freq to configure freq
<trabucayre> the only device where the freq is changed is gowin -> 2.5MHz
<trabucayre> for i5 I need something to plug the board :)
<disasm[m]> i5 extension board?
<trabucayre> yep
<disasm[m]> Sure, that's why I ordered a combo from Aliexpress
<disasm[m]> Nice Type-C programming connector and lots of PMOD-compatible headers
<trabucayre> yep
<trabucayre> but one of more important task is Ãto relicense openFPGALoader (unable to decide between apache and BSD)
<trabucayre> disasm[m]: for ice40 if iceprog don't want to change speed you can use openFPGALoader :)
<disasm[m]> <trabucayre "disasm: for ice40 if iceprog don"> No, I mean, the problem is not JTAG speed, the problem is overall performance
<trabucayre> ahh. Ok
<trabucayre> Seems logical. When programming flash you spend most of the time to wait for sector erase end and the wren bit...
<trabucayre> pepijndevos: I'm stupid. If I'm able to have access to SSPI the best solution is to write the driver
<disasm[m]> trabucayre: I believe kernel provides a generic SPI interface
<trabucayre> yep
<trabucayre> and an fpga interface
<trabucayre> I think I must solder wires directly to the Pins of my runber
<trabucayre> ice40 is already supported
<omnitechnomancer> you can use spidev to do userspace spi