00:36 <elms> litghost: 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:37 <litghost> elms: Not sure it matters. prjxray will remain internally consistent, and so will symbiflow-arch-defs

00:37 <litghost> elms: Alturnatively we put fasm2asc in its own repo, for double + consistency?

00:39 <elms> litghost: 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.

05:40 <Rohan_> Hi, I would like to know what are some good beginner issues to start with?

09:11 <sf-slack> <acomodi> @mkurc: no problem with that, now we know that there is an issue to be solved with those RAM32X1D

14:49 <sf-slack> <tmichalak> Hi Guys, I started looking into https://github.com/SymbiFlow/prjxray/issues/588 and wanted to run the fuzzer first (051-pip-imuxlout-bypalts), however it fails on segmaker.py with the following error: "Didn't generate any segments"

14:49 <tpb> Title: INT_R.IMUX43.LOGIC_OUTS23 solution is unstable · Issue #588 · SymbiFlow/prjxray · GitHub (at github.com)

14:49 <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?

15:19 <litghost> I believe that may be because you have already solved all the bits. Did you try deleting the segbits file first?

15:20 <litghost> Specifically the int ones?

15:33 <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.

16:04 <litghost> acomodi: Ya, the counter is too fast, but the LED driven via the timing and the UART echo both work.

16:06 <sf-slack> <acomodi> @litghost: Yep, those work fine. Question about UART. It is supposed to simply to output the input right?

16:07 <litghost> acomodi: Yes, and it outputs an 'A' at boot, but seeing that is pretty hard.

16:08 <sf-slack> <acomodi> @litghost: Great, so it is working as expected

16:08 <litghost> Yep

16:09 <litghost> acomodi: FYI, the reason the counter is too fast it that the Murax was generated for ice40, which runs ~8 times slower.

16:11 <sf-slack> <acomodi> litghost: Ok, good to know. Before checking with the oscilloscope I was afraid it wasn't working anymore

18:35 <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:40 <litghost> acomodi: 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 helps

18:41 <litghost> https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/utils/prjxray_routing_import.py#L296 rather than two delayless switch connections, should probably be one shorted switch

18:41 <tpb> Title: symbiflow-arch-defs/prjxray_routing_import.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

19:12 <sf-slack> <acomodi> litghost: ok, I'll look into that then

21:18 <mithro> litghost: There is something weird going on DB generation....

21:18 <litghost> mithro: Be more specific?

21:19 <mithro> litghost: There seem to be some major changes in the bram output....

21:19 <mithro> litghost: Will push something shortly

21:19 <litghost> mithro: Just make a PR or diff for now?

21:19 <mithro> litghost: Will do

21:24 <mithro> litghost: It seems like the SLICEM RAM/SMALL/SRL bits disappeared...

21:24 <mithro> litghost: https://github.com/SymbiFlow/prjxray-db/compare/master...mithro:master

21:24 <tpb> Title: Comparing SymbiFlow:master...mithro:master · SymbiFlow/prjxray-db · GitHub (at github.com)

21:27 <litghost> BRAM is likely a regression due to SDP mode, which causes some parameter decoupling

21:27 <litghost> Not sure what the SLICEM regression is

21:31 <litghost> mithro: Ya, BRAM regression was straight forward: https://github.com/SymbiFlow/prjxray/pull/687/files

21:31 <tpb> Title: Only tag some tags when running in TDP mode. by litghost · Pull Request #687 · SymbiFlow/prjxray · GitHub (at github.com)

21:36 <litghost> The SLICEM regression looks a lot like what would happen if fuzzer 018 never ran at all

21:36 <litghost> Can you check that fuzzer 018 actually ran successfully?

21:37 <mithro> I seem to have both 018-clbram and 018-clb-ram ....

21:37 <litghost> they were renamed at some point

21:38 <mithro> https://www.irccloud.com/pastebin/l8L11QaZ/

21:38 <tpb> Title: Snippet | IRCCloud (at www.irccloud.com)

21:40 <litghost> That looks right, what does running make pushdb do?

21:40 <litghost> "make pushdb"

21:40 <litghost> I expect it will fix it up

21:41 <mithro> litghost: I wonder if this is the race condition in pushdb

21:41 <litghost> mithro: Ah, totally possible!

21:46 <mithro> What about BRAM_L.RAMB18_Y0.WRITE_MODE_A_NO_CHANGE and BRAM_L.RAMB18_Y0.ZINV_REGCLKB ?

21:47 <litghost> I already answered you?

21:47 <litghost> > mithro: Ya, BRAM regression was straight forward: https://github.com/SymbiFlow/prjxray/pull/687/files

21:47 <tpb> Title: Only tag some tags when running in TDP mode. by litghost · Pull Request #687 · SymbiFlow/prjxray · GitHub (at github.com)

21:47 <mithro> litghost: Oh yeah - okay

23:25 <mithro> litghost: https://github.com/SymbiFlow/prjxray/issues/689 ?

23:25 <tpb> Title: Fuzzers missing README.md files · Issue #689 · SymbiFlow/prjxray · GitHub (at github.com)

23:42 <litghost> mithro: Nope. I don't really leverage the mask files, not entirely sure what they are used for.

23:44 <mithro> litghost: Should ./artix7/mask_clk_bufg_bot_r.db still exist?

23:45 <mithro> litghost: segbits_clk_bufg_rebuf.db replaces it, right?

23:52 <litghost> mithro: Incorrect. The CLK_BUFG fuzzer (042) was disable because it was persistently unstable and causing checkdb to fail. 042 is currently disable and https://github.com/SymbiFlow/prjxray/issues/657 was filed

23:52 <tpb> Title: Unstable output from 042 fuzzer · Issue #657 · SymbiFlow/prjxray · GitHub (at github.com)

23:52 <litghost> mithro: BUFG_REBUF is a different tile and a different set of bits

23:58 <mithro> litghost: I think the mask_db are about which bits we have seen ever been set in that tile?