<gatecat>
Lofty:/Sarayan: looking at the LAB cell MODE mux, am I right in saying that even though Quartus shows this as four separate MUX3s (give or take), it's actually a kind of permutation mux and there only 16 possible permutations in total?
<Lofty>
gatecat: yes, although we don't know all of those permutations
<gatecat>
right, but we know some aren't possible ?
<Lofty>
The Mistral manual shows the ones we do
<gatecat>
mmm
<Lofty>
It might be easier if we figure out what the remaining permutations are, but we can hazard guesses I think
<gatecat>
yeah, the main thing is that I tell the interchange peeps about this because it's quite a serious omission there (I can probably fudge a solution in nextpnr though)
<Lofty>
I guess Mistral is helping already, despite the slight incompleteness :P
<gatecat>
definitely :)
<Lofty>
Because it's showing an actual example of an ALM rather than a theoretical one :P
peeps[zen] has joined #prjmistral
peepsalot has quit [Ping timeout: 252 seconds]
<Sarayan>
gatecat: More precisely, it's the 16 that quartus can generate. You *can* feed other bit patterns, but you get to keep the magic smoke
<gatecat>
Sarayan: another question, do we know what uses the 'l7' modes? it seems like they might be ignorable for a first proof-of-concept?
<Sarayan>
none of the modes are specifically used in a given situation, it's an optimization issue. l7 is supposed to be lut-with-seven-inputs, which is obviously nonsensical when you have only 64 bits of ram
<Sarayan>
but, well, it's what the manual calls lut-7
<Sarayan>
I wouldn't say I entirely understand it
<Sarayan>
or, to be more precise, the point of it
<Sarayan>
quartus itself rarely generates it, and I haven't seen the loopback-from-ff modes used yet
<gatecat>
so I get the feeling to start with just the basic l5 and l6 modes will be enough ?
<Sarayan>
yes
peeps[zen] is now known as peepsalot
<gatecat>
I'm starting my nextpnr skeleton work at https://github.com/gatecat/nextpnr/tree/cyclonev - atm this is just rebasing on top of master, it'll be a day or two until I suspect there's a useful but feel free to leave comments on commits
<gatecat>
a thought - should we call the arch mistral (or intel-alm like Yosys) instead of cyclonev ? I expect we will want to support other ALM-based devices in the not-so-distant future, too
<Sarayan>
they have differently structures alms
<Sarayan>
strutured
<Sarayan>
structured damnit
<Sarayan>
at least the cyclone 4
<Sarayan>
which is my next on the list once I've finished the cv, and please stop laughing, it's unseemly
<gatecat>
but I think a lot of the nextpnr code can eventually be shared
<gatecat>
I'd rather not have a proliferation of similar arches
<gatecat>
I _think_ at least Cyclone V, Cyclone 10GX and Arria 10 could be shared based on a cursory glance, anyway
mwk has quit [*.net *.split]
mwk has joined #prjmistral
<Lofty>
gatecat: I'm happy with -mistral, personally
<Lofty>
I don't know what we'll do about the LE based chips
<Lofty>
But for now the ALM stuff seems *similar enough*
<Sarayan>
calling the backends different names does not preclude having common code
<Lofty>
Sarayan: yeah, but having common code implies the backend having the same name in nextpnr
<Lofty>
nextpnr-xilinx was nextpnr-rapidwright
<Lofty>
There's nextpnr-fpga_interchange too
<Sarayan>
I thought it was written in C++?
<Lofty>
'it', Sarayan?
<Sarayan>
nextpnr
<Sarayan>
and the backends in particular
<Sarayan>
you can use intermediate inheritance, you can use multiple inheritance, there are a bunch of ways to commonalize functionality while keeping separate bottom classes
<gatecat>
chances are the differences will mainly be data and occasional branches
<gatecat>
so imo keeping it as one backend will be best
<gatecat>
this is my experience of combining xc7 and ultrascale together (which I suspect are no more different than any of the main ALM-based Intel arches)
<gatecat>
a separate backend of the LE-based devices might be reasonable, depending on how many other differences they have
<Sarayan>
gatecat: 10gx looks indeed identical, LAB-wise. Maybe it's possible to fold it under V actually, we'll see in time
<Sarayan>
also, l7 = "extended lut mode"
<Sarayan>
at least according to the 10gx manual
<gatecat>
is routing without configuration bits like carry chains in-scope for mistral, or is that something that nextpnr should create (we've got to create wires for the site-internal routing anyway so it's not a big extra step to create things like that too)
<Sarayan>
I try to keep mistral at describing what's there, and leave virtual stuff to the backend
<gatecat>
understood, that's fine
<gatecat>
is the missing rnode/pnode mapping for clock enables (and possibly some other flop related signals) intentional?
<Sarayan>
I mean, you're probably going to une the routing algorithms to choose and hude the clock muxes, the pll outputs, etc
<Sarayan>
not intntional
<gatecat>
nextpnr still needs a complete routing graph, but it can create that itself in the backend, it's fine
<Sarayan>
there's weirdess I don't yet understand of the common part of the lab
<gatecat>
right, it definitely be useful to have a bit more understanding there for PnR purposes
<gatecat>
that said, for a blinky all we need is a single clock shared between all the FFs in an ALM
<gatecat>
*LAB
<Sarayan>
also, just fyi, rnode type is 8 bits but only goes to 23 iirc. So you can make your own "virtual" types
<gatecat>
shall we say that rnode>=128 is reserved for virtual types?
<gatecat>
that way if mistral ever gains extra types it won't break stuff