<nats`>
do you have an idea about this 013 issue ?
<nats`>
I don't know where I should look
<kgugala>
I'd grep through logs to see which run actually instantiated CLBLL_L.SLICEL_X1.CARRY4.ACY0
<kgugala>
also, I'd check git log if there was something done with this fuzzer recently
<nats`>
thanks good hints
proteusguy has quit [Ping timeout: 250 seconds]
Rahix_ has joined #symbiflow
Rahix has quit [Ping timeout: 268 seconds]
<nats`>
I don't find any clue about that duplicated problem
proteusguy has joined #symbiflow
<kgugala>
all those 01x bugs look like heisenbugs
<kgugala>
when I run it on my machine I cannot reproduce it
<kgugala>
however, on different machines those fails in exact the same way as for nats`
<nats`>
ouch I don't like that
<nats`>
I rerun one after having explicitly make clean the database
<nats`>
just to be sure
<nats`>
schroendinbug
<nats`>
uhh kgugala
<nats`>
make clean in database cleared the problem...
<nats`>
I guess we have to trigger the database make clean from fuzzer make
<kgugala>
I got this bug even with clean db
<nats`>
that becomes really "mystic" :D
<nats`>
currently running the 026 no problem so far since I clean the database
<kgugala>
for Artix?
<nats`>
yep
<nats`>
it's now Dumping pips from tile
<nats`>
I don't know which fuzzer it is :D
<kgugala>
I'd guess one of 05x
citypw has joined #symbiflow
citypw has quit [Ping timeout: 258 seconds]
Rahix_ has quit [Quit: Rahix_]
<litghost>
kgugala: > I think they (CLB fuzzers) were working before -> No, the CLB fuzzers were broken for a while. They were running to completion, but returning invalid results by including some INT bits.
<litghost>
I've been working on getting the false positive rate down, and artix7 seems more consistent. I'm currently doing a complete run on artix7 with the latest PR's, and then I'll do some repeat runs to ensure that the CLB fuzzers are stochastically failing
<litghost>
Are not stochastically failling
<litghost>
The changes I added for the CLB fuzzers will cause broken partial databases to generate errors, like the "strict: got duplicate tag" failure
<litghost>
But the reason for the failure is that the fuzzer added bad bits in the earlier run, and needs to be cleaned out
<litghost>
We could add smarts to detect when a new entry is narrower than the previous entry. Generally speaking narrower entries are more likely to be correct than wide entries
<nats`>
litghost, I think we need a massive rework of the dependencies and cleaning process
<nats`>
because a lot of things explode bescause of that
<litghost>
I don't disagree, however I don't see an immediately obvious solution. Part of the problem arises in the fact that the fuzzer process is additive, which makes the dependency tracking merky. Unclear what the "correct" structure looks like that enables parallelism and tighter dependency tracking
<nats`>
oky
Sonnenmann has joined #symbiflow
Rahix has joined #symbiflow
<nats`>
uhhhhh question...
<nats`>
is it normal to loop over the fuzzer 050 since few hours ?
<nats`>
we could save the last valid step and the corresponding target (zynq/artix/kintex)
<nats`>
so it would allow to keep everything coherent when restarting a failed fuzzer
<litghost>
that feature feels orthogonal to the 074 refactoring
<nats`>
sure it is !
<nats`>
sorry my mistake I made that confusing
<nats`>
I think it's a better feature to do before refactoring
<nats`>
my opinion is if we can be sure the dependency system covers almost all possible easy mistake the refactoring can be splitted in even more small job
<litghost>
Ultimately up to you
<nats`>
ok I'll focus on making things work first and we will see later or I'll stack a lot of modification in my code without testing but I keep that in mind
<nats`>
:wq
<nats`>
...
<nats`>
-_-
<nats`>
litghost, basic question with makefile but I don't remember if it ok to use $(var) to pass the argument to internal command line ?
<litghost>
what do you mean "internal command line"?
<nats`>
uhhmmm to pass as an argument for command line started by the Makefile
<tpb>
Title: GNU make: Reading Makefiles (at www.gnu.org)
<litghost>
If it's in the command portion, it is deferred, meaning command line overrides
<litghost>
if you need something in the dependency list, so the link
<nats`>
I think I see the link is useful thanks
<nats`>
I'm sorry this evening my brain doesn't want to speak english.... I'll try to write better sentence
<nats`>
cool thanks the arg passing through Makefile is working now with default value
<nats`>
I have something that seems to work i'll push to update the PR if it's good I'll squash commit before merge is it ok ?
<litghost>
nats: Sounds good
<nats`>
can you keep old file to compare with the new version I did a stupid make clean without saving them :|
<mithro>
litghost: It would be really nice if we solve https://github.com/SymbiFlow/prjxray/issues/494 -- then the CI should give us nice looking status outputs of which fuzzers ran / failed / etc
<tpb>
Title: Make each fuzzer output a test_results.xml file · Issue #494 · SymbiFlow/prjxray · GitHub (at github.com)
<mithro>
bblr, going to find some lunch
<nats`>
litghost, saw your review i'll take care of that tomorrow I need to go to sleep :)