azonenberg changed the topic of ##openfpga to: Open source tools for FPGAs, CPLDs, etc. Silicon RE, bitfile RE, synthesis, place-and-route, and JTAG are all on topic. Channel logs:
emeb has quit [Quit: Leaving.]
lain has quit [Quit: brb~]
lain has joined ##openfpga
oeuf has quit [Ping timeout: 265 seconds]
egg has quit [Ping timeout: 268 seconds]
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
egg has joined ##openfpga
oeuf has joined ##openfpga
oeuf has quit [Ping timeout: 272 seconds]
tokomak has joined ##openfpga
egg has quit [Ping timeout: 250 seconds]
oeuf has joined ##openfpga
egg has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
specing_ has joined ##openfpga
specing has quit [Ping timeout: 240 seconds]
specing_ is now known as specing
cr1901 has quit [Ping timeout: 240 seconds]
cr1901 has joined ##openfpga
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined ##openfpga
tokomak has quit [Ping timeout: 240 seconds]
promach[m] has quit [Quit: Bridge terminating on SIGTERM]
promach[m] has joined ##openfpga
whitequark has joined ##openfpga
emilazy has joined ##openfpga
jevinskie[m] has joined ##openfpga
oeuf has quit [Ping timeout: 256 seconds]
egg has quit [Ping timeout: 256 seconds]
oeuf has joined ##openfpga
egg has joined ##openfpga
thaytan has quit [Ping timeout: 258 seconds]
thaytan has joined ##openfpga
emeb has joined ##openfpga
FireFly has quit [Quit: WeeChat 2.0.1]
FireFly has joined ##openfpga
<vup> gatecat: do you have any guidance on how quick the prjtrellis fuzzers are roughtly? (specifically 051-pio_ioconfig)
<gatecat> that one can take a few hours iirc
<gatecat> you can set the TRELLIS_JOBS env var to something higher than the default of 4 if you have plenty of cores and RAM
<vup> I tried that, but it doesn't seem to really help
<gatecat> ah that fuzzer might not support the parallelism
<vup> Yeah seems like it
specing_ has joined ##openfpga
specing has quit [Ping timeout: 252 seconds]
specing_ is now known as specing
emeb_mac has joined ##openfpga
<cr1901> azonenberg: Looks like you'll get to donate to RPI after all if you wish:
<azonenberg> Lol
<azonenberg> you're the third one to tell me
<azonenberg> Honestly, it feels like an occasion worth celebrating
<cr1901> From what I can gather: She is highly accomplished, but used her power to really screw students over
<vup> gatecat: would this be a problem with my additions to the fuzzer or something else: ?
<azonenberg> Correct
<azonenberg> cr1901: she's a brilliant physicist and generally smart person, but also has a bit of a god complex
<azonenberg> a shame the first black woman to get a PhD from MIT had to be such an asshole lol
<gatecat> vup: I suspect this was a regression from the move from boost::python to pybind11
<vup> hmm yeah, just `python3 -c 'import pytrellis; pytrellis.EnumSettingBits()'` also triggers it
<azonenberg> She had everything she needed to make RPI a great place to be a student
<azonenberg> then she went dictator instead
<cr1901> azonenberg: Yes indeed. And almost certainly ppl use that as a shield an excuse to shit on an accomplished black woman just because she's an accomplished black woman. As opposed to "she pissed a lot of ppl off"
<kc8apf> Finally starting to catalog my programmable logic museum collection:
<vup> gatecat: Ok I think I know how to fix this, but I there there are a bunch more constructors missing. Is there a easier way to test this than just running all the fuzzers?
<gatecat> vup: unfortunately, probably not, but if it looks reasonable then it's probably OK in this case
<vup> well I was more looking for a way to check all the fuzzer actually work after that
<gatecat> at least seeing if they start is probably a good initial test, even if you don't let them run to completion
<gatecat> (which is likely to be a multi day process)
<vup> the problems unfortunately seem to mostly occur in the end
<vup> (atleast the exception I linked above only happend after ~2 hours)
<cr1901> There's a nontrivial chance that your errors were caused by changes I made to accomodate MachXO2, and I only fixed the fuzzers as needed
<cr1901> I didn't really worry about touching fuzzers I already ran because gatecat and I accepted at the time that the full flow from empty dbs to filled dbs was already broken/needed to be fixed.
<vup> Interesting, I don't think the MachXO2 changes were the cause of this issue
<cr1901> Well, that's why I didn't put a concrete bound on the odds its my fault :)
<vup> :)
<vup> gatecat: is it normal that running a unchanged fuzzer actually produces changes to the database? Running 001-plc2_routing produces this diff:
<gatecat> yes, there's a fixup pass at the end that folds these back into the muxes
<vup> makes sense, thank you :)
<cr1901> The fuzzers treat "no change to bitstream" as a fixed connection. Sometimes those "no changed to bitstream" connections are default outputs for muxes
<cr1901> So dbfixup handles that
<cr1901> Tho without opening up EPIC right now, ".fixed_conn F0 F0_SLICE" seems like a genuine fixed connection?
<vup> are there any more interdependencies between the fuzzers (when starting from the current db), or can I just run some random fuzzers and then db_fixup in the end?
<cr1901> I don't remember running into problems doing that
<vup> great
<gatecat> the only other thing is that the "copy" fuzzers need to be run after fuzzers producing the data that they copy between tile types
<vup> I see
emeb has quit [Quit: Leaving.]