<Lofty>
As you can see, most of this patch is just mechanically translating hard-coded LAB to is_mlab ? MLAB : LAB
<Lofty>
And if the input routing is the same, you would expect this to work
<Lofty>
But it doesn't
<Sarayan>
interesting
<Lofty>
I checked what Quartus does in this situation and it looks like the relevant config bits are the same
<Lofty>
So I'm wondering if the fixed routing metal is different
<Sarayan>
I know there are differences on the carry bypass network
<Lofty>
Oh yeah, carries are quite fucked
<Sarayan>
but I didn't see anything otherwise
<Lofty>
But even individual LUTs are different
<Lofty>
(I suppose an alternative option is that the LUT ordering is different for MLAB?)
<Sarayan>
it shouldn't be, but....
<Lofty>
Should I file another bug? :p
<Sarayan>
it's a little vague at this point :-)
<Lofty>
I'm just wondering how you'd design a bitstream to check the ordering of bits
<Lofty>
We know that the LAB ordering is right at least
<Lofty>
So there's that
<Sarayan>
I have some hope to show you and gatecat somehting fun and horrible at the same time in the next days... but let's make it a surprise (if it works out :-)
<Sarayan>
there's some massive weirdness w.r.t signal inversions
<gatecat>
in the LAB?
<Sarayan>
tbh, every inverter in the schematics may or may not be correct, and it's the same for a lack of inverter
<Sarayan>
honestly, everywhere
<gatecat>
at least for regular LABs, it seems like LUT inputs and outputs are always inverted
<gatecat>
for MLABs the problem is more than just inversion for sure, as I'm seeing things stuck rather than just always producing the opposite value
<Sarayan>
if you have inverted inputs you can end up stuck because you're not hitting the right part of the LUT data
<Sarayan>
if you don't saturate the lut inputs
<gatecat>
nextpnr treats unused inputs as 'don't care' when calculating mask, so that won't matter
<gatecat>
and based on a simple test with the not gate as described above, it's definitely more likely to be a routing issue as Lofty says rather than an inversion issue
<gatecat>
one thought is that the MODE switchbox is different for MLABs
<Sarayan>
let's say you do an inverter, that would be a lut of 10
<Sarayan>
but if it's a lut3, it's 10xxxxxx, say 10111111
<Sarayan>
but if somehow inputs 1,2 are 1, then you end up stuck with '1'
<gatecat>
except nextpnr treats those inputs as don't care
<gatecat>
so it would write 10101010....
<Sarayan>
ahhhh
<Sarayan>
ok, I get you now
<gatecat>
so yeah, it's not just an inversion issue
<gatecat>
I think there are three possible differences - LUT bits are a different way round, LUT inputs are swapped, or the MODE box works differently
<Sarayan>
oh, another kinky thing, I have looked at the 64 bits -> 6 luts bit repartition on LAB only
<Sarayan>
and given it's the ram too, they may have found useful to move them around
<Lofty>
gatecat: distinguishing 3 should be easy, but 1/2 seems trickier
<gatecat>
mm, that'd definitely cause this kind of funkiness
<Sarayan>
I haven't found where that relationship is done in the quartus code, so it's trial and error all the way
<Sarayan>
the inner blocks internals are very opaque in fact, they don't appear in the routing graph
<gatecat>
yeah
<gatecat>
they might be defined more as code than data in Quartus
<Sarayan>
that's what I think too
<Sarayan>
that made building the schematic rather interesting :-)
<Sarayan>
not at all surprised you find some mistakes
<gatecat>
yeah, don't worry, it's certainly expected at this stage
<Sarayan>
also, sclr/sdata/enable stuff in the common part of LABs is rather unclear, so as you noticed there's more exploring to do to be sure of what's going on
<gatecat>
mm
<Sarayan>
there's been some hopeful thinking in drawing the schematic :-)
<gatecat>
can I ask, are the names of bits like EN0_SEL directly from Quartus?
<Sarayan>
mostly
<gatecat>
mm, weird that EN0_SEL actually controls the source of SCLR
<gatecat>
afaics
<Sarayan>
I simplified some
<Sarayan>
there's a weird mess between sclr, sdata and enable 0
<gatecat>
yeah
<Sarayan>
even the documentation is rather strange
<gatecat>
the docs don't seem to exactly match reality for sure
<Sarayan>
cv_5v2.pdf pdf page 13
<Sarayan>
"labclkena0 or asyncload or labpreset"... wtf?
<gatecat>
is there even asyncload at all?
<Sarayan>
not convinced there is
<Sarayan>
async clear sure
<Lofty>
gatecat: my understanding from VQM dumping is that the compiler errors if you ask it to asynchronously load a variable
<Lofty>
So it just translates it to async clear
<gatecat>
right...
<Sarayan>
but, well, the muxes names are strange
<gatecat>
I'm not sure if that's more or less evil than faking it with LUTs and combinational feedback
<mwk>
gatecat: the story here is that older Cyclone devices did have it
<mwk>
and if you wanted an async clear on *those*, you needed to do it via async load of 0
<gatecat>
amusingly, ECP5 devices have async load support but the vendor tools don't actually support it
<mwk>
so presumably they kept it as "async load" for compatibility, except now it only works with fixed 0 value
<Lofty>
It'll *attempt* to satisfy async load by inverting the flop values, but if you ask it to do something like initialise to one but async load zero, the compiler errors
<Sarayan>
ok,the fun-and-terrifying thing too lesstime than expected
<Sarayan>
you guys around or I'm going to bed and we'll see tomorrow?
<Sarayan>
bedtime then, see ya
<Lofty>
... Drat
<JJJollyjim>
haha
<Lofty>
One day I really hope you remember to ping me because I don't get notifications simply for you posting