<Wanda[cis]>
wrt P&R, another thing I keep wondering about is whether I'll end up writing `prjcombine-router` even before we get to `prjunnamed-pnr`
<Wanda[cis]>
as in, I'm going to need a hack-grade router for test bitstreams while doing in-hardware verification, and it may not make sense to go through prjunnamed (the testcases will be written directly in terms of bitstream fields to set, and the crimes I'll need may not even be representable in the IR); in any case it'd be a really weird dependency cycle to untangle
<Wanda[cis]>
I can manually place and lower the logic stuff I need without much suffering, but manual routing is not something I recommend doing ever, it was already annoying when messing with CPLDs and FPGAs are so much worse
<Wanda[cis]>
so, I think it's time to tackle the BelId refactor
<Wanda[cis]>
right now the bels in an FPGA are identified by a (DieId, ColId, RowId, LayerId, BelId) tuple
<Wanda[cis]>
with LayerId identifying which of the "node"s covering a given coordinate a bel is in, and BelId being essentially an index into the list of bels in a given NodeKind
<Wanda[cis]>
this is ridiculously unwieldy because, in practice, you have to obtain such coordinates by looking things up via (DieId, ColId, RowId, bel_slot: String) and going through all the bels of all nodes at that position to find the right one
<Wanda[cis]>
I'd propose storing a list of all "bel slots" in the interconnect database, identifying bels by `(DieId, ColId, RowId, BelSlotId)` coordinates, and having the `bels` field of a `NodeKind` be a `BTreeMap<BelSlotId, BelInfo>` instead of a vector
<Wanda[cis]>
and the (DieId, ColId, RowId, BelSlotId) tuple would become the thing that the placer would associate with every target cell
<Wanda[cis]>
for siliconblue, we'd have "bel slots" of: `LC[0-7]`, `IO[01]`, `BRAM`, `PLL`, `WARMBOOT`, `DSP`, `SPI`, `I2C`, ....; you'd look up the `BelSlotId` (which is just a u16) by the slot name, and then use it for all your P&R needs
<Wanda[cis]>
hm.
<Wanda[cis]>
there's an impedance mismatch here between what I want to store in the database and what will be needed for P&R
<Wanda[cis]>
for Xilinx LUT6 CLB, I currently have the bel slots of `SLICE0` and `SLICE1`; a P&R tool would likely want slots of `SLICE[01].LUT[0-3]` for placing LUTs and LUT paraphenalia, and even something like `SLICE[01].LUT[0-3].FF[01]` for placing FFs
<Wanda[cis]>
... actually SLICE[01].LUT[0-3].LUT[56] for LUTs because you can actually pack two LUTs per LUT.
<Wanda[cis]>
I thiiiink `prjunnamed-pnr` could just clone and extend the bel slot list from the database with whatever sub-slots it needs for P&R purposes?
<Wanda[cis]>
it certainly makes no sense to store bel pin information in the database in terms of the sub-bels, so I do want the full SLICE[01] as bel slots
<whitequark[cis]>
right
<whitequark[cis]>
are all the *Id types just newtypes over u32?
<Wanda[cis]>
u16 or u32
<Wanda[cis]>
but it's somewhat more complex
<Wanda[cis]>
it's actually a weird newtype over NonZeroU16/32 that remaps 0.. to 1.., so that the type ends up with a niche
<whitequark[cis]>
hm
<whitequark[cis]>
yeah
<Wanda[cis]>
I was inspired by cranelift-entity when writing this thing
<Wanda[cis]>
it is responsible for some of the weirdness
<whitequark[cis]>
I was thinking about whether this is the key type we want but I can't find a counterargument to it
<Wanda[cis]>
I actually want to try redesigning this thing a bit because the macros involved have already been a headache on several occasions
<Wanda[cis]>
mei has suggested either using https://crates.io/crates/sign-bound or borrowing its niche hack, so that a) the annoying +1/-1 on every operation is not needed, b) we get more niche
<whitequark[cis]>
fascinating
<whitequark[cis]>
dear god have you seen the source.
<Wanda[cis]>
yes
<Wanda[cis]>
lovely, isn't it
<whitequark[cis]>
that's... sure something
<whitequark[cis]>
I will take inspiration for my future macro_rules crimes
<Wanda[cis]>
okay now I am concerned
<whitequark[cis]>
:3
<Wanda[cis]>
... another fucking refactoring attempt killed by const traits being unstable
<mupuf>
i'm surprised not to see you mentioned there
<mupuf>
I'll read it this weekend
<Wanda[cis]>
... it's not very competently written
<Wanda[cis]>
actually the author doesn't appear to have a clue what the fuck they are talking about at all
<Wanda[cis]>
"PGRAPH is named after the concept of scene graph, which it implements" what the fuck have you actually seen the hardware
<mupuf>
loool
<Wanda[cis]>
this is the kind of stuff you'd end up with if you stuffed all of envytools or whatever leaked docs you could find into chatgpt and asked it how the GPU works
<Wanda[cis]>
to be fair, the nvidia object/method model is incredibly confusing until you finally understand how it works, or more specifically, understand that it's a complete and total lie