kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #symbiflow
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
OmniMancer has joined #symbiflow
kraiskil has quit [Ping timeout: 256 seconds]
spavs has joined #symbiflow
kraiskil has joined #symbiflow
kgugala_ has joined #symbiflow
kgugala has quit [Ping timeout: 240 seconds]
xtro has quit [Ping timeout: 240 seconds]
kgugala has joined #symbiflow
kgugala_ has quit [Ping timeout: 240 seconds]
<spavs>
hi, for prjxray, how to I change the sequence of the fuzzers ?
<sf-slack>
<tmichalak> spavs: The Makefile in the fuzzers directory describes which fuzzers to run
<sf-slack>
<tmichalak> spavs: first of all, you can run them manually in the order you like
<spavs>
yes, the makefile in the fuzzer directory describes which fuzzers to run; but I observed that the sequence or order in which the fuzzers are run are quite "random"
<spavs>
can't find the codes where the sequence/order are called;
<spavs>
for example when I run "make -j32 MAX_VIVADO_PROCESS=32 db-part-only-artix7_200t"
<spavs>
the fuzzers run 000 and then 074 followed by 073
<spavs>
can't seem to locate the codes that determine the order of fuzzers run
<sf-slack>
<tmichalak> This is actually a Make thing, the only thing we fully control is the dependecy on some preprequisite fuzzers - like many of them need the result of 005-tilegrid to run
<sf-slack>
<tmichalak> the fuzzer macro is being used for that
<sf-slack>
<tmichalak> the naming of the fuzzers was meant to help with the execution order
<sf-slack>
<tmichalak> But there is no part in prjxray that explicitly decides upon the exact execution order
<spavs>
thanks; so it's a fuzzer macro that does the ordering of the fuzzing sequence ?
<spavs>
can I check where in the code is this fuzzer macro called ?
<sf-slack>
<tmichalak> only to some extent, for example `$(eval $(call fuzzer,013-clb-ncy0,005-tilegrid,all))` means that for the 013 fuzzer the 005 is required to finish
<spavs>
ah ......... ic ic, thanks;
<sf-slack>
<tmichalak> but you will notice that there are more than fuzzer 013 with this dependency
<sf-slack>
<tmichalak> theoretically you could create a handcrafted chain of such dependency entries, i.e. `$(call fuzzer, f-1, f-0, all)` and the `$(call fuzzer, f-2, f-1, all)`
<sf-slack>
<tmichalak> but this is suboptimal for parallel execution
<spavs>
sure, but if I don't specify have the chain, which is the part of the code calls the macro that does the scheduling of the "call fuzzer" order ?
<sf-slack>
<tmichalak> That would be Make
<spavs>
ok can, understand ....... :) thanks;
<sf-slack>
<tmichalak> No problem
<spavs>
also to check on the organization of the database; if I were to run 2 different families for example artix7_100t and artix7_50t and fuzz 074
<spavs>
the later fuzz will overwrite the former fuzz right ?
<spavs>
in the db
<spavs>
which means if I fuzz 074 for artix7_100t and then fuzz 074 for artix7_50t
<spavs>
the database would be for artix7_50t; am I right ?
<sf-slack>
<tmichalak> Nope, `$(call fuzzer,074-dump_all,005-tilegrid 072-ordered_wires,part))` note the `part` at the end of this call
<sf-slack>
<tmichalak> the same goes for 072
<sf-slack>
<tmichalak> it's part specific
<sf-slack>
<tmichalak> which means the result will end up in a separate directory
<sf-slack>
<tmichalak> in opposition to calls with `all`
<sf-slack>
<tmichalak> these are being overwritten
<spavs>
separate directory like "prjxray/database/artix7/xc7a100tfgg676-1" for example ?
<spavs>
but I don't see any .db files in that directory
<sf-slack>
<tmichalak> yes, as far as the directory is concerned
<sf-slack>
<tmichalak> and there are no .db files because the fuzzers that do generate the .db are not part specific
<sf-slack>
<tmichalak> what is part specific is the pin constraints, tilegrid, tileconn etc.
<spavs>
ah ........... ic ic ............. thanks so much :)
rvalles_ has quit [Ping timeout: 246 seconds]
spavs has quit [Remote host closed the connection]
kraiskil has quit [Ping timeout: 264 seconds]
kraiskil has joined #symbiflow
kgugala_ has joined #symbiflow
kgugala__ has joined #symbiflow
kgugala has quit [Ping timeout: 246 seconds]
kgugala has joined #symbiflow
kgugala_ has quit [Ping timeout: 240 seconds]
kgugala__ has quit [Ping timeout: 256 seconds]
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #symbiflow
kraiskil has quit [Ping timeout: 256 seconds]
kraiskil has joined #symbiflow
skydive has quit [Read error: Connection reset by peer]
skydive has joined #symbiflow
kraiskil has quit [Ping timeout: 246 seconds]
citypw has quit [Ping timeout: 240 seconds]
citypw has joined #symbiflow
somlo has quit [Remote host closed the connection]
citypw has quit [Remote host closed the connection]
kraiskil has joined #symbiflow
skydive has quit [Read error: Connection reset by peer]
skydive has joined #symbiflow
C-Man has quit [Remote host closed the connection]
craigo has joined #symbiflow
skydive has quit [Ping timeout: 260 seconds]
skydive has joined #symbiflow
<_whitenotifier-b>
[sv-tests] hzeller opened issue #970: Add RedPitaya to cores - https://git.io/JJueG
<_whitenotifier-b>
[fpga-tool-perf] acomodi opened issue #192: Add vpr-fasm2bels support for all the VPR tests - https://git.io/JJuel
<_whitenotifier-b>
[fpga-tool-perf] acomodi opened issue #193: Add circuits from the VTR paper - https://git.io/JJue6
xtro has joined #symbiflow
<_whitenotifier-b>
[fpga-tool-perf] acomodi opened issue #194: Provide config file to FPGA tool perf to run tests - https://git.io/JJuvr
<_whitenotifier-b>
[symbiflow-arch-defs] acomodi opened issue #1622: The Clean Circuit step in VPR takes too much time - https://git.io/JJuUm
QDX45 has joined #symbiflow
citypw has joined #symbiflow
OmniMancer has quit [Quit: Leaving.]
citypw has quit [Ping timeout: 240 seconds]
epony has joined #symbiflow
goku12 has joined #symbiflow
goku12 has quit [Client Quit]
goku12 has joined #symbiflow
goku12 has quit [Client Quit]
goku12 has joined #symbiflow
alexhw has quit [Remote host closed the connection]
alexhw has joined #symbiflow
enriq has joined #symbiflow
az0re has joined #symbiflow
craigo has quit [Quit: Leaving]
craigo has joined #symbiflow
kraiskil has quit [Ping timeout: 256 seconds]
space_zealot has joined #symbiflow
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 256 seconds]
goku12 has quit [Quit: WeeChat 2.9]
<_whitenotifier-b>
[conda-packages] HackerFoo opened issue #127: Depending on the `prjxray-config` script now introduces an implicit dependency on Conda. - https://git.io/JJu3p
samhsmith[m] has quit [Ping timeout: 244 seconds]
kgugala has quit [Quit: -a- Connection Timed Out]
samhsmith[m] has joined #symbiflow
kgugala has joined #symbiflow
rvalles has joined #symbiflow
<skydive>
litghost: thanks a lot for the help! - I guess I need to return my laptop! :)
<skydive>
Will take a crack on my desktop in a week's time - not at home unfortunately
<litghost>
skydive: Sorry I don't have a better answer. It is something we know we need to work on
<skydive>
It's understandable - lots of LUTs on the chip
<skydive>
I should be able to write up an ssh script to compile stuff remotely via my desktop as a workaround
<litghost>
skydive: But we know it is possible to have a memory space efficient graph representation, we just don't know what it looks like yet
josi7 has quit [Remote host closed the connection]
az0re has quit [Ping timeout: 240 seconds]
az0re has joined #symbiflow
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]