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
_whitelogger has joined #apicula
<pepijndevos> trabucayre, do you think it'd be possible to bitbang JTAG on a Raspberry? IIRC some parts of the process need specific speeds
<trabucayre> yes of course. It's I have done for the ULX3S which uses an ft232rl
<trabucayre> In fact using GPIOs to have a JTAG bitbang is in my TODO since 1 year
<trabucayre> I've seen tries to integrate a jtag framework in linux kernel, but seems not in the mainline
<pepijndevos> Hmmm, so I guess only problem is if the pi has enough ram to use nextpnr
<pepijndevos> Well I guess for CI I could just build bitstreams online and only upload them on the pi. But if I'm making a Gowin HAT, people would probably like to run yosys and nextpnr on the pi itself.
<trabucayre> building something in a RPI is a strange thing to me :)
<trabucayre> the talk is done by a colleague, I'm coauthor
<pepijndevos> I mean, at what point does something stop being a target and starts being a full computer?
<pepijndevos> Obviously if you're going to be compiling stuff *for* a raspberry pi *all day* better get into cross-compiling, but if you're using the pi to program something else, it's no longer a target...
<pepijndevos> It might still be mind numbingly slow to PnR a CPU on the Pi... but it should be possible I think
<pepijndevos> Certainly for a blinky it might be less of a hassle to just PnR on the Pi than ssh the bitstream over. At that point what are you even using the pi for
<trabucayre> Yes of course. I'm agree
<trabucayre> With modern "embedded" board it's difficult to see limit...
<pepijndevos> On my machine PnR of attosoc takes a gb of ram it seems. Not sure how much it'd be on a 32 bit system, but... seems to be within reach
<pepijndevos> Takes the same to just do a blinky so... probably just the chipdb. ugh... need to write a better nextpnr target
<pepijndevos> gw1n-1 is definitely doable it seems
<trabucayre> In fact adding yosys, nextpnr, etc. to buildroot is in my todolist too
<trabucayre> openFPGALoader (outdated) is available (not my fault) ;-)
<trabucayre> rpi4 is a 64bits quadcore with plenty of RAM
<pepijndevos> Yea. The zero is only 512mb though. seems a better match for these low-end fpga's. tec0117 and pi zero are... roughly the same size
<trabucayre> zero is more or less rpi1 with a different form factor
<pepijndevos> uhu
<pepijndevos> ohhh I forgot Gowin can also get the bitstream over SPI as a slave, so the Pi could just upload the bitstream. that sounds cool
<trabucayre> Boards with onbard jtag are really great... But I need boards without too :)
<trabucayre> pepijndevos: I'm unable to see doc about using SPI to load a bitstream
<pepijndevos> It can use external spi flash right?
<trabucayre> TN653 explains how to use JTAG to program external Flash
<pepijndevos> You can't exactly program it, but it can load a bitstream in spi master and spi slave mode.
<pepijndevos> Normally you use master mode and the slave is the spi flash
<pepijndevos> but you can also use slave mode, and a microcontroler can load a bitsream directly
<pepijndevos> Maybe they call it PC mode, I don't remember
<trabucayre> true. DS100 AUTOBOOT, SSPI, MSPI, CPU, SERIAL, Dual Boot
* trabucayre has to sniff SPI transactions
<trabucayre> it's requires to pass in SSPI
<trabucayre> runber seems good to test this mode
<trabucayre> pff pins are mspi, others sspi ... :-/
<pepijndevos> Do any of the boards expose the necessary mode pins to select sspi?
<trabucayre> i need to check all of them :)
<trabucayre> Trenz no (and it's not possible to mode resistors for Pin mode)
<trabucayre> pepijndevos: you have designed a board based on gowin's FPGA, no?