00:38 <hackerfoo> I found a new trick: make -j -l`nproc` all_xc7

01:06 <hackerfoo> It wasn't that after all. top_bram_n8 blows up after running for a very long time. It's up to 64GB and still running.

01:08 <litghost> hackerfoo: There is a reason I disabled that code :)

01:09 <hackerfoo> Maybe we can fix it, though.

01:10 <hackerfoo> Now that I know where it fails.

01:10 <litghost> hackerfoo: If you can show that high fanout nets are causing some of our performance issues (e.g. https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1251#issuecomment-571705160 ), then that is helpful

01:10 <tpb> Title: Zybo: Add minitest with Litex/Vex booting Linux by kgugala · Pull Request #1251 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

01:11 <hackerfoo> Okay. I'll do some more profiling.

01:12 <hackerfoo> Wait, isn't that due to missing data?

01:13 <litghost> I don't believe anyone actually tracked down the failure

01:13 <litghost> We just know it takes a very long time

01:17 <hackerfoo> Maybe I should just disable high fanout routing after the overused RR nodes goes under a threshold of 10. That's when it gets into trouble.

01:18 <hackerfoo> It seems to perform better at first, then get stuck.

01:44 <hackerfoo> Okay, now it works great, about 25% faster for top_bram_n8

03:56 <litghost> hackerfoo: Nice

08:30 <sf-slack1> <mkurc> I have a generic question about VPR: Can multiple CHANX (or CHANY) nodes at the same location and with the same length be connected with an edge? Will VPR complain about such rr graph or not?

09:38 <_whitenotifier-3> [symbiflow-arch-defs] acomodi opened issue #1278: Combinatorial Loop after running fasm2bels - https://git.io/JvtDi

15:23 <litghost> mkurc: Maybe? So we've disabled most of VPR's rr graph checking code because we violate some it's assumptions. That being said, the router and placer won't care, as a graph is a graph

15:23 <litghost> mkurc: I make connections of that sort all the time

15:24 <sf-slack1> <mkurc> @litghost Ok, thanks.