10:01 <duck2> so i left `make buttons_basys3_bin` running overnight and woke up to frozen laptop and some corrupted files

10:01 <sf-slack1> <kgugala> it may consume a lot of RAM

10:02 <sf-slack1> <kgugala> how much memory do you have on your laptop?

10:02 <duck2> i think mem + swap were full so computer just went derp. how much RAM do i need to build the archs?

10:02 <duck2> 4gb :(

10:03 <sf-slack1> <kgugala> memory consumption depends on the project

10:03 <sf-slack1> <kgugala> but 4gb is way to low

10:03 <sf-slack1> <kgugala> we will optimize the flow to consume less memory

10:03 <sf-slack1> <kgugala> it's on the TODO list

10:04 <sf-slack1> <kgugala> duck2: do you want yo take a look on that?

10:13 <duck2> i think the .xml files are generated but vpr just makes all things break in seconds, and computer acts weird when rebooted unlike the other times i went oom

10:14 <duck2> i wonder if it tries to load a huge file into memory

10:18 <duck2> kgugala: the arch generation or vpr? arch generation also takes a lot of memory but it passes through when it's the only thing running. i also tried to run prjxray_routing_import.py with pypy and it was ok i think

10:19 <sf-slack1> <kgugala> vpr creates a lot of data structures in RAM

10:20 <sf-slack1> <kgugala> this could be the reason why your laptop cannot handle it

10:24 <duck2> i agree. i can try and profile it while restricting its memory. i know that pnr is a hard operation but it's the first time my laptop is humiliated like this and i'm offended :D

10:25 <sf-slack1> <kgugala> :slightly_smiling_face:

10:29 <daveshah> The PnR part shouldn't be that memory intensive

10:29 <daveshah> nextpnr can do PnR for an 85k logic element ECP5 in ~200MB

10:30 <daveshah> Admittedly the database build is quite memory intensive, but that's a one-off operation

10:34 <duck2> i thought that too, most memory intensive processes fill up my ram and freeze the gui but don't corrupt my /usr/bin on a reboot. this is interesting

10:35 <daveshah> I suspect that's more bad luck that anything VPR specific

10:36 <daveshah> Perhaps because it was doing disk operations at the same time as running out of RAM

10:43 <duck2> looks like it. i really shouldn't have run it twice i think. will fix debian and give it another shot

13:24 <litghost> duck2: Ya, the current XML read method in VPR consumes quiet a bit of RAM. I typically measure ~7 GB. This can be reduced in the future, but is what we have right now

15:13 <sf-slack1> <acomodi> SLICEM modes update: I have finally managed to get slicem carrychain to be packed. I'll clean up and open a PR with WIP as I still need to test that everything else works fine and is not affected by the changes

15:25 <litghost> acomodi: Awesome, what ended up changing?

15:29 <sf-slack1> <acomodi> The way in which `try_intra_lib_nets` computes `router_data`: every time there is a mode conflict between `lib_nets` I set as `illegal` the mode that cannot be selected by one of the childs of a pb (in our case the `SLICEM_MODES` pb_type) and try to route again, this time without considering the `illegal` mode (in our case the illegal mode was `DRAMs` as no {N}_LUT had to actually be set to DRAM mode, therefore, in

15:29 <sf-slack1> the end LUTs mode will be selected)

15:39 <litghost> acomodi: Did you test packing a DRAM with a LUT with the new code?

15:39 <litghost> acomodi: Otherwise sounds good

15:40 <litghost> acomodi: One thing to start working on is a VPR only test case. As we are going to start upstreaming these changes, please add the smallest test case you can manage that tests this feature

15:42 <sf-slack1> <acomodi> litghost: Ok, so it will be necessary to use a small test architecture instead of a whole a7 right?

15:43 <litghost> acomodi: Ya, that's the idea. Hopefully your mind is in this space enough to be able to create a reduced test case

15:44 <litghost> acomodi: I'd put up the PR with the VPR changes when you can so we can start the review cycle, but I do want to start adding test cases for the VPR changes

15:45 <sf-slack1> <acomodi> litghost: Ok, sounds good, I'll start dealing with it then. Anyway, by packing DRAM with LUT you mean running one of the dram codes or having a SLICEM with both LUT and DRAMs?

15:45 <litghost> acomodi: Later. You should be able to leverage the existing pack resource tests we have in xc7/tests/dram

15:45 <litghost> acomodi: Just add a new test case

15:47 <sf-slack1> <acomodi> litghost: All right

17:00 <duck2> hello from fresh install ^^ i plan to do the rest of the builds in a memory-limited container and hope only the container breaks on oom. then i should profile and see if there is a way to make it through except by downloading more ram or throwing swap at it. as for the XML arch generation and VPR, did anyone notice any obvious pain points of memory

17:00 <duck2> usage? so that i have somewhere to start

17:01 <litghost> duck2: VPR currently loads the entire XML rr graph into memory, which is relatively wasteful: https://github.com/SymbiFlow/vtr-verilog-to-routing/blob/master%2Bwip/vpr/src/route/rr_graph_reader.cpp

17:01 <tpb> Title: vtr-verilog-to-routing/rr_graph_reader.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)

17:01 <litghost> duck2: Switching to an incremental reader will likely save some memory

17:02 <litghost> I believe to was significant

18:29 <mithro> duck2: Plenty of room for memory optimization, but it is easier to optimize when you have a working solution - so correctness has been the priority