<whitequark>
how do I explain to people that the reason some of the things in nmigen are internal is because they have objectively bad design and should just not be used period?
<whitequark>
assertFormal is garbage. it barely serves the purpose it has in the nMigen testsuite itself. completely unacceptable in external code
<zignig_>
whitequark: just put a "not for external code" warning in the source. :)
<whitequark>
i... guess that could work
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #nmigen
<zignig_>
whitequark: oh and cxxrtl is getting more awesome, keep up the good work.
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
Asu has joined #nmigen
smkz has quit [Ping timeout: 256 seconds]
pdp7 has quit [*.net *.split]
Cynthia has quit [*.net *.split]
daveshah has quit [*.net *.split]
levi_ has quit [*.net *.split]
anuejn_ has quit [*.net *.split]
electronic_eel has quit [*.net *.split]
_whitelogger has joined #nmigen
jeanthom has joined #nmigen
* zignig_
dredges c++ out of deep core memory, 10+ solar cycles.
jeanthom has quit [Ping timeout: 256 seconds]
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
Asu has quit [Quit: Konversation terminated!]
<Lofty>
I'm tempted to try some nMigen metaprogramming to improve my chess move generator
<Lofty>
e.g. being able to do x.op() instead of op(x)
<Lofty>
Mostly to learn how to do such a thing if I need to
<Lofty>
Maybe I can just subclass Value to do what I want
Asu has joined #nmigen
<Sarayan>
Hmmm, algorithmic question
<Sarayan>
is have a firmware of 56M bits. Next to that, I have 2.2M lists of bit numbers. I want to know which lists have bits set (and which entry in the list), knowing that I have to do it only once for a firmware. About 16M bits are actually used
<Lofty>
Algorithmic answer
<Sarayan>
I wonder if for simple cache/precalculation time reasons the best way isn't just to run the lists linearly
<Lofty>
Uuuh
<Lofty>
Is this Mistral stuff?
<Sarayan>
yup
<Lofty>
So you want to find which bits correspond to a feature, right?
<Sarayan>
it's routing actually, but yes
<Sarayan>
rebuild the routes from the firmware
<Lofty>
Treat it as vertical binary strings
<Sarayan>
?
<Lofty>
e.g. bit 0 is bit N of bitstream 0, bit 1 is bit N of bitstream 1, bit 2 is bit N of bitstream 2
<Sarayan>
???
<Lofty>
May I explain?
<Sarayan>
sure
<Lofty>
If you have a feature that is on in 0, off in 1, and on in 2, you can search for a value of 101 in the bitstream
<Sarayan>
Need to prepare some stuff, I'll read your explanation when I'm back
<Lofty>
The explanation isn't that long
<Sarayan>
ah that, I know that, and no, that's not the problem
<Lofty>
Well, okay
<Lofty>
You can just construct RCF files that get the bits you want
<Sarayan>
I have the bits numbers
<Sarayan>
there are 2.2M routing elements, with a list of bit numbers associated to each
<Sarayan>
I want to know for a given firmware which elements have bits set and which ones
<Lofty>
If you know the bit locations, just traverse the bitstream I suppose
<Sarayan>
Yeah, that's where I suspect traversing the lists is a better idea
<Sarayan>
because I'd need to do some kind of lookup structure if I traverse the bitstream
<Lofty>
Have you noticed a pattern to the bits yet, Sarayan?
<Sarayan>
if you delta-encode them as "first value + delta", there are only 24143 different lists
<Sarayan>
it compresses rather well :-)
<whitequark>
Lofty: you can't subclass Value. UserValue exists for that
<Lofty>
I abandoned the idea for a different reason, but also that
<whitequark>
ack
<Lofty>
Basically I suppose I wanted to do the Python equivalent of implementing Rust traits on someone else's code to extend its functionality
lkcl_ has quit [Ping timeout: 260 seconds]
<whitequark>
yeah, Python doesn't do that
<whitequark>
which is why UserValue exists, except it's flawed, but we can fix that
lkcl_ has joined #nmigen
<tpw_rules>
what's the most efficient way to OR together e.g. 64 8 bit values? where "efficiency" = least logic > highest fmax > lowest latency
jeanthom has joined #nmigen
<tpw_rules>
so far i'm just doing a tree kind of thing where i OR all the inputs in groups of 4, then latch them, then repeat for the outputs of before, until i have 1 final output
Asu has quit [Quit: Konversation terminated!]
lkcl_ has quit [Read error: Connection reset by peer]
<whitequark>
for OR, shouldn't the synthesizer turn anything into the optimal pattern?
<whitequark>
the main problem you can hit is actually an expression that's too recursive for the frontend (either nmigen itself, or yosys, or ...) but i don't think it affects efficiency of synthesis
<whitequark>
if you have data indicating the opposite, please file an issue because it needs invesigation and fixin
<whitequark>
also, wait, *latch* them?
<tpw_rules>
so it's like a 3 stage deal
<whitequark>
ohhh
<whitequark>
you're basically retiming it manually, right?
<tpw_rules>
yeah
<whitequark>
oh ok then what i said was irrelevant, sorry
<tpw_rules>
i'm not sure if it needs to be retimed in the first place. i just did it cause it sounded good but i need to expand it a lot and i'm rather tight on resources
<whitequark>
and your approach is afaik the best possible
<whitequark>
if the number of stages is irrelevant
<whitequark>
if you want to minimize the number of stages you should see the longest logic chain elsewhere in your circuit and tailor to that
<tpw_rules>
yeah i don't care about latency at all
<whitequark>
yep sounds good then, FPGAs love registers
<Lofty>
I've been staring at the Intel Hyperflex manual
<Lofty>
They really, *really* love registers
<whitequark>
weird flex but okay
<whitequark>
:p
<Lofty>
weird hyperflex but okay
<tpw_rules>
so now that i think about it, if each OR operation is one LUT4, there's literally no disadvantage to reducing the number of registers
<whitequark>
doesn't 7-series have registers in fabric too?
<tpw_rules>
or advantage rather
<whitequark>
tpw_rules: exactly
<Lofty>
I don't know, it's a question for daveshah I think
<whitequark>
on a LUTFF architecture anyway
<daveshah>
The only registers in the fabric Xilinx have are for crossing SLR partitions
<whitequark>
ah
<daveshah>
I don't know if xc7 has them. I know they are broken in UltraScale (hold time issue or something) but definitely used sometimes for UltraScale+
<Lofty>
I'm kinda curious how nextpnr would do there to be honest
<daveshah>
I'm working on that atm
<daveshah>
The placer algorithm I am looking at has some hypergraph-based pre-placement partitioning that I plan to hack into an SLR partitioner
lkcl_ has joined #nmigen
<mwk>
daveshah: no SLR crossing regs in xc7
jeanthom has quit [Ping timeout: 272 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 272 seconds]
lkcl_ has quit [Read error: Connection reset by peer]
SpaceCoaster has quit [*.net *.split]
felix__ has quit [*.net *.split]
felix__ has joined #nmigen
SpaceCoaster has joined #nmigen
mwk has quit [*.net *.split]
esden has quit [*.net *.split]
esden has joined #nmigen
mwk has joined #nmigen
emily has quit [*.net *.split]
futarisIRCcloud has quit [*.net *.split]
sorear has quit [*.net *.split]
miek has quit [*.net *.split]
sorear has joined #nmigen
miek has joined #nmigen
futarisIRCcloud has joined #nmigen
nengel has quit [*.net *.split]
MadHacke1 has quit [*.net *.split]
proteus-guy has quit [*.net *.split]
vup has quit [*.net *.split]
vup has joined #nmigen
proteus-guy has joined #nmigen
nengel has joined #nmigen
MadHacke1 has joined #nmigen
futarisIRCcloud has quit [Ping timeout: 246 seconds]