*** tpb has joined #symbiflow | 00:00 | |
*** citypw has joined #symbiflow | 03:34 | |
*** litghost has quit IRC | 05:35 | |
*** kraiskil has joined #symbiflow | 07:46 | |
nats` | good morning :) | 08:07 |
---|---|---|
*** sorear has quit IRC | 08:11 | |
*** daveshah has quit IRC | 08:12 | |
*** sorear has joined #symbiflow | 08:12 | |
*** daveshah has joined #symbiflow | 08:12 | |
*** Jim_GM0UIN has joined #symbiflow | 08:22 | |
*** JimGM0UIN has quit IRC | 08:24 | |
*** kgugala has joined #symbiflow | 08:29 | |
*** tmichalak has joined #symbiflow | 08:29 | |
*** kraiskil has quit IRC | 08:30 | |
*** acomodi has joined #symbiflow | 08:31 | |
*** mgielda has joined #symbiflow | 08:33 | |
digshadow | hey nats` | 09:03 |
digshadow | Hows it going? | 09:03 |
digshadow | If someone is looking for an entry level prjxray issue, this one is probably easy to fix: https://github.com/SymbiFlow/prjxray/issues/450 | 09:03 |
tpb | Title: Missing *LUT bits in DB · Issue #450 · SymbiFlow/prjxray · GitHub (at github.com) | 09:03 |
nats` | fine short night but good :) | 09:04 |
nats` | I'll continue on fuzzers this evening | 09:04 |
digshadow | cool! | 09:05 |
*** sxpert has quit IRC | 09:54 | |
*** sxpert has joined #symbiflow | 09:54 | |
*** citypw has quit IRC | 10:04 | |
*** Rahix has joined #symbiflow | 10:27 | |
*** Rahix has quit IRC | 10:43 | |
digshadow | noopwafel: https://github.com/SymbiFlow/prjxray/pull/455 | 10:52 |
tpb | Title: addrwidth utility by mcmasterg · Pull Request #455 · SymbiFlow/prjxray · GitHub (at github.com) | 10:52 |
digshadow | FYI those utility functions should be useful for your project | 10:52 |
*** _whitelogger has quit IRC | 11:51 | |
*** _whitelogger has joined #symbiflow | 11:54 | |
*** kgugala has quit IRC | 11:59 | |
*** Rahix has joined #symbiflow | 12:29 | |
*** Jack__ has joined #symbiflow | 14:22 | |
*** kgugala has joined #symbiflow | 14:36 | |
*** tmichalak has quit IRC | 15:24 | |
digshadow | mithro: htmlgen is un-borked | 15:46 |
digshadow | if we can convince ourselves that database is reasonably stable, might be worth it to regenerate | 15:46 |
mithro | \o/ | 15:47 |
digshadow | there are a few outstanding issues (mostly related to db conflicts), but the bulk is working again | 15:47 |
digshadow | mithro: https://photos.app.goo.gl/vw3VpEwwNBJQQsPu6 | 15:49 |
digshadow | top of tree using download latest | 15:50 |
digshadow | the red is from: https://github.com/SymbiFlow/prjxray/issues/456 | 15:53 |
tpb | Title: Different bit names on the same bit position in CLBLL · Issue #456 · SymbiFlow/prjxray · GitHub (at github.com) | 15:53 |
mithro | I'm still waking up | 16:18 |
mithro | But I did start playing with the cloud build stuff that Rick setup a long time ago | 16:19 |
mithro | I also kicked off a manual build last night | 16:24 |
digshadow | cool | 16:27 |
mithro | digshadow: it would be good to do some gardening of the prjxray issue tracker | 16:36 |
*** halosghost has joined #symbiflow | 16:42 | |
halosghost | howdy, folks | 16:42 |
mithro | Hi halosghost | 16:53 |
*** litghost has joined #symbiflow | 16:58 | |
*** Rahix has quit IRC | 17:00 | |
*** acomodi has quit IRC | 17:05 | |
halosghost | :P | 17:10 |
*** halosghost has left #symbiflow | 17:44 | |
nats` | ahhh SLICEL doesn't have the "dynamic write port" that's why it can be used only for combinatorial logic ! | 18:08 |
nats` | oups WW sorry | 18:09 |
*** kgugala has quit IRC | 18:30 | |
*** Jack__ has quit IRC | 18:40 | |
mithro | digshadow: Should 051-imuxlout be working? | 18:49 |
nats` | I think I made my first patch for fuzzers, is there a way to have someone to test the patch and make me some remark about it to know if it's good enough ? | 18:59 |
nats` | https://github.com/SymbiFlow/prjxray/issues/171 | 19:00 |
tpb | Title: All output products should go into "build" dir · Issue #171 · SymbiFlow/prjxray · GitHub (at github.com) | 19:00 |
nats` | I have a problem with the Fuzzers 072 it seems it get stuck but maybe it's just Vivado not outputing message after some point. | 20:08 |
nats` | INFO: [Common 17-14] Message 'Vivado 12-2683' appears 100 times and further instances of the messages will be disabled. Use the Tcl command set_msg_config to change the current settings. | 20:08 |
nats` | mithro digshadow any hint on that ? | 20:08 |
nats` | (vivado still running 100% in top) | 20:09 |
nats` | (eating 11GB of ram now) | 20:25 |
nats` | the process got killed after going over ram limit at 16GB | 20:35 |
litghost | nats: Ya, fuzzer 072 consumes a lot of memory. 16 GB is typically enough, but we typically run it on a 32 GB or 64 GB system. I believe there is an issue for attempting to lower the memory usage. | 20:56 |
nats` | oky feel free to close my issue on the github so | 20:57 |
nats` | I'll buy few ram stick to reach 32 | 20:57 |
litghost | Feel free to take a shot at lowering the memory usage. The tcl code was written in a very simple way, but I believe with more care the peak memory usage could be lowered. This work is likely important when running fuzzer 072 on larger parts. | 20:58 |
nats` | I'll take a look but I think it's way above my knowledge for now :) | 20:59 |
nats` | I'm patching simple things for now | 20:59 |
nats` | anyway in the log vivado is giving some hints apparently | 20:59 |
nats` | WARNING: [Vivado 12-2548] 'get_pips' without an -of_object switch is potentially runtime- and memory-intensive. Please consider supplying an -of_object switch. You can also press CTRL-C from the command prompt or click cancel in the Vivado IDE at any point to interrupt the command. | 20:59 |
litghost | The relevant tcl script is https://github.com/SymbiFlow/prjxray/blob/master/fuzzers/072-ordered_wires/generate.tcl | 21:00 |
tpb | Title: prjxray/generate.tcl at master · SymbiFlow/prjxray · GitHub (at github.com) | 21:00 |
litghost | It's actually pretty small and understandable, but you would need to understand tcl to work on it | 21:00 |
nats` | I understand tcl but not really what it call in vivado batch mode but I'll take a look just after finishing the patch of build process for fuzzer | 21:01 |
nats` | https://github.com/SymbiFlow/prjxray/issues/465 <= can we use this issue to work on that so ? | 21:02 |
tpb | Title: Fuzzer 072-ordered-wires RAM explosion · Issue #465 · SymbiFlow/prjxray · GitHub (at github.com) | 21:02 |
nats` | if you agree I can add a comment with a brief of what we just discussed here | 21:02 |
nats` | mithro, why did you remove the -j to fuzzer ? | 21:10 |
litghost | Ya, that issue is fine | 21:23 |
nats` | uhhmmmm something is boring me https://github.com/SymbiFlow/prjxray/issues/171 | 21:26 |
tpb | Title: All output products should go into "build" dir · Issue #171 · SymbiFlow/prjxray · GitHub (at github.com) | 21:26 |
nats` | why the issue reference all the different commit I amended in my fork | 21:26 |
litghost | Because you have the #171 in the commit description | 21:29 |
litghost | Github is being "smart" | 21:29 |
nats` | but........ I made a lot of testing on my fork exactly to not pollute the main one... | 21:30 |
nats` | Am I wrong or this is really stupid ? | 21:30 |
nats` | (yep never really used for working on big projects) | 21:30 |
litghost | Nothing to worry about | 21:32 |
nats` | oky thanks you're reassuring me :) | 21:33 |
nats` | for pull request should I make them atomic to the smallest commit possible or group some higher level commit ? | 21:33 |
nats` | for example i'm fixing different fuzzer build process, should I PR each fuzzer fix or all at once ? | 21:34 |
nats` | litghost, if I'm understanding correctly it creates a list of the PIPS in two file uphill and downhill | 22:03 |
nats` | but it doesn't flush while running | 22:03 |
litghost | It's unclear where the memory usage is going. If adding a flush in the loop solves the issues, great. But that seems wrong to me, as typical buffered file writers flush on newline or # of characters. | 22:04 |
nats` | I'll dig a little more to understand that | 22:05 |
nats` | but for what I saw the file are empty while the loop is running | 22:05 |
litghost | Oph | 22:05 |
nats` | I need to recheck that | 22:05 |
litghost | Worth trying adding a flush then | 22:06 |
litghost | https://www.tcl.tk/man/tcl8.4/TclCmd/flush.htm | 22:06 |
tpb | Title: Tcl Built-In Commands - flush manual page (at www.tcl.tk) | 22:06 |
nats` | but does this mean file will be 16GB+ ? | 22:06 |
litghost | I'm showing ~2.7G and 3.6G | 22:07 |
litghost | If all of that was buffered, that might be enough to cause an OOM on top of the typical vivado usage | 22:08 |
nats` | ah nop sorry it doesn't stay empty it has crashed before | 22:08 |
nats` | seeing the size of that vivado stuff I think it's not doable to try a valgrind | 22:08 |
litghost | You can try https://www.tcl.tk/man/tcl8.4/TclCmd/memory.htm#M11 "memory usage" to debug it | 22:10 |
tpb | Title: Tcl Built-In Commands - memory manual page (at www.tcl.tk) | 22:10 |
nats` | thanks for the hint I'll take a look | 22:11 |
*** mrhat2010[m] has joined #symbiflow | 22:14 | |
nats` | https://webcache.googleusercontent.com/search?q=cache:CsB7PWFna0QJ:https://forums.xilinx.com/t5/Vivado-TCL-Community/Is-it-possible-to-navigate-through-a-path-automatically-in/td-p/757323+&cd=5&hl=fr&ct=clnk&gl=fr I'm wondering why this page is no more available on the website directly | 22:26 |
tpb | Title: Solved: Is it possible to navigate through a path automati... - Community Forums3rd Party Header & Footer (at webcache.googleusercontent.com) | 22:26 |
nats` | when trying a little in tcl shell I see some interesting things | 22:35 |
nats` | foreach pip [get_pips] {} <= is not really a problem it consume about 2.3GB but foreach pip [get_pips] {foreach dnode [get_nodes -downhill -of_object $pip] {}} <= seems to already be a a big problem | 22:39 |
nats` | maybe because dnodes is never freed | 22:39 |
nats` | I'll try something using intermediate value | 22:39 |
digshadow | nats`: back for a bit sorting through things | 22:51 |
digshadow | feel free to ping me again if you need something asap, otherwise will sort through messages as I can | 22:52 |
nats` | no problem | 22:52 |
mithro | nats`: I removed the -j because it was failing, will figure out how to reenable once I figure out why it failed... | 23:33 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!