ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
Asuu has quit [Remote host closed the connection]
_whitelogger has joined #nmigen
* whitequark sighs
<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]
futarisIRCcloud has joined #nmigen
emily has joined #nmigen
lkcl has joined #nmigen