Wednesday, 2019-01-16

*** tpb has joined #symbiflow00:00
*** proteusguy has quit IRC02:48
*** _whitelogger has quit IRC03:33
*** _whitelogger has joined #symbiflow03:36
*** citypw has joined #symbiflow03:59
*** proteusguy has joined #symbiflow04:07
*** proteusguy has quit IRC04:21
*** proteusguy has joined #symbiflow04:46
*** proteusguy has quit IRC06:25
*** proteusguy has joined #symbiflow07:03
*** proteusguy has quit IRC07:08
*** proteusguy has joined #symbiflow07:20
*** citypw has quit IRC09:03
nats`kgugala, I have a problem running the fuzzer 005 but I remember seeing something on the bug tracker09:05
nats`is it me or there is something broken ?09:05
*** Rahix has joined #symbiflow09:09
nats`++ fgrep CRITICAL vivado.log09:10
nats`+ test -z ''09:10
nats`+ for x in design*.bit09:10
nats`+ /home/nats/project/symbiflow/prjxray/build/tools/bitread --part_file /home/nats/project/symbiflow/prjxray/database/zynq7/xc7z010clg400-1.yaml -F 0x00000000:0xffffffff -o design.bits -z -y design.bit09:10
nats`Part file not found or invalid09:10
nats`../fuzzaddr/ recipe for target 'build/specimen_001/OK' failed09:10
nats`uhhmm it may have been corrected by a commit I don't have let me retry09:11
noopwafelheh is zynq7 'working' now? :)09:11
nats`working on it (mainly kgugala in fact I'm fixing generale perf problem in fuzzer)09:12
noopwafelvery nice!09:12
nats`oky kgugala seems fixed by a change in the 001 fuzzer :)09:13
nats`I start a full run on zynq with time to see how long it'll take09:14
nats`let's hope it doesn't fail mid way09:14
*** citypw has joined #symbiflow09:15
nats`+ python3 /home/nats/project/symbiflow/prjxray/utils/ --strict build/segbits_clbx.db09:42
nats`Traceback (most recent call last):09:42
nats`  File "/home/nats/project/symbiflow/prjxray/utils/", line 61, in <module>09:42
nats`    main()09:42
nats`  File "/home/nats/project/symbiflow/prjxray/utils/", line 57, in main09:42
nats`    run(args.fin, args.fout, strict=args.strict, verbose=args.verbose)09:42
nats`  File "/home/nats/project/symbiflow/prjxray/utils/", line 27, in run09:42
nats`    bits, tag, bitss[bits])09:42
nats`AssertionError: strict: got duplicate bits frozenset({'31_16', '31_17'}): CLB.SLICE_X0.BLUT.RAM CLB.SLICE_X0.ALUT.RAM09:42
nats`+ finish09:42
nats`+ echo 'Cleaning up temp files'09:42
nats`I'll switch to artix because I think kgugala is stil lfixing a lot of things on zynq target09:42
*** citypw has quit IRC10:10
nats`fuzzer 013 making error too in artix 710:54
nats`+ python3 /home/nats/project/symbiflow/prjxray/utils/ --out ./tmp.7L99aPR736 /home/nats/project/symbiflow/prjxray/database/artix7/segbits_clbll_l.db ./tmp.HnAre7NUQC10:54
nats`WARNING: got duplicate tag CLBLL_L.SLICEL_X1.CARRY4.ACY010:54
nats`  Orig line: CLBLL_L.SLICEL_X1.CARRY4.ACY0 31_01 31_04 31_14 31_1510:54
nats`  New line : CLBLL_L.SLICEL_X1.CARRY4.ACY0 31_1410:54
nats`Traceback (most recent call last):10:54
nats`  File "/home/nats/project/symbiflow/prjxray/utils/", line 64, in <module>10:54
nats`    main()10:54
nats`  File "/home/nats/project/symbiflow/prjxray/utils/", line 60, in main10:54
nats`    verbose=args.verbose)10:54
nats`  File "/home/nats/project/symbiflow/prjxray/utils/", line 28, in run10:54
nats`    assert not strict, "strict: got duplicate tag"10:54
nats`AssertionError: strict: got duplicate tag10:54
kgugalayes, I've seen the problems with 01x fuzzers on zynq10:58
nats`there it's on artix10:58
nats`the second one10:58
kgugalaI think they were working before10:58
nats`how about taking a break in new feature and working together to get a full run working for each target ?10:59
nats`in my case the 013 always fail on same error10:59
kgugalastable DB would be very good to have11:00
nats`it would help people wanting to work on higher level stuff11:00
kgugalacan you create an issue with 013 on artix11:00
nats`yep sure I wanted to be sure it's not already a known issue11:01
kgugalanote that about a week ago we switched to more strict error checking11:01
kgugalaso the problem you have could be present before, but was masked11:01
nats`oky good things anyway to clean everything :)11:02
kgugalastill, we need to fix this11:02
tpbTitle: Fuzzer 013 Duplicate Tag · Issue #532 · SymbiFlow/prjxray · GitHub (at
nats`you're copied in the issue11:04
nats`so you'll see update11:04
nats`do you have an idea about this 013 issue ?11:07
nats`I don't know where I should look11:07
kgugalaI'd grep through logs to see which run actually instantiated CLBLL_L.SLICEL_X1.CARRY4.ACY011:31
kgugalaalso, I'd check git log if there was something done with this fuzzer recently11:32
nats`thanks good hints11:34
*** proteusguy has quit IRC11:39
*** Rahix_ has joined #symbiflow11:52
*** Rahix has quit IRC11:55
nats`I don't find any clue about that duplicated problem13:49
*** proteusguy has joined #symbiflow13:55
kgugalaall those 01x bugs look like heisenbugs14:30
kgugalawhen I run it on my machine I cannot reproduce it14:30
kgugalahowever, on different machines those fails in exact the same way as for nats`14:31
nats`ouch I don't like that14:32
nats`I rerun one after having explicitly make clean the database14:32
nats`just to be sure14:32
nats`uhh kgugala14:42
nats`make clean in database cleared the problem...14:42
nats`I guess we have to trigger the database make clean from fuzzer make14:42
kgugalaI got this bug even with clean db14:56
nats`that becomes really "mystic" :D14:58
nats`currently running the 026 no problem so far since I clean the database14:59
kgugalafor Artix?15:12
nats`it's now Dumping pips from tile15:15
nats`I don't know which fuzzer it is :D15:15
kgugalaI'd guess one of 05x15:34
*** citypw has joined #symbiflow15:34
*** citypw has quit IRC16:21
*** Rahix_ has quit IRC17:40
litghostkgugala: > 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.18:14
litghostI'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 failing18:16
litghostAre not stochastically failling18:16
litghost The changes I added for the CLB fuzzers will cause broken partial databases to generate errors, like the "strict: got duplicate tag" failure18:17
litghostBut the reason for the failure is that the fuzzer added bad bits in the earlier run, and needs to be cleaned out18:17
litghostWe 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 entries18:18
nats`litghost, I think we need a massive rework of the dependencies and cleaning process19:17
nats`because a lot of things explode bescause of that19:17
litghostI 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 tracking19:24
*** Sonnenmann has joined #symbiflow19:48
*** Rahix has joined #symbiflow20:10
nats`uhhhhh question...20:10
nats`is it normal to loop over the fuzzer 050 since few hours ?20:10
litghostyes and no20:13
tpbTitle: int_loop stability criteria is wasteful · Issue #537 · SymbiFlow/prjxray · GitHub (at
litghostI'm working on a patch20:13
litghostlowers the runtime significantly20:13
litghoston artix7 it appears to take all 12 iterations, but the last couple iterations only find less than 10 pips per iteration20:14
*** Sonnenmann has quit IRC20:27
nats`uhhmmm ok I need to understand how it works but anyway I think it loops since 3 or 4hours so I'll stop it20:27
nats`litghost, do you think I modify my 074 patch to do what we said and them redo a clean PR to merge anyway ?20:29
litghostnats: can you rephrase?20:43
nats`we discussed some modification to apply to my last code for fuzzer 07420:45
nats`I was wondering if I do them even if we couldn't fully test it because of dependencies to other fuzzer20:45
nats`I'm tired I guess my english is pretty hard to understand :D20:46
nats`short: do I update my patch to merde the PR for the 07420:46
litghostnats: Yes, apply the fixes. 072-074 are relatively independent of the other fuzzers, so you only really need to test 072-07420:49
nats`074 is more complicated20:53
nats`the post processing call stuff from lower fuzzer like 00520:54
nats`so I couldn't test post processing but I didn't modify that part so if the generation part of the fuzzer is good.... it should be20:54
nats`just be aware that merge could break something20:55
nats`but if everybody is aware it's not a real problem20:55
nats`litghost, can we skip the move of my pool function to for now20:57
nats`I would like to avoid spreadin mistake if there are some20:58
mithroSo, should "make -jXXX" work on the fuzzers?20:58
nats`once well tested we could refactors things20:58
litghostmake -jXXX is working20:58
litghostI've been using it to accelerate testing with success20:59
mithrolitghost: Does it work with QUICK=y ?21:05
mithrolitghost: and what should I set it too? The number of processors? smaller? greater?21:06
litghostUnclear, I haven't been testing with QUICK, I'm mostly interested in fixed the fuzzer output to be correct right now21:06
litghostPretty much none of the tip of HEAD fuzzers output the correct bits21:07
litghostAs for number of processes, I've been using -j48 to good affect, but my machine is very large.21:13
mithrolitghost: This is for the CI21:20
mithrolitghost: It's almost working21:20
mithroCurrently trying "make --output-sync=target --warn-undefined-variables QUICK=y -j32"21:21
* nats` is dying of jealousy of all those huge -j :)21:23
nats`litghost, do you have an idea about the good default size for the number of item to process in each instance of vivado ?21:23
litghosttry 50 items?21:24
nats`it's really low21:24
nats`I made all my test with 64 block so something like hundreds thousand item per instance21:24
nats`but it varies a lot following what you're processing21:24
litghostso tiles should be ~10 - ~10021:25
nats`in fact it depends more on what is called in the loop21:25
litghostpips should 10k - 100k21:25
litghostsame with nodes21:25
litghosttry that for a first cut21:25
litghostwatch for peak memory and runtime21:25
nats`I'll do that yes21:27
litghostnodes is ~10k21:28
nats`how hard could it be to make a first fuzzer called bencher21:28
litghostpips is ~100k21:28
nats`to find the sweet spot21:28
nats`it could be the next step21:28
litghostI don't think we want it to be that dynamic21:28
litghostBut it is a fun exercise21:28
litghostKeep in mind you are balancing a lot of variables21:28
litghostCPU usage, disk usage, memory usage21:28
nats`sure you're right21:29
nats`I'll put a default at 10k in the python script and set things in the makefile21:29
litghostI think we might tune the CI and larger systems differently than the defaults21:29
litghostsounds good21:29
nats`CI ?21:29
litghostcontinuous integration21:29
litghostOnce the memory requirements on 072-074 is fixed, we should be running a database generation once a day (or maybe every other day)21:30
litghostmithro was alluding to a QUICK mode, which hopefully runs in <10 minutes21:31
litghostto do sanity checking on PR's21:31
nats`ah oky21:32
nats`it seems complicated no ?21:32
nats`I mean even with optimisation I'm pretty sure 072 and 074 can't be run in less than few hours21:33
nats`by the way I was wondering if we should split 074 in two part, the generation and the post processing21:33
litghost074 is already split in a functional sense21:37
litghostI'm not sure the value of splitting it in the fuzzer sense21:38
litghost072-074 is generally excluded from QUICK because of its large runtime21:38
nats`the main advantage I see is in case of late failure in 074 you can easily rerun the post processing part21:39
litghostthat's what is for21:39
tpbTitle: prjxray/ at master · SymbiFlow/prjxray · GitHub (at
litghostI guess you mean from the standpoint of the makefile?21:39
litghostthe makefile could easily be refactored to know when the vivado portion is done21:40
nats`I used to run generate_after_dump by hand but it's not really "documented"21:40
nats`could be done in the same way I want to implement the "last target function"21:40
litghostthere are many ways if you are simply referring to keep 074 as one fuzzer, but making two targets instead of one21:41
nats` <= I was talking about extending this "feature request"21:42
tpbTitle: Fuzzer storing last target · Issue #528 · SymbiFlow/prjxray · GitHub (at
litghostNot sure how that is related21:42
litghost the database target could invoke generate_after_dump.sh21:43
tpbTitle: prjxray/Makefile at master · SymbiFlow/prjxray · GitHub (at
nats`we could save the last valid step and the corresponding target (zynq/artix/kintex)21:43
nats`so it would allow to keep everything coherent when restarting a failed fuzzer21:43
litghostthat feature feels orthogonal to the 074 refactoring21:43
nats`sure it is !21:43
nats`sorry my mistake I made that confusing21:44
nats`I think it's a better feature to do before refactoring21:44
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 job21:45
litghostUltimately up to you21:46
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 mind21:47
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 ?22:12
litghostwhat do you mean "internal command line"?22:16
nats`uhhmmm to pass as an argument for command line started by the Makefile22:19
tpbTitle: GNU make: Reading Makefiles (at
litghostIf it's in the command portion, it is deferred, meaning command line overrides22:22
litghostif you need something in the dependency list, so the link22:22
nats`I think I see the link is useful thanks22:26
nats`I'm sorry this evening my brain doesn't want to speak english.... I'll try to write better sentence22:27
nats`cool thanks the arg passing through Makefile is working now with default value22:29
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 ?22:39
litghostnats: Sounds good22:41
nats`can you keep old file to compare with the new version I did a stupid make clean without saving them :|23:00
mithrolitghost: It would be really nice if we solve -- then the CI should give us nice looking status outputs of which fuzzers ran / failed / etc23:11
tpbTitle: Make each fuzzer output a test_results.xml file · Issue #494 · SymbiFlow/prjxray · GitHub (at
mithrobblr, going to find some lunch23:13
nats`litghost, saw your review i'll take care of that tomorrow I need to go to sleep :)23:33
nats`good night !23:33
mithronats`: thanks for all your work!23:34

Generated by 2.13.1 by Marius Gedminas - find it at!