Friday, 2019-03-01

*** tpb has joined #symbiflow00:00
elmslitghost: dependency question. the ice40 fasm2asc depends on fasm repo and so does prjxray tools. If I just add fasm to arch-defs 3rd party, they could get out of sync. This is one reason people avoid recursive submodules. Any thoughts?00:43
litghostelms: Not sure it matters.  prjxray will remain internally consistent, and so will symbiflow-arch-defs00:44
litghostelms: Alturnatively we put fasm2asc in its own repo, for double + consistency?00:44
elmslitghost: probably won't matter, but I don't like the feel. Maybe kick it down the road when it's time to improve/cleanup the dependencies in general.00:46
*** citypw has joined #symbiflow03:29
*** OmniMancer has joined #symbiflow04:14
*** Rohan_ has joined #symbiflow05:47
Rohan_Hi, I would like to know what are some good beginner issues to start with?05:48
*** Rohan_ has quit IRC05:55
*** Rohan_ has joined #symbiflow06:22
*** Rohan_ has quit IRC06:33
*** rohan_ has joined #symbiflow07:23
*** kraiskil has joined #symbiflow07:32
*** rohan_ has quit IRC07:51
*** _whitelogger has quit IRC07:58
*** _whitelogger_ has joined #symbiflow08:01
*** _whitelogger_ has quit IRC08:31
sf-slack<mkurc> @litghost @acomodi Sorry about the RAM32X1D. I didn't know it won't work.08:33
sf-slack<kgugala> hi Rohan_, you may look at issues tagged as good first issue08:33
*** _whitelogger has joined #symbiflow08:34
sf-slack<acomodi> @mkurc: no problem with that, now we know that there is an issue to be solved with those RAM32X1D09:19
*** celadon has joined #symbiflow09:21
*** celadon_ has joined #symbiflow09:46
*** celadon has quit IRC09:47
*** celadon_ has quit IRC09:55
*** celadon has joined #symbiflow09:58
*** citypw has quit IRC10:11
*** citypw has joined #symbiflow11:35
*** kraiskil has quit IRC12:37
*** kraiskil has joined #symbiflow13:04
*** kraiskil has quit IRC13:14
*** kraiskil has joined #symbiflow13:27
*** celadon has quit IRC13:29
*** celadon has joined #symbiflow13:32
*** celadon has quit IRC13:59
*** celadon has joined #symbiflow14:14
*** kraiskil has quit IRC14:38
*** OmniMancer has quit IRC14:55
sf-slack<tmichalak> Hi Guys, I started looking into and wanted to run the fuzzer first (051-pip-imuxlout-bypalts), however it fails on with the following error: "Didn't generate any segments"14:56
tpbTitle: INT_R.IMUX43.LOGIC_OUTS23 solution is unstable · Issue #588 · SymbiFlow/prjxray · GitHub (at
sf-slack<tmichalak> @litghost: git log shows you were the last to modify the fuzzer, do you have an idea what might be going on?14:56
*** OmniMancer has joined #symbiflow15:00
*** OmniMancer has quit IRC15:02
*** OmniMancer has joined #symbiflow15:06
*** OmniMancer has quit IRC15:06
litghostI believe that may be because you have already solved all the bits.  Did you try deleting the segbits file first?15:27
litghostSpecifically the int ones?15:27
sf-slack<acomodi> update: murax is working on HW (the counter though is not visible to human eyes. To check if it worked I needed to use the oscilloscope). Picosoc didn't work, it turns out that the program data was not in `BRAMs` and was probably directly synthesized in LUTs. with a quick fix from @mkurc now I am building another picosoc which has progmem in `BRAMs`. Further updates later on with the status.15:40
litghostacomodi: Ya, the counter is too fast, but the LED driven via the timing and the UART echo both work.16:12
sf-slack<acomodi> @litghost: Yep, those work fine. Question about UART. It is supposed to simply to output the input right?16:14
litghostacomodi: Yes, and it outputs an 'A' at boot, but seeing that is pretty hard.16:14
sf-slack<acomodi> @litghost: Great, so it is working as expected16:15
litghostacomodi: FYI, the reason the counter is too fast it that the Murax was generated for ice40, which runs ~8 times slower.16:16
sf-slack<acomodi> litghost: Ok, good to know. Before checking with the oscilloscope I was afraid it wasn't working anymore16:19
sf-slack<acomodi> Update: picosoc is still not working on HW, I have added an external counter to check if the bitstream was fine and the counter works. I have to debug whether there is some kind of problem with the progmem that is not correctly read or with the CPU itself.18:42
litghostacomodi: There is a possible bug in the way we are generating the routing graph.  Track connections should be using switch type SHORT versus switch type MUX.  Might want to try fixing that, and see if it helps18:47
litghost rather than two delayless switch connections, should probably be one shorted switch18:48
tpbTitle: symbiflow-arch-defs/ at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack<acomodi> litghost: ok, I'll look into that then19:19
*** sudo-sh has joined #symbiflow19:49
*** sudo-sh has quit IRC20:30
mithrolitghost: There is something weird going on DB generation....21:25
litghostmithro: Be more specific?21:26
mithrolitghost: There seem to be some major changes in the bram output....21:26
mithrolitghost: Will push something shortly21:26
litghostmithro: Just make a PR or diff for now?21:26
mithrolitghost: Will do21:27
mithrolitghost: It seems like the SLICEM RAM/SMALL/SRL bits disappeared...21:31
tpbTitle: Comparing SymbiFlow:master...mithro:master · SymbiFlow/prjxray-db · GitHub (at
litghostBRAM is likely a regression due to SDP mode, which causes some parameter decoupling21:34
litghostNot sure what the SLICEM regression is21:34
litghostmithro: Ya, BRAM regression was straight forward:
tpbTitle: Only tag some tags when running in TDP mode. by litghost · Pull Request #687 · SymbiFlow/prjxray · GitHub (at
litghostThe SLICEM regression looks a lot like what would happen if fuzzer 018 never ran at all21:43
litghostCan you check that fuzzer 018 actually ran successfully?21:44
mithroI seem to have both 018-clbram and 018-clb-ram ....21:44
litghostthey were renamed at some point21:45
tpbTitle: Snippet | IRCCloud (at
litghostThat looks right, what does running make pushdb do?21:47
litghost"make pushdb"21:47
litghostI expect it will fix it up21:47
mithrolitghost: I wonder if this is the race condition in pushdb21:48
litghostmithro: Ah, totally possible!21:48
litghostI already answered you?21:54
litghost> mithro: Ya, BRAM regression was straight forward:
tpbTitle: Only tag some tags when running in TDP mode. by litghost · Pull Request #687 · SymbiFlow/prjxray · GitHub (at
mithrolitghost: Oh yeah - okay21:54
*** litghost__ has joined #symbiflow22:52
*** _whitelogger_ has joined #symbiflow22:54
*** zkms_ has joined #symbiflow22:54
*** _whitelogger has quit IRC23:00
*** zkms has quit IRC23:00
*** galv[m] has quit IRC23:00
*** litghost has quit IRC23:00
*** litghost__ is now known as litghost23:02
*** galv[m] has joined #symbiflow23:07
mithrolitghost: ?23:33
tpbTitle: Fuzzers missing files · Issue #689 · SymbiFlow/prjxray · GitHub (at
*** _whitelogger_ has quit IRC23:46
mithrolitghost: Any idea what is up with the mask_bram_X.db files with ?23:48
tpbTitle: Comparing SymbiFlow:master...mithro:master · SymbiFlow/prjxray-db · GitHub (at
*** _whitelogger has joined #symbiflow23:49
litghostmithro: Nope.  I don't really leverage the mask files, not entirely sure what they are used for.23:49
mithrolitghost: Should ./artix7/mask_clk_bufg_bot_r.db still exist?23:52
mithrolitghost: segbits_clk_bufg_rebuf.db replaces it, right?23:53
*** proteusguy has quit IRC23:54
litghostmithro: Incorrect.  The CLK_BUFG fuzzer (042) was disable because it was persistently unstable and causing checkdb to fail.  042 is currently disable and was filed23:59
tpbTitle: Unstable output from 042 fuzzer · Issue #657 · SymbiFlow/prjxray · GitHub (at
litghostmithro: BUFG_REBUF is a different tile and a different set of bits23:59

Generated by 2.13.1 by Marius Gedminas - find it at!