<tpb>
Title: FOSDEM 2023 - Self-Hosting (Almost) All The Way Down (at archive.fosdem.org)
<Adrien[m]>
Too bad this was in Risc-V devroom I would have seen this
<somlo>
I managed to talk my higher-ups into giving me a month of $dayjob to see if I can get this working on a xilinx board (i.e., using nextpnr-xilinx instead of vivado, to preserve the "self-hosting" property)
<somlo>
on the premise that one can build bigger/faster softcore SoCs on xilinx compared to Lattice ECP5 :)
FabM has quit [Ping timeout: 265 seconds]
<GenTooMan>
good fortune with that is all I can say
<GenTooMan>
may you not be cursed by crazed support information and arbitrary patches to dead versions of linux.
indy_ has quit [*.net *.split]
ymherklotz has quit [*.net *.split]
indy_ has joined #yosys
ymherklotz has joined #yosys
bpye has quit [Read error: Connection reset by peer]
bpye has joined #yosys
SpaceCoaster has quit [Read error: Connection reset by peer]
SpaceCoaster has joined #yosys
SpaceCoaster has quit [Read error: Connection reset by peer]
SpaceCoaster has joined #yosys
<Adrien[m]>
My little experience is for now purely with Zynq boards Zybo and Zedboards, respective FPGA size is 17k and 54k LUT6. RAM size is 512 MB (off-chip DDR).
<Adrien[m]>
My observation is that the limit is the amount of RAM available for the place-and-route tools. With 512 MB for the entire system, only a small fraction of the Zybo board can be used... this constraint should be largely relaxed with some Kintex boards with a few GBs of on-board RAM.
<Adrien[m]>
Yosys also takes a lot of RAM depending on the design size and also depending on some internal shape of the design, not sure what exactly
<somlo>
Adrien: IIRC, zynq based boards can only access RAM through the hard-IP (arm?) cpu core, so I've been avoiding any "hybrid" hard-cpu + fpga combos
<somlo>
I'm looking at the nexys video (artix7), genesys2 (kintex7), or some virtex7 board with a SODIMM socket where the soft-IP memory controller can talk directly to the DRAM
<juri_>
somlo: according to my reading of the datasheet, the memory controller is accessable from both the Arm cores, and the fpga.
<Adrien[m]>
Yes Zynq boards have the RAM accessible through the memory controller embedded in the PS part of the chip (Processor Subsystem), so it's completely part of the ASIC part of the chip.
<Adrien[m]>
For performance and energy it's great, and about resource usage it provides high bandwidth for both CPU and FPGA with absolutely no FPGA usage overhead taken by the DDR interface.
<Adrien[m]>
I think the ZC706 has 1GB of RAM as an SODIMM, should be upgradable, and the FPGA is large (but bitstream not documented in prjxray)
<Adrien[m]>
I mention the ZC706 only because it would complete so nicely the set of Zynq boards and chips tested with that flow
<Adrien[m]>
Correction : it has 1GB connected on PS memory controller, and 1GB directly on the FPGA.
<Adrien[m]>
* the FPGA. Total 2GB.
<Adrien[m]>
somlo: virtex7 bitstream is not documented yet in prjxray so no short-term hope about "self-hosting" these chips.
<Adrien[m]>
I have a VC709 board with 8GB of RAM and would like so much to materialize this...
<juri_>
what will we need to do to get the larger zynq chips supported? poking a 7045 at the moment...
<somlo>
I could probably work on understanding prjxray itself, and see if there's something that could be done about virtex7 (I have access to a vc707 board, but I don't think physical hardware is actually needed for prjxray, just ability to run the vendor toolchain *a lot* :)
<Adrien[m]>
Either this chip was too large (233k LUT6) to make it a priority for bitstream documentation.
<somlo>
so, create a vm template based on some ancient debian/ubuntu/fedora, hack it to work with 2017.2, and launch as many instances as the underlying hardware will support :)
<somlo>
for a prjxray n00b, it might be the path of least resistance (as compared to "dig in and fix issue #14 the Right Way (tm)") :D
<juri_>
where can i even grab 2017.2 now? looks like all links point into login.amd.com
<somlo>
there's mention of some archive in one of the replies (but maybe you already tried that and got the dead login page ?)
<Adrien[m]>
The only issue about versions beyond 2017.2 seems to be vivado refusing to handle design that places LUT6_2 immadiately followed by a MUXF in the same slice. Supposedly this would have no practical usefulness. So some fuzzers fail. But I'm fairly convinced that just skipping potentially problematic fuzzer designs would still let the whole fuzzing system document most of the FPGA, if not everything. Just nobody pushed the effort up to porting
<Adrien[m]>
the entire prjxray to any other version.
<Adrien[m]>
Not claiming old FPGAs supported by 2017.2 should be converted to another version of Vivado.
<Adrien[m]>
IMHO having even partially documented bistreams for Virtex-7 and all other Kintex and Artix and Zynq chips is a better beginning than having no support at all.
<Adrien[m]>
Take care a vivado 2023 install is 110-180GB of disk space depending on what is selected...
<somlo>
juri_: presumably if you had (or created) an AMD/Xillinx account, you could then grab a copy? I'll have to try that myself...
whitequark[cis] has joined #yosys
<whitequark[cis]>
vivado always required a xilinx account to download, for export control reasons
<whitequark[cis]>
i recall getting one in 2017, i think
<Adrien[m]>
somlo: I added links to your web page and FOSDEM presentation to related works in my little repo ;)
<somlo>
Adrien[m]: Thanks! Hope it ends up being useful :)
<somlo>
should definitely be more useful if it can run on a larger/faster FPGA than Lattice ecp5
<Adrien[m]>
To give you figures, genarating a bitstream for an AES core (something like 1000-2000 LUT6 ?) takes around half an hours for my intern. When he's done his repo will be available public too with all details, not sure when, if you are interested I can take a few more notes of our discussions.
<Adrien[m]>
There are many technology details in your works that I want to have a look at, the Rocket chip (or CVA6 more common nearby me), Fedora, soft cores, Litex, ...
<Adrien[m]>
(disclaimer : with baby to take care of and a part-time nurse, only part-time work time remains available for me ':) )
cr1901_ has quit [Read error: Connection reset by peer]