<tpb>
Title: Different bit names on the same bit position in CLBLL · Issue #456 · SymbiFlow/prjxray · GitHub (at github.com)
<mithro>
I'm still waking up
<mithro>
But I did start playing with the cloud build stuff that Rick setup a long time ago
<mithro>
I also kicked off a manual build last night
<digshadow>
cool
<mithro>
digshadow: it would be good to do some gardening of the prjxray issue tracker
halosghost has joined #symbiflow
<halosghost>
howdy, folks
<mithro>
Hi halosghost
litghost has joined #symbiflow
Rahix has quit [Quit: Rahix]
acomodi has quit [Ping timeout: 256 seconds]
<halosghost>
:P
halosghost has left #symbiflow ["WeeChat 2.3"]
<nats`>
ahhh SLICEL doesn't have the "dynamic write port" that's why it can be used only for combinatorial logic !
<nats`>
oups WW sorry
kgugala has quit [Ping timeout: 256 seconds]
Jack__ has quit [Quit: Page closed]
<mithro>
digshadow: Should 051-imuxlout be working?
<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 ?
<tpb>
Title: All output products should go into "build" dir · Issue #171 · SymbiFlow/prjxray · GitHub (at github.com)
<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.
<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.
<nats`>
mithro digshadow any hint on that ?
<nats`>
(vivado still running 100% in top)
<nats`>
(eating 11GB of ram now)
<nats`>
the process got killed after going over ram limit at 16GB
<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.
<nats`>
oky feel free to close my issue on the github so
<nats`>
I'll buy few ram stick to reach 32
<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.
<nats`>
I'll take a look but I think it's way above my knowledge for now :)
<nats`>
I'm patching simple things for now
<nats`>
anyway in the log vivado is giving some hints apparently
<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.
<litghost>
It's actually pretty small and understandable, but you would need to understand tcl to work on it
<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
<tpb>
Title: All output products should go into "build" dir · Issue #171 · SymbiFlow/prjxray · GitHub (at github.com)
<nats`>
why the issue reference all the different commit I amended in my fork
<litghost>
Because you have the #171 in the commit description
<litghost>
Github is being "smart"
<nats`>
but........ I made a lot of testing on my fork exactly to not pollute the main one...
<nats`>
Am I wrong or this is really stupid ?
<nats`>
(yep never really used for working on big projects)
<litghost>
Nothing to worry about
<nats`>
oky thanks you're reassuring me :)
<nats`>
for pull request should I make them atomic to the smallest commit possible or group some higher level commit ?
<nats`>
for example i'm fixing different fuzzer build process, should I PR each fuzzer fix or all at once ?
<nats`>
litghost, if I'm understanding correctly it creates a list of the PIPS in two file uphill and downhill
<nats`>
but it doesn't flush while running
<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.
<nats`>
I'll dig a little more to understand that
<nats`>
but for what I saw the file are empty while the loop is running
<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
<tpb>
Title: Solved: Is it possible to navigate through a path automati... - Community Forums3rd Party Header & Footer (at webcache.googleusercontent.com)
<nats`>
when trying a little in tcl shell I see some interesting things
<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
<nats`>
maybe because dnodes is never freed
<nats`>
I'll try something using intermediate value
<digshadow>
nats`: back for a bit sorting through things
<digshadow>
feel free to ping me again if you need something asap, otherwise will sort through messages as I can
<nats`>
no problem
<mithro>
nats`: I removed the -j because it was failing, will figure out how to reenable once I figure out why it failed...