Friday, 2019-03-15

*** tpb has joined #symbiflow00:00
*** _whitelogger has quit IRC02:58
*** _whitelogger has joined #symbiflow03:01
*** OmniMancer has joined #symbiflow06:12
*** Bertl is now known as Bertl_zZ06:18
*** lopsided98 has quit IRC07:06
*** lopsided98 has joined #symbiflow07:08
*** kgugala has quit IRC08:18
*** citypw has joined #symbiflow10:05
duck2so i left `make buttons_basys3_bin` running overnight and woke up to frozen laptop and some corrupted files10:08
sf-slack1<kgugala> it may consume a lot of  RAM10:09
sf-slack1<kgugala> how much memory do you have on your laptop?10:09
duck2i think mem + swap were full so computer just went derp. how much RAM do i need to build the archs?10:09
duck24gb :(10:10
sf-slack1<kgugala> memory consumption depends on the project10:10
sf-slack1<kgugala> but 4gb is way to low10:11
sf-slack1<kgugala> we will optimize the flow to consume less memory10:11
sf-slack1<kgugala> it's on the TODO list10:11
sf-slack1<kgugala> duck2: do you want yo take a look on that?10:12
duck2i 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 oom10:21
duck2i wonder if it tries to load a huge file into memory10:21
duck2kgugala: 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 with pypy and it was ok i think10:26
sf-slack1<kgugala> vpr creates a lot of data structures in RAM10:27
sf-slack1<kgugala> this could be the reason why your laptop cannot handle it10:27
duck2i 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 :D10:32
sf-slack1<kgugala> :slightly_smiling_face:10:33
daveshahThe PnR part shouldn't be that memory intensive10:37
daveshahnextpnr can do PnR for an 85k logic element ECP5 in ~200MB10:37
daveshahAdmittedly the database build is quite memory intensive, but that's a one-off operation10:37
duck2i 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 interesting10:42
daveshahI suspect that's more bad luck that anything VPR specific10:43
daveshahPerhaps because it was doing disk operations at the same time as running out of RAM10:43
duck2looks like it. i really shouldn't have run it twice i think. will fix debian and give it another shot10:51
litghostduck2: 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 now13:32
*** Bertl_zZ is now known as Bertl14:23
*** citypw has quit IRC14:25
*** citypw has joined #symbiflow14:25
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 changes15:20
*** OmniMancer has quit IRC15:22
litghostacomodi: Awesome, what ended up changing?15:32
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, in15:37
sf-slack1the end LUTs mode will be selected)15:37
litghostacomodi: Did you test packing a DRAM with a LUT with the new code?15:47
litghostacomodi: Otherwise sounds good15:47
litghostacomodi: 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 feature15:48
sf-slack1<acomodi> litghost: Ok, so it will be necessary to use a small test architecture instead of a whole a7 right?15:50
litghostacomodi: Ya, that's the idea.  Hopefully your mind is in this space enough to be able to create a reduced test case15:50
litghostacomodi: 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 changes15:51
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:52
litghostacomodi: Later.  You should be able to leverage the existing pack resource tests we have in xc7/tests/dram15:53
litghostacomodi: Just add a new test case15:53
sf-slack1<acomodi> litghost: All right15:54
*** GuzTech has quit IRC17:05
duck2hello 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 memory17:07
duck2 usage? so that i have somewhere to start17:07
litghostduck2: VPR currently loads the entire XML rr graph into memory, which is relatively wasteful:
tpbTitle: vtr-verilog-to-routing/rr_graph_reader.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at
litghostduck2: Switching to an incremental reader will likely save some memory17:09
litghostI believe to was significant17:09
mithroduck2: Plenty of room for memory optimization, but it is easier to optimize when you have a working solution - so correctness has been the priority18:36
*** Bertl is now known as Bertl_oO21:03

Generated by 2.13.1 by Marius Gedminas - find it at!