<whitequark[cis]>
Wanda: do you want commit notifications here?
<Wanda[cis]>
surre
<mupuf>
it's too quiet 🤣
<Wanda[cis]>
well I've been busy with unnamed
<Wanda[cis]>
and traveling
<Wanda[cis]>
mmm
<Wanda[cis]>
I missed sitting in front of this desktop
<Wanda[cis]>
holy crap those are nice screens
Micko[m] has joined #prjcombine
<Micko[m]>
maybe a bit out of context question, but is prjbureau planned to be ported to prjcombine ?
<Wanda[cis]>
maybe, maybe not
<Wanda[cis]>
there's not that much benefit for a CPLD project
<Wanda[cis]>
Cat once mentioned considering that
<Wanda[cis]>
tbh I should start with porting my own CPLD work to prjcombine
<Wanda[cis]>
speaking of which. the plan.
<Micko[m]>
my backlog and list of weird architectures reversed is growing and would like to help, but not sure I'll have time soon, but one potential good target for unnamed could be GALs due to their size, and generaly not good tools for support
<Wanda[cis]>
I'm going to put prjunnamed mostly on hold for a bit, and spend the next few weeks getting prjcombine in shape for actually being a backend for something
<Wanda[cis]>
this is going to entail a) cleaning up a bunch of stuff I never had time for before, b) actually defining what is the public interface, c) finishing up prjcombine-siliconblue
<Wanda[cis]>
one of the things I'd like to clean up, btw, is the CPLD targets which kind of predate a bunch of common prjcombine structures and are very odd as a result
<Wanda[cis]>
in particular, it annoys me because it makes a few things generic over types that really don't need to be generic
<Wanda[cis]>
Micko[m]: GALs. I was thinking of that.
<Wanda[cis]>
and maybe this will happen at some point when I'm bored
<Wanda[cis]>
but, GALs are an even worse fit for a project like this than CPLDs
<Wanda[cis]>
GALs are basically too simple to really benefit from having the kind of common infrastructure that prjcombine provides
<Micko[m]>
yeah, they are fully documented, no need to reverse anything
<Wanda[cis]>
that too, but that's only part of it
<Wanda[cis]>
so, what common infrastructure does prjcombine provide?
<Wanda[cis]>
the reversing algorithms, but those are not necessary
<Wanda[cis]>
the interconnect database format for FPGAs, which is completely useless for CPLDs and GALs
<Wanda[cis]>
the tile-based bitstream description format, which ... is somewhat helpful for CPLDs because they actually have a significant amount of bits in the macrocell control areas, and non-uniform routing between function blocks, but also somewhat not helpful
<Wanda[cis]>
for GALs, completely not helpful because the routing is fully regular and there's like 4 kinds of per-MC and global options tops
<Wanda[cis]>
so the only thing that's left is the common database format for the actual list of devices and pin-pad package maps
<Wanda[cis]>
which, btw, isn't really common; that code is actually per-target in prjcombine, because I found it a little too hard to make things generic at the very top level of the database
<Wanda[cis]>
(now that I want to have it as a prjunnamed backend, I'll have another go at it, and probably get something trait-based... we'll see)
<Micko[m]>
would keep an eye on progress there, mostly interested how to add new architecture
<Wanda[cis]>
what would you like to do?
<Micko[m]>
have a few half backed things like Anlogic, Efinix, AGM and aware of some things related to MachXO2/3 and some other Lattice Diamond targets
<Wanda[cis]>
correct.
<mupuf>
Wanda[cis]: that was not a dig, it was clear what was going on: you two cat girls got together to kickstart prjunnamed, and reverse engineering would not have made too much sense focusing on!
<Wanda[cis]>
for Lattice Diamond, I want to make my own prjcombine-hammer backend and do a full reversing run like for ISE
<Wanda[cis]>
this will cover everything starting from ecp/xp/machxo and before nexus
<Micko[m]>
Great
<Wanda[cis]>
anlogic and efinix... I never really had the time to investigate these toolchains and how to best handle them
<Wanda[cis]>
if you can get any routing information out of them, my guess is they should follow the same approach as SiliconBlue
<Wanda[cis]>
(that's also what I want to use for Quartus and Gowin)
<Micko[m]>
Anlogic is also using ncl files, so very similar to diamond on that part at least. have decoded internal database, but that can just help (even without actually understanding some data there)
<Wanda[cis]>
if not, things get very tricky; I spent some amount of time figuring out how to completely blackbox a toolchain, and there's some half-baked ideas
<Wanda[cis]>
ah, ncl files
<Wanda[cis]>
is it going to be another target that'd be best covered by Lattice-specific code?
<Wanda[cis]>
like, to be clear, I fully intend to just have Gw1n as a subkind of the Lattice device structure; handled in prjunnamed-lattice like any other
<Wanda[cis]>
the fact that Lattice didn't authorize them being made is immaterial; they are Lattice devices
<Micko[m]>
it's a look a like, but not sure if complete approach can be reused but at least part of infrastructure can
<Wanda[cis]>
mhm.
<Wanda[cis]>
I'm mostly motivated by the BRAM and logic tile being practically identical to ECP3 by the way, which is the stuff that synthesis actually cares about
<Wanda[cis]>
whatever custom hard IP they stuffed on top is immaterial
<Micko[m]>
in that branch I had it at least get tilemap for all, there are some duplicated names/locations for couple of architectures, but was long time ago so not remembering all the details
<Micko[m]>
pushed the work there so, if it helps to somebody at least it is not all lost :)
<Micko[m]>
but yeah please do follow your own plans, and I will see to follow the work and try to understand details (to be honest did not look at the code for a long long time)
<Wanda[cis]>
mhm
<Wanda[cis]>
so I suppose one of the crucial parts of the next month's work will be actually documenting the prjcombine database format
<Wanda[cis]>
with the major non-obvious part being the interconnect database
<Wanda[cis]>
it commits a fair amount of sins in order to be able to heavily deduplicate routing across the whole family of FPGAs
<Wanda[cis]>
ever since I designed this thing I've been wondering whether a P&R tool can make efficient use of it without having to expand it to the full graph
<Wanda[cis]>
I guess we'll find out later this year
<Micko[m]>
would you mind me trying to use it in nextpnr for SiliconBlue ?
<Micko[m]>
more like experiment for both projects
<Wanda[cis]>
huh.
<Wanda[cis]>
that's a weird proposal
<Wanda[cis]>
how would nextpnr benefit from a new siliconblue backend?
<Micko[m]>
not any benefit on that side, but more me understanding details for prjcombine API and testing out data. It is small arch, not too many strange things there and not expectations for anyone following progress from outside
<Wanda[cis]>
prjcombine-siliconblue is not ready to be used as a P&R backend. and the second it becomes ready, we start work on prjunnamed P&R stage
<Wanda[cis]>
(if anything, most Xilinx backends are more P&R-ready than `prjcombine-siliconblue` right now, though they lack timing data still)
<Micko[m]>
only trouble with xilinx is then everyone would start tryining it and pushing for some progress :)
<Micko[m]>
s/tryining/trying/
<Wanda[cis]>
... yeahhh this is also why we're trying to avoid it for a while
<Wanda[cis]>
(and why the first xilinx backend wired into unnamed is slated to be prjcombine-virtex2)
<Wanda[cis]>
it won't save us for that long, after all we do want to develop P&R that's capable of bearing UltraScale-grade load, and there's only one way to test it
<Wanda[cis]>
but at least most of the infra should be in place by then
<Micko[m]>
every attention delay is welcome in this case
<Wanda[cis]>
true
Maja_ has joined #prjcombine
<Wanda[cis]>
hi two meis
<Maja_>
told you i'm plural
<Wanda[cis]>
of course
<Wanda[cis]>
anyway
<Wanda[cis]>
mei just made a very good suggestion
<Wanda[cis]>
which is that we should write down the roadmap somewhere
<Wanda[cis]>
... which I suppose applies to prjunnamed more so than prjcombine, but still
<Wanda[cis]>
I suppose it may also be time to stop using nvim as issue tracker
<Wanda[cis]>
or, in prjunnamed's case, a shared google spreadsheet
* mupuf
would be very interested in a public roadmap as a GitHub issue
<Wanda[cis]>
I have just added two
<Wanda[cis]>
(issues #1 + #2 is basically the roadmap for the next month, possibly excluding the hardware testing part of #2 because I uhhhh don't actually have any SiliconBlue devboards right now)
<Wanda[cis]>
(I do have a few Glasgows, but that's not really a good device to use as a generic devboard, and especially not good for the kind of work I need to do here)
<Wanda[cis]>
(okay I also have a fomu but it kind of stands out as the most useless ice40 devboard ever made)
<Wanda[cis]>
* ever made, so I shall not speak of it again)
<mupuf>
hehe, yeah, the fomu has like 4 gpios and that's it
<mupuf>
i've soldered some pins to them
<mupuf>
then got myself an netv2 and old3s
<mupuf>
ulx3s*
<mupuf>
11
<Wanda[cis]>
so I'm actually not sure how best to write down the full roadmap
<Wanda[cis]>
prjcombine doesn't have versioned releases (and likely never will, any versions and releases are going to be per-crate), so I don't really think the usual milestone stuff would apply
<whitequark[cis]>
put it in a wiki?
<Wanda[cis]>
I'm not really using a wiki yet, and I'm not convinced I should start it
<Wanda[cis]>
it adds one more place you need to look
<whitequark[cis]>
put it in a .md file in the source?
<Wanda[cis]>
yeah, quite possibly
<Wanda[cis]>
or maybe just stuff it to the readme directly
<Wanda[cis]>
hm, better not, if it's any good it'll become long
leocassarani[m] has joined #prjcombine
<leocassarani[m]>
I thought that's what the issues tagged "Feature" were for — as in, a roadmap
<leocassarani[m]>
Oh sorry, unnamed vs combine?
<Wanda[cis]>
issues are just that; reminders of things that need to be done at some point
<Wanda[cis]>
a roadmap is a vision for where the project goes next; you can think of it as a set of priorities overlaid across the underyling feature-tagged issues, but that's a little reductive