whitequark[cis] changed the topic of #prjunnamed to: FPGA toolchain project · rule #0 of prjunnamed: no one should ever burn out building software · https://prjunnamed.org · https://github.com/prjunnamed/prjunnamed · logs: https://libera.irclog.whitequark.org/prjunnamed
eightdot has quit [Ping timeout: 268 seconds]
eightdot has joined #prjunnamed
ydnatag[m] has joined #prjunnamed
<ydnatag[m]> Hello everyone! I'm following this project from day 0 and what you are doing is amazing. I'm following the progress in mastodon, here and github and I'm learning a lot about sw dev, reverse eng (not too much but at least learning how bad vendor tools are) and trying to learn rust to understand the code and maybe contribute in the future. I only have one doubt that maybe you replied previously: what is driving this project? I mean,
<ydnatag[m]> there are some tools like yosys, nextpnr and others that resolve this in one or other way. I'm asking this mainly to understand current tools limitations because I use them everyday.
Wanda[cis] has joined #prjunnamed
<Wanda[cis]> there's several interconnected motivations in place
<Wanda[cis]> you mentioned reverse engineering, so I'm going to assume you're asking about prjcombine as well
<Wanda[cis]> broadly speaking: prjunnamed is an answer to core design flaws in the existing FOSS tools
<Wanda[cis]> the most high-level one being lack of integration
<Wanda[cis]> the other obvious one is having an intermediate representation that makes writing transforms easy
<Wanda[cis]> yosys IR is ... not really fit for purpose, tbh. when writing a yosys pass you're spending more time fighting with its idiosyncracies than doing whatever the pass is for.
<Wanda[cis]> on the integration angle... yosys offloads most of its logic optimization and LUT mapping work to abc; this involves translating the whole design to another IR, losing a lot of information in the process, and then translating it back
<Wanda[cis]> this results eg. in loss of all debugging information
<Wanda[cis]> there's also the whole yosys-nextpnr split, which is far less immediately problematic, but we still believe that having integrated synthesis+pnr will allow us to add useful features further down the road that'd be impossible otherwise (mostly resynthesis-type optimizations)
<Wanda[cis]> as for prjcombine: it started out as my small project to reverse Spartan 3 bitstream format. it got .. considerably more ambitious in the meantime.
<Wanda[cis]> the motivation for the xilinx reversing stuff should be obvious (there are no xilinx reversing projects that actually delivered any kind of reasonable results); however, a secondary aim of prjcombine is to create a chip database format that is compact and uniform across FPGA architectures, minimizing the amount of target-specific code in prjunnamed
<ydnatag[m]> thanks for your amazing and complete answer! I think you should add this in the readme of the repo, it would help lot of people like me to understand the differences between the projects and what to expect from prjunnamed and prjcombined.
<ydnatag[m]> Is it already working for any platform?. Let me know if i can contribute at least testing/using it.
<Wanda[cis]> the synthesis part of prjunnamed is already functional on siliconblue devices, though not very good at optimization; P&R is entirely TODO
<Wanda[cis]> (my focus right now is on getting the prjcombine infrastructure in place before starting pnr work)
<Wanda[cis]> in general, the project is not really mature enough yet to be seeking users or publicity
<ydnatag[m]> Ohh. I see. I will continue following the project. I'm really impressed with these both projects! I will be here waiting for the first usable version. :)