08:05 <sf-slack1> <mkurc> @litghost: I can try testing it with the PicoSoC

09:18 <sf-slack1> <mkurc> @litghost: I've tested your `fasm2bels.py` utility. When runned on the `chain_packing` it did worked correctly. However clock signals was not correctly translated which was expected since I've used the database without #727.

09:20 <sf-slack1> <mkurc> @litghost: Unfortunatelly when runned on a working design of the PicoSoC (no tile grid split) I got an error `assert 'RAMB36.RAM_EXTENSION_A_NONE_OR_UPPER' in tile_features`. You said that it does not support BRAMs yet ? If so then I can't use it right now. Or do I need the database from #727 to solve that ?

11:27 <sf-slack1> <acomodi> slicem regression test update: I have been able to shrink the `slicem.xml` test architecture to ~1300 lines. I have cleaned it up and removed some parts which were not needed. I'll try to further whittle down more un-needed parts.

12:34 <sf-slack1> <acomodi> I have been able to further shrink `slicem.xml` (~1000 lines). I have removed all MUX[678] and maintained only the FDRE FF. I think it is not shrinkable anymore without applying major modifications. Here's the latest commit https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/29/commits/fc209c4a3e0163e47657a6c50300ac6607ad8c1a

12:34 <tpb> Title: vpr: differing modes between lib_nets fix by acomodi · Pull Request #29 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)

13:48 <litghost> mkurc: only ramb18 support is present

13:49 <litghost> Mkurc: data Cascades require ramb36 support

13:54 <sf-slack1> <mkurc> @litghost: That is strange, I've just checked the fasm file I'am trying to convert and there is no mention of RAMB36. It uses a few RAMB18s.

13:55 <litghost> Mkurc: Ah, did you get the fast file from vpr or from bit2fasm?

13:55 <sf-slack1> <mkurc> from VPR

13:55 <sf-slack1> <mkurc> Shoud I use bit2fasm ?

13:56 <litghost> mkurc: yes

13:56 <sf-slack1> <mkurc> I see.

13:57 <litghost> acomodi: great

20:37 <sf-slack1> <acomodi> litghost, mithro: now that the SLICEM issue is solved I guess I could move back on to v2x. Around two months ago I had started dealing with that (https://github.com/SymbiFlow/symbiflow-arch-defs/pull/316). What would be one of the first things to do?

20:37 <tpb> Title: WIP: Improve the Verilog to XML conversion process by acomodi · Pull Request #316 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

20:38 <mithro> acomodi: I think that should be something we do sooner rather than later

20:39 <litghost> acomodi: Another thing to consider doing is working on isolating patches for upstreaming to VTR. Probably worth documenting a concrete plan to upstream the various bits. FYI, some changes on master+wip should probably not make it upstream, e.g. the round robin work. But many of the packer changes are fixing real bugs, like you most recent one.

20:42 <sf-slack1> <acomodi> mithro: all right, I need to understand though what are the main issues to be solved there in order to proceed with the improvements in v2x

20:43 <sf-slack1> <acomodi> litghost: ok, first I would say that a full rebase with the current master mainline of VTR could be necessary before starting to isolate the patches

20:45 <litghost> acomodi: Agreed

20:46 <litghost> acomodi: I did a more recent merge, but there has been some large commits since then

20:46 <sf-slack1> <acomodi> litghost: after that I'll look into the various major patches that need to be merged upstream and start to think on how to isolate them then

20:46 <litghost> acomodi: Thanks

20:47 <litghost> acomodi: FYI the metadata is already upstream, and genfasm has a PR https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/510

20:47 <tpb> Title: Initial implemention of genfasm by litghost · Pull Request #510 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)

20:47 <litghost> acomodi: So if you notice changes outside of the packer, do check if those changes are included in the FASM PR

20:47 <sf-slack1> <acomodi> Yes, in fact I see that we are smth like 260 commits behind

20:47 <sf-slack1> <acomodi> All right

20:50 <litghost> acomodi: We were "only" 50 commits behind a week or two ago. A large PR was merged having to do with dedicated clock networks.

20:52 <sf-slack1> <acomodi> litghost: Ok, hopefully than there will be no conflicts

20:53 <litghost> acomodi: I believe I solved most of the conflicts in the last merge, all bets are off. All the more reason to make a dedicated effort to get completely upstreamed

20:55 <sf-slack1> <acomodi> litghost: yes indeed, we better do that ASAP. I will deal with it first thing tomorrow

21:47 <mithro> acomodi: The first thing with the v2x was to get a bunch of tests together so that we are sure the v2x is working as we expect

21:48 <mithro> acomodi: The clock / comb generation is a bit fiddly and want to make sure it is happening correctly

23:03 <sf-slack1> <acomodi> mitrho: Ok, if I remember right I had added the tests for that already in the #316 PR

23:03 <sf-slack1> <acomodi> *mithro

23:05 <mithro> acomodi: Yeah

23:09 <mithro> acomodi: The testing came from trying to add support for v2x of the ice40 ioblocks and getting confused about what I was trying to do